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:
destination-interface sp-fpc/pic/port.logical-unit destination-interface ms-fpc/pic/port.logical-unit
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:
rpm (client | server);
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, on PTX5000, PTX10008, and PTX10016 routers, and
on 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
hardware-timestamp;
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.
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:
one-way-hardware-timestamp;
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/portstatement 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-pointandlanstatements 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 theprotocol local,rib inet.0, androute-filter sp-interface-ip-address/32 exactstatements at the[edit policy-options policy-statement policy-name term term-name from]hierarchy level and theacceptaction 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 theexport policy-namestatement 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:
services rpm {
probe p1 {
test t1 {
probe-type icmp-ping;
target address 10.8.4.1;
probe-count 10;
probe-interval 10;
test-interval 10;
dscp-code-points af11;
data-size 100;
destination-interface sp-1/2/0.0;
}
}
}
firewall {
filter f1 {
term t1 {
from {
dscp af11;
}
then {
forwarding-class assured-forwarding;
}
}
}
}
interfaces sp-1/2/0 {
unit 2 {
rpm client;
family inet {
address 10.8.4.2/32;
filter {
input f1;
}
}
}
}
interfaces sp-1/2/1 {
unit 2 {
rpm server;
family inet {
address 10.8.3.2/32;
filter {
input f1;
}
}
}
}
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).