Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

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.

• Layer 2 services package on all Mulitservices PICs and DPCs.
• Layer 3 service package on AS and Multiservices PICs and Multiservices DPCs.
• 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 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.

  Note: Hardware timestamping is not supported on PTX Series Packet Transport Routers.

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 adaptive 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.

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 and 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 the client side, these probes are timestamped in the Packet Forwarding Engine host processor on the egress DPC on the MX 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.

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, 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 Routing Policy Feature Guide for Routing Devices or the Junos OS Routing Protocols Library for Routing Devices.

Routing the probe packets through the adaptive services 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 Routing Policy Feature Guide for Routing Devices; for more information about queuing, see the Junos OS Class of Service Library for Routing Devices.