Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Analyzing Network Efficiency in IPv6 Networks on MX Series Routers Using RPM Probes

Real-time performance monitoring (RPM) is a mechanism that enables you to monitor network performance in real time and to assess and analyze network efficiency. Typically, network performance is assessed in real time based on the jitter, delay, and packet loss experienced on the network. RPM is a service available in Junos OS that enables a router to measure metrics such as round-trip delays and unanswered echo requests. To compute these parameters, RPM exchanges a set of probes with other IP hosts in the network for monitoring and network tracking purposes. These probes are sent from a source node to other destination devices in the network that require tracking. Data such as transit delay and jitter can be collected from these probes, and this data can be used to provide an approximation of the delay and jitter experienced by live traffic in the network. Different live traffic metrics such as round-trip time (RTT), positive egress jitter, negative egress jitter, positive ingress jitter, negative ingress jitter, positive round-trip jitter, and negative round-trip jitter can be obtained from the results of the RPM test. RPM calculates minimum, maximum, average, peak-to-peak, standard deviation, and sum calculations for each of these measurements. RPM probes can also be used to verify the path between BGP neighbors.

Starting with Junos OS release 16.1, the RPM client router (the router or switch that originates the RPM probes) can send probe packets to the RPM probe server (the device that receives the RPM probes) that contains an IPv6 address. To specify the destination IPv6 address used for the probes, include the target (url ipv6-url | address ipv6-address) statement at the [edit services rpm probe owner test test-name] hierarchy level. The protocol family for IPv6 is named inet6.

To specify the IPv6 protocol-related settings and the source IPv6 address of the client from which the RPM probes are sent, include the inet6-options source-address ipv6-address statement at the [edit services rpm probe owner test test-name] hierarchy level. A probe request is a standard packet with corresponding TCP, UDP, and ICMP headers over the IPv6 header. No RPM header is appended to the standard packet for Routing Engine-based RPM implementation. A probe response is also a standard packet with corresponding TCP, UDP, and ICMP headers over the IPv6 header. No RPM header is appended to the standard packet for Routing Engine-based RPM implementation.

The output of the show services rpm probe-results owner probe-name test test-name and show services rpm history-results owner owner test name commands that display the results of the most recent RPM probes and results of historical RPM probes respectively have been enhanced to display the target address as IPv6 address and other IPv6 information for probes sent to IPv6 servers or destinations. The existing SNMP Get requests and traps for IPv6 are applicable for IPv6 probes. The target type field in the SNMP set operation contains IPv6 source and destination addresses.

Guidelines for Configuring RPM Probes for IPv6 Destinations

Keep the following points in mind when you configure IPv6 addresses for RPM destinations or servers:

  • Only Routing Engine-based RPM is supported for IPv6 targets including VRF support, specification of the size of the data portion of ICMP probes, data pattern, and traffic class.

  • You can configure probes with a combination of IPv4 and IPv6 tests. However, a test can be either IPv4 or IPv6-based at a point in time. The OS impacts the accuracy of the measurements because the variability factor introduced by the general OS that performs the system processing proved is significantly larger than the amount of time spent by the packet traversing on the wire. This condition causes round-trip time (RTT) spikes to be seen even with a single test.

  • Routing Engine-based RPM does not support one-way hardware-based timestamping.

  • One-way measurements are not supported here because timestamping is done only on the RPM client side.

  • The maximum number of concurrent probes allowed (by including the probe-limit statement at the [edit services rpm] hierarchy level) is 1000. We recommend that the limit on concurrent probes be set as 10. Higher concurrent probes can result in higher spikes. The maximum number of tests you can configure is 1000. RPM cannot be configured on logical systems. SNMP set operation is permitted only on ICMP probes and it is not supported for other type of probes.

  • The hardware-timestamp and one-way-hardware-timestamp statements at the [edit services rpm probe owner test test-name] hierarchy level are not supported for IPv6.

  • You cannot specify the icmp-ping (which sends ICMP echo requests to a target address) and the icmp-ping-timestamp (which sends ICMP timestamp requests to a target address) options with the probe-type statement at the [edit services rpm probe owner test test-name] hierarchy level.

  • Some of the RPM problems can resolved by restarting the SNMP remote operations process (rmopd) on the Routing Engine by using the restart remote-operations command. If RPM needs to be disabled, the rpm statement at the [edit services] hierarchy level needs to be deleted or deactivated. PIC, Packet Forwarding Engine, and lookup chip (LU) based RPM implementation for IPv6 are not supported.

  • The following table describes the IPv6 special address prefixes that are not supported.

    IPV6 Address Type

    IPV6 Address Prefix

    Node-Scoped Unicast

    ::1/128 is the loopback address

    ::/128 is the unspecified address

    IPv4-Mapped Addresses

    ::FFFF:0:0/96

    IPv4-Compatible Addresses

    :<ipv4-address>/96

    Link-Scoped Unicast

    fe80::/10

    Unique-Local

    fc00::/7

    Documentation Prefix

    2001:db8::/32

    6to4

    2002::/16

    6bone

    5f00::/8

    ORCHID

    2001:10::/28

    Teredo

    2001::/32

    Default Route

    ::/0

    Multicast

    ff00::/8

  • The current scaling number for IPv4 probes is a maximum of 500 concurrent probes and the limit on the maximum number of configurable tests is 1000. These scaling parameters are applicable for IPv6 probes. The same scaling limits are applicable, even in cases where both IPv4-based tests and IPv6-based tests are run at the same time.

  • The minimum rate of probes is 1 probe per second and the maximum interval between tests is 86400 seconds. These scaling and performance numbers vary based on whether the Two-Way Active Measurement Protocol (TWAMP) server and client are configured on the same router. This condition occurs because the TWAMP server/client has packet processing in RMOPD and it competes with RPM functionality in the same process. The RTT of IPv6-based RPM and ping utilities must be equivalent for data size. In Routing Engine-based RPM implementation, RTT spikes are seen owing to various queuing delays introduced in the system. This behavior can be noticed even with a single test.

  • Some of the TCP and UDP ports might be opened to communicate between the RPM server and RPM client. Therefore, we recommend that you use firewalls and distributed denial-of-service (DDoS) attack filters to ensure that no security threats are possible by some third-party attackers or hackers.

  • The different packet types that can be used within the probe include:

    • ICMP6 echo

    • UDP echo

    • UDP timestamp

Related Documentation