Configuring RPM Probes on M, MX and T Series Routers and EX Series Switches

The probe owner and test name of an RPM probe together represent a single RPM configuration instance. When you specify the test name, you also can configure the test parameters.

To configure the probe owner, test name, and test parameters, include the probe statement at the [edit services rpm] hierarchy level:

Keep the following points in mind when you configure RPM clients and RPM servers:

• RPM is not supported on logical systems.

• Starting in Junos OS Release 17.3R1, PIC-based and Routing Engine-based RPM is supported for IPsec tunnels and GRE tunnels if you are using MS-MPCs or MS-MICs. Packet Forwarding Engine-based RPM is not supported for IPsec tunnels. Support of RPM on IPSec tunnels enables service level agreement (SLA) monitoring for traffic transported in IPSec tunnels.

• Starting in Junos OS Release 17.3R1, you can configure the generation of IPv4 icmp-ping and icmp-ping-timestamp RPM probes on an MS-MPC or MS-MIC, which increases the number of probes generated upto 1 million per second on every service-NPU compared to the number of probes that are generated on the Packet Forwarding Engine. Starting in Junos OS Release 18.1R1, you can configure the generation of icmp6-ping RPM probes on an MS-MPC or MS-MIC. To configure the generation of RPM probes on an MS-MPC or MS-MIC:

  • Include the destination-interface interface-name.logical-unit-number at the [edit services rpm probe owner test test-name] hierarchy level, and include the delegate-probes statement at the [edit services rpm probe owner] hierarchy level. The interface-name.logical-unit-number specifies a logical interface on an MS-MPC or MS-MIC slot, PIC, and port that has a valid IP address defined on it (for example, ms-1/2/1.1). The interface cannot be an aggregated multiservices interface (ams-).

  • Include the rpm client-delegate-probes and the family (inet | inet6) address address statements at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. The interface-name and the logical-unit-number must match the interface-name.logical-unit-number that you used for the destination-interface.

  For RPM probes configured on an MS-MPC or MS-MIC, you cannot configure the routing-instance statement at the [edit services rpm probe owner test test-name] hierarchy level, and you cannot configure both IPv4 and IPv6 probes within the same test.

  Starting in Junos OS Release 18.1R1, you can use additional filters to limit the output of the show services rpm probe-results and show services rpm history-results commands for RPM probes generated on an MS-MPC or MS-MIC.

• Starting in Junos OS Release 17.4R1, you can optimize the CLI configuration for RPM tests for IPv4. Starting in Junos OS Release 18.2R1, you can also optimize the CLI configuration for RPM tests for IPv6. This optimization allows the use of minimal RPM configuration statements to generate multiple tests (up to 100K tests) with pre-defined, reserved RPM test names. This optimization can be configured for tests with probes that are generated by either the Packet Forwarding Engine or by an MS-MPC or MS-MIC. Tests are generated for multiple combinations of source and target addresses, which are incremented based on your configuration.

  The maximum number of concurrent RPM probes supported for various Junos releases are as follows:

  • Junos OS release older than 17.3R1—500

  • Junos OS release 17.3R1 and later—2000 for ICMP and ICMP-Timestamp probe types. For probes of other types (UDP and TCP) the limit is 500.

  • Junos OS Release 17.3R1 and later (with the implementation of delegate-probes)—1 Million per Service-NPU.

    Note:

    One MS-MIC contains one service-NPU and one MS-MPC contains four service-NPUs.

    With the implementation of delegate-probes, the RPM probes are compliant to RFC792 and RFC4443. Hence, they can be used to monitor any IP device compliant to either RFC and are able to respond to icmp-timestamp and/or icmp6-ping packets.

  Tests are first generated for all the source addresses with the initial target address, then tests are generated for all the source addresses with the next available target address, and so on. You can also configure a group that contains global values for a particular probe owner, and apply the group to the probe owner.

  To generate multiple RPM tests, configure the following:

  The options are:

  ipv4-address-base	The IPv4 source or target address that is incremented to generate the addresses used in the RPM tests.
  ipv6-address-base	The IPv6 source or target address that is incremented to generate the addresses used in the RPM tests.
  ipv4-step	The amount to increment the IPv4 source or target address for each generated RPM test.
  ipv6-step	The amount to increment the IPv6 source or target address for each generated RPM test.
  ipv4-count	The maximum number of IPv4 source or target addresses to use for the generated RPM tests.
  ipv6-count	The maximum number of IPv6 source or target addresses to use for the generated RPM tests.
  interface-name.logical-unit-number	The services interface that is generating RPM probes and the logical unit number that is used for the first test that is generated.
  subunit-cnt	The maximum number of logical units used by the services interface in the generated tests. The first generated test uses the logical unit specified in the interface-name.logical-unit-number option, and each successive test increments the logical unit number by one. Once the maximum number of logical units has been used, the next generated test cycles back to the logical unit that was used in the first test.
  tests-count	The maximum number of RPM tests to generate. This number must be less than or equal to the number of generated source addresses multiplied by the number of generated target addresses.

  To configure a group with global values for a particular probe owner:

• To specify a probe owner, include the probe statement at the [edit services rpm] hierarchy level. The probe owner identifier can be up to 32 characters in length.

• To specify a test name, include the test statement at the [edit services rpm probe owner] hierarchy level. The test name identifier can be up to 32 characters in length. A test represents the range of probes over which the standard deviation, average, and jitter are calculated.

• To specify the contents of the data portion of Internet Control Message Protocol (ICMP) probes, include the data-fill statement at the [edit services rpm probe owner] hierarchy level. The value can be a hexadecimal value. The data-fill statement is not valid with the http-get or http-metadata-get probe types.

• To specify the size of the data portion of ICMP probes, include the data-size statement at the [edit services rpm probe owner] hierarchy level. The size can be from 0 through 65400 and the default size is 0. The data-size statement is not valid with the http-get or http-metadata-get probe types.

  Note:

  If you configure the hardware timestamp feature (see Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches):

  • This is a deprecated element data-size default value is 32 bytes and this is a deprecated element 32 is the minimum value for explicit configuration. The UDP timestamp probe type is an exception; it requires a minimum data size of 44 bytes.

  • The data-size must be at least 100 bytes smaller than the default MTU of the interface of the RPM client interface.

• On M Series and T Series routers, you configure the destination-interface statement to enable hardware timestamping of RPM probe packets. You specify an sp- interface to have the AS or Multiservices PIC add the hardware timestamps; for more information, see Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches. You can also include the one-way-hardware-timestamp statement to enable one-way delay and jitter measurements.

• To specify the User Datagram Protocol (UDP) port or Transmission Control Protocol (TCP) port to which the probe is sent, include the destination-port statement at the [edit services rpm probe owner test test-name] hierarchy level. The destination-port statement is used only for the UDP and TCP probe types. The value can be 7 or from 49160 through 65535.

  When you configure either probe-type udp-ping or probe-type udp-ping-timestamp along with hardware timestamping, the value for the destination-port can be only 7. A constraint check prevents you from configuring any other value for the destination port in this case. This constraint does not apply when you are using one-way hardware timestamping.

• To specify the value of the Differentiated Services (DiffServ) field within the IP header, include the dscp-code-point statement at the [edit services rpm probe owner test test-name] hierarchy level. The DiffServ code point (DSCP) bits value can be set to a valid 6-bit pattern; for example, 001111. It also can be set using an alias configured at the [edit class-of-service code-point-aliases dscp] hierarchy level. The default is 000000.

• To specify the number of stored history entries, include the history-size statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 0 to 512. The default is 50.

• To specify a number of samples for making statistical calculations, include the moving-average-size statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 0 through 255.

• To specify the number of probes within a test, include the probe-count statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 1 through 15.

• To specify the time to wait between sending packets, include the probe-interval statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 1 through 255 seconds.

• To specify the packet and protocol contents of the probe, include the probe-type statement at the [edit services rpm probe owner test test-name] hierarchy level. The following probe types are supported:

  • http-get—Sends a Hypertext Transfer Protocol (HTTP) get request to a target URL.

  • http-metadata-get—Sends an HTTP get request for metadata to a target URL.

  • icmp-ping—Sends ICMP echo requests to a target address.

  • icmp-ping-timestamp—Sends ICMP timestamp requests to a target address.

  • tcp-ping—Sends TCP packets to a target.

  • udp-ping—Sends UDP packets to a target.

  • udp-ping-timestamp—Sends UDP timestamp requests to a target address.

  The following probe types support hardware timestamping of probe packets: icmp-ping, icmp-ping-timestamp, udp-ping, udp-ping-timestamp. Starting in Junos OS Release 17.3R3, the delegate probes are distributed evenly across the interval of 3 seconds to avoid the packet bursts in the network due to real-time performance monitoring (RPM). RPM syslogs are processed with the increase in the ramp up time of RPM delegates tests to 60 seconds. With RPM syslogs processed, the chances of multiple tests starting and ending at the same time are smaller, thus a potential restriction in event-processing.

  Note:

  Some probe types require additional parameters to be configured. For example, when you specify the tcp-ping or udp-ping option, you must configure the destination port using the destination-port statement. The udp-ping-timestamp option requires a minimum data size of 12; any smaller data size results in a commit error. The minimum data size for TCP probe packets is 1.

  When you configure either probe-type udp-ping or probe-type udp-ping-timestamp along with the one-way-hardware-timestamp command, the value for the destination-port can be only 7. A constraint check prevents you for configuring any other value for the destination port in this case.

• To specify the routing instance used by ICMP probes, include the routing-instance statement at the [edit services rpm probe owner test test-name] hierarchy level. The default routing instance is Internet routing table inet.0.

• To specify the source IP address used for ICMP probes, include the source-address statement at the [edit services rpm probe owner test test-name] hierarchy level. If the source IP address is not one of the router’s assigned addresses, the packet uses the outgoing interface’s address as its source.

• Starting in Junos OS Release 16.1R1, to specify the source IPv6 address to be used for RPM probes that are sent from the RPM client (the device that originates the RPM packets) to the RPM server (the device that receives the RPM probes), include the inet6-options source-address ipv6-address statement at the [edit services rpm probe owner test test-name] hierarchy level. If the source IPv6 address is not one of the router’s or switch’s assigned addresses, the packet use the outgoing interface’s address as its source.

• To specify the destination address used for the probes, include the target statement at the [edit services rpm probe owner test test-name] hierarchy level.

  • For HTTP probe types, specify a fully formed URL that includes http:// in the URL address.

  • For all other probe types, specify an IP version 4 (IPv4) or IP version 6 (IPv6) (IPv6 support starts in Junos OS release 16.1R1) address for the target host.

• To specify the time to wait between tests, include the test-interval statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 0 through 86400 seconds. A value of 0 seconds causes the RPM test to stop after one iteration. The default value is 1.

• To specify thresholds used for the probes, include the thresholds statement at the [edit services rpm probe owner test test-name] hierarchy level. A system log message is generated when the configured threshold is exceeded. Likewise, an SNMP trap (if configured) is generated when a threshold is exceeded. The following options are supported:

  • egress-time—Measures maximum source-to-destination time per probe.

  • ingress-time—Measures maximum destination-to-source time per probe.

  • jitter-egress—Measures maximum source-to-destination jitter per test.

  • jitter-ingress—Measures maximum destination-to-source jitter per test.

  • jitter-rtt—Measures maximum jitter per test, from 0 through 60000000 microseconds.

  • rtt—Measures maximum round-trip time per probe, in microseconds.

  • std-dev-egress—Measures maximum source-to-destination standard deviation per test.

  • std-dev-ingress—Measures maximum destination-to-source standard deviation per test.

  • std-dev-rtt—Measures maximum standard deviation per test, in microseconds.

  • successive-loss—Measures successive probe loss count, indicating probe failure.

  • total-loss—Measures total probe loss count indicating test failure, from 0 through 15. The default for this threshold is 1.

• Traps are sent if the configured threshold is met or exceeded. To set the trap bit to generate traps, include the traps statement at the [edit services rpm probe owner test test-name] hierarchy level. The following options are supported:

  • egress-jitter-exceeded—Generates traps when the jitter in egress time threshold is met or exceeded.

  • egress-std-dev-exceeded—Generates traps when the egress time standard deviation threshold is met or exceeded.

  • egress-time-exceeded—Generates traps when the maximum egress time threshold is met or exceeded.

  • ingress-jitter-exceeded—Generates traps when the jitter in ingress time threshold is met or exceeded.

  • ingress-std-dev-exceeded—Generates traps when the ingress time standard deviation threshold is met or exceeded.

  • ingress-time-exceeded—Generates traps when the maximum ingress time threshold is met or exceeded.

  • jitter-exceeded—Generates traps when the jitter in round-trip time threshold is met or exceeded.

  • probe-failure—Generates traps for successive probe loss thresholds crossed.

  • rtt-exceeded—Generates traps when the maximum round-trip time threshold is met or exceeded.

  • std-dev-exceeded—Generates traps when the round-trip time standard deviation threshold is met or exceeded.

  • test-completion—Generates traps when a test is completed.

  • test-failure—Generates traps when the total probe loss threshold is met or exceeded.