Configuring RPM Timestamping

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 Adaptive Services (AS) or Multiservices PIC, and MX Series routers with a Multiservices DPC, you can enable hardware timestamping of RPM probe messages. The timestamp is applied on both the RPM client router (the router that originates the RPM probes) and the RPM probe server and applies only to IPv4 traffic. It is supported in the Layer 2 service package on all Multiservices PICs and DPCs and in the Layer 3 service package on AS and Multiservices PICs and Multiservices DPCs.

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 on the adaptive services logical 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.

Note: If you configure RPM timestamping on an AS PIC, you cannot configure the source-address statement at the [edit services rpm probe probe-name test test-name] hierarchy level.

On MX Series routers, 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 the client side, these probes are timestamped in the Packet Forwarding Engine host processor on the egress DPC on the MX Series router originating the RPM probes (RPM client). On the responder side (RPM server), the RPM probes to be timestamped are handled by 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.

Note: The Packet Forwarding Engine based RPM feature does not support any stateful firewall configurations. If you need to combine RPM timestamping with stateful firewall, you should use the interface-based RPM timestamping service described earlier in this section. Multiservices 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 Junos Policy Framework Configuration Guide or the Junos Routing Protocols Configuration Guide.

Routing the probe packets through the AS or Multiservices PIC 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 Junos Policy Framework Configuration Guide; for more information about queuing, see the Junos Class of Service Configuration Guide.