Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

To account for latency in the communication of probe messages, you can enable timestamping of the probe packets. You can timestamp the following RPM probe types: icmp-ping, icmp-ping-timestamp, udp-ping, and udp-ping-timestamp.

On M Series and T Series routers with an MS-PIC, on MX Series routers with an MS-DPC, MS-MIC, or MS-MPC linecard, on MX10000 Series routers, on PTX10008 and PTX10016 routers, and on EX Series switches, you can enable hardware timestamping of RPM probe messages. The timestamp is applied on both the RPM client device (the router or switch that originates the RPM probes) and the RPM probe server and applies only to IPv4 traffic. It is supported on the following:

  • Layer 2 service package on MS-PICs, MS-DPCs, MS-MPCs, and MS-MICs.

  • Layer 3 service package on MS-PICs, MS-DPCs, MS-MPCs, and MS-MICs.

  • Extension-provider services package on M Series, MX Series, and T Series services PICs that support the Extension-Provider packages (In Junos OS releases earlier than Release 12.3, the extension-provider packages were variously referred to as Junos Services Framework (JSF), MP-SDK, and eJunos.)

  • Layer 2, Layer 3, SDK Services, and PFE RPM timestamping interoperate with each other. Here, the RPM client can be on the Layer 3 sp- interface and the RPM server can be on an SDK Services package.

Two-way timestamping is available on sp- and ms- interfaces. To configure two-way timestamping on M Series and T Series routers, include the destination-interface statement at the [edit services rpm probe probe-owner test test-name] hierarchy level:

Specify the RPM client router and the RPM server router on the services logical interface or the multiservices interface by including the rpm statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level:

The logical interface must be dedicated to the RPM task. It requires configuration of the family inet statement and a /32 address, as shown in the example. This configuration is also needed for other services such as NAT and stateful firewall. You cannot configure RPM service on unit 0 because RPM requires a dedicated logical interface; the same unit cannot support both RPM and other services. Because active flow monitoring requires unit 0, but RPM can function on any logical interface, a constraint check prevents you from committing an RPM configuration there.

On MX Series routers, on M320 Series routers using the Enhanced Queuing MPC, and on EX Series switches, you include the hardware-timestamp statement at the [edit services rpm probe probe-name test test-name] hierarchy level to specify that the probes are to be timestamped in the Packet Forwarding Engine host processor:

On MX Series routers, on MX10000 Series routers, PTX10008 and PTX10016 routers, and EX Series switches, you can include the hardware-timestamp statement at the [edit services rpm probe probe-name test test-name] hierarchy level to specify that the probes are to be timestamped in the Packet Forwarding Engine host processor. On MX Series routers, hardware timestamping is supported on the following line cards:

  • DPC

  • DPCE

  • MPC1

  • MPC2

  • MPC3

  • MPC4

  • MPC5

  • MPC6

  • MPC7

On the client side, these probes are timestamped in the Packet Forwarding Engine host processor on the egress DPC on the MX Series or M320 Series router or EX Series switch originating the RPM probes (RPM client). On the responder side (RPM server), the RPM probes to be timestamped are handled by the Packet Forwarding Engine host processor, which generates the response instead of the RPM process. The RPM probes are timestamped only on the router that originates them (RPM client). As a result, only round-trip time is measured for these probes.

When using the hardware-timestamp statement, the data-size value for the probe must be at least 100 bytes smaller than the default MTU of the interface of the RPM client interface (see Configuring RPM Probes on M, MX and T Series Routers and EX Series Switches). If hardware timestamping of RPM probe messages is enabled, the maximum data size that you can configure by using the data-size statement is limited to 1400.

Note:

The Packet Forwarding Engine-based RPM feature does not support any stateful firewall configurations. If you need to combine RPM timestamping with a stateful firewall, use the interface-based RPM timestamping service described earlier in this section. MS-DPCs support stateful firewall processing as well as RPM timestamping.

To configure one-way timestamping, you must also include the one-way-hardware-timestamp statement at the [edit services rpm probe probe-owner test test-name] hierarchy level:

Note:

If you configure RPM probes for a services interface (sp-), you need to announce local routes in a specific way for the following routing protocols:

  • For OSPF, you can announce the local route by including the services interface in the OSPF area. To configure this setting, include the interface sp-fpc/pic/port statement at the [edit protocols ospf area area-number] hierarchy level.

  • For BGP and IS-IS, you must export interface routes and create a policy that accepts the services interface local route. To export interface routes, include the point-to-point and lan statements at the [edit routing-options interface-routes family inet export] hierarchy level. To configure an export policy that accepts the services interface local route, include the protocol local, rib inet.0, and route-filter sp-interface-ip-address/32 exact statements at the [edit policy-options policy-statement policy-name term term-name from] hierarchy level and the accept action at the [edit policy-options policy-statement policy-name term term-name then] hierarchy level. For the export policy to take effect, apply the policy to BGP or IS-IS with the export policy-name statement at the [edit protocols protocol-name] hierarchy level.

For more information about these configurations, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Routing the probe packets through the multiservices card also enables you to filter the probe packets to particular queues. The following example shows the RPM configuration and the filter that specifies queuing:

For more information about firewall filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide; for more information about queuing, see the Class of Service User Guide (Routers and EX9200 Switches).