Configuring Real-Time Performance Monitoring

This section describes the following tasks for configuring RPM:

• Configuring RPM Probes
• Configuring RPM Receiver Servers
• Limiting the Number of Concurrent RPM Probes
• Configuring RPM Timestamping
• Configuring TWAMP

Configuring RPM Probes

The owner name and test name identifiers of an RPM probe together represent a single RPM configuration instance. When you specify the test name, you also can configure the test parameters.

To configure the probe owner, test name, and test parameters, include the probe statement at the [edit services rpm] hierarchy level:

• To specify a probe owner, include the probe statement at the [edit services rpm] hierarchy level. The probe owner identifier can be up to 32 characters in length.
• To specify a test name, include the test statement at the [edit services rpm probe owner] hierarchy level. The test name identifier can be up to 32 characters in length. A test represents the range of probes over which the standard deviation, average, and jitter are calculated.
• To specify the contents of the data portion of Internet Control Message Protocol (ICMP) probes, include the data-fill statement at the [edit services rpm probe owner] hierarchy level. The value can be a hexadecimal value. The data-fill statement is not valid with the http-get or http-metadata-get probe types.
• To specify the size of the data portion of ICMP probes, include the data-size statement at the [edit services rpm probe owner] hierarchy level. The size can be from 0 through 65507 and the default size is 0. The data-size statement is not valid with the http-get or http-metadata-get probe types.

  Note: If you configure the hardware timestamp feature (see Configuring RPM Timestamping), the data-size default value is 32 bytes and 32 is the minimum value for explicit configuration. The UDP timestamp probe type is an exception; it requires a minimum data size of 44 bytes.

• On M Series and T Series routers, you configure the destination-interface statement to enable hardware timestamping of RPM probe packets. You specify an sp- interface to have the AS or Multiservices PIC add the hardware timestamps; for more information, see Configuring RPM Timestamping. You can also include the one-way-hardware-timestamp statement to enable one-way delay and jitter measurements.
• To specify the User Datagram Protocol (UDP) port or Transmission Control Protocol (TCP) port to which the probe is sent, include the destination-port statement at the [edit services rpm probe owner test test-name] hierarchy level. The destination-port statement is used only for the UDP and TCP probe types. The value can be 7 or from 49160 through 65535.
• To specify the value of the Differentiated Services (DiffServ) field within the IP header, include the dscp-code-point statement at the [edit services rpm probe owner test test-name] hierarchy level. The DiffServ code point (DSCP) bits value can be set to a valid 6-bit pattern; for example, 001111. It also can be set using an alias configured at the [edit class-of-service code-point-aliases dscp] hierarchy level. The default is 000000.
• To specify the number of stored history entries, include the history-size statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 0 to 255. The default is 50.
• To specify a number of samples for making statistical calculations, include the moving-average-size statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 0 through 255.
• To specify the number of probes within a test, include the probe-count statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 1 through 15.
• To specify the time to wait between sending packets, include the probe-interval statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 1 through 255 seconds.
• To specify the packet and protocol contents of the probe, include the probe-type statement at the [edit services rpm probe owner test test-name] hierarchy level. The following probe types are supported:
  • http-get—Sends a Hypertext Transfer Protocol (HTTP) get request to a target URL.
  • http-metadata-get—Sends an HTTP get request for metadata to a target URL.
  • icmp-ping—Sends ICMP echo requests to a target address.
  • icmp-ping-timestamp—Sends ICMP timestamp requests to a target address.
  • tcp-ping—Sends TCP packets to a target.
  • udp-ping—Sends UDP packets to a target.
  • udp-ping-timestamp—Sends UDP timestamp requests to a target address.

  The following probe types support hardware timestamping of probe packets: icmp-ping, icmp-ping-timestamp, udp-ping, udp-ping-timestamp.

  Note: Some probe types require additional parameters to be configured. For example, when you specify the tcp-ping or udp-ping option, you must configure the destination port using the destination-port statement. The udp-ping-timestamp option requires a minimum data size of 12; any smaller data size results in a commit error. The minimum data size for TCP probe packets is 1.

• To specify the routing instance used by ICMP probes, include the routing-instance statement at the [edit services rpm probe owner test test-name] hierarchy level. The default routing instance is Internet routing table inet.0.
• To specify the source IP address used for ICMP probes, include the source-address statement at the [edit services rpm probe owner test test-name] hierarchy level. If the source IP address is not one of the router’s assigned addresses, the packet will use the outgoing interface’s address as its source.
• To specify the destination address used for the probes, include the target statement at the [edit services rpm probe owner test test-name] hierarchy level.
  • For HTTP probe types, specify a fully formed URL that includes http:// in the URL address.
  • For all other probe types, specify an IP version 4 (IPv4) address for the target host.
• To specify the time to wait between tests, include the test-interval statement at the [edit services rpm probe owner test test-name] hierarchy level. Specify a value from 0 through 86400 seconds.
• To specify thresholds used for the probes, include the thresholds statement at the [edit services rpm probe owner test test-name] hierarchy level. A system log message is generated when the configured threshold is exceeded. Likewise, an SNMP trap (if configured) is generated when a threshold is exceeded. The following options are supported:
  • egress-time—Measures maximum source-to-destination time per probe.
  • ingress-time—Measures maximum destination-to-source time per probe.
  • jitter-egress—Measures maximum source-to-destination jitter per test.
  • jitter-ingress—Measures maximum destination-to-source jitter per test.
  • jitter-rtt—Measures maximum jitter per test, from 0 through 60000000 microseconds.
  • rtt—Measures maximum round-trip time per probe, in microseconds.
  • std-dev-egress—Measures maximum source-to-destination standard deviation per test.
  • std-dev-ingress—Measures maximum destination-to-source standard deviation per test.
  • std-dev-rtt—Measures maximum standard deviation per test, in microseconds.
  • successive-loss—Measures successive probe loss count, indicating probe failure.
  • total-loss—Measures total probe loss count indicating test failure, from 0 through 15.
• Traps are sent if the configured threshold is met or exceeded. To set the trap bit to generate traps, include the traps statement at the [edit services rpm probe owner test test-name] hierarchy level. The following options are supported:
  • egress-jitter-exceeded—Generates traps when the jitter in egress time threshold is met or exceeded.
  • egress-std-dev-exceeded—Generates traps when the egress time standard deviation threshold is met or exceeded.
  • egress-time-exceeded—Generates traps when the maximum egress time threshold is met or exceeded.
  • ingress-jitter-exceeded—Generates traps when the jitter in ingress time threshold is met or exceeded.
  • ingress-std-dev-exceeded—Generates traps when the ingress time standard deviation threshold is met or exceeded.
  • ingress-time-exceeded—Generates traps when the maximum ingress time threshold is met or exceeded.
  • jitter-exceeded—Generates traps when the jitter in round-trip time threshold is met or exceeded.
  • probe-failure—Generates traps for successive probe loss thresholds crossed.
  • rtt-exceeded—Generates traps when the maximum round-trip time threshold is met or exceeded.
  • std-dev-exceeded—Generates traps when the round-trip time standard deviation threshold is met or exceeded.
  • test-completion—Generates traps when a test is completed.
  • test-failure—Generates traps when the total probe loss threshold is met or exceeded.

Configuring RPM Receiver Servers

The RPM TCP and UDP probes are proprietary to Juniper Networks and require a receiver to receive the probes. To configure a server to receive the probes, include the probe-server statement at the [edit services rpm] hierarchy level:

The port number specified for the UDP and TCP server can be 7 or from 49160 through 65535.

Limiting the Number of Concurrent RPM Probes

To configure the maximum number of concurrent probes allowed, include the probe-limit statement at the [edit services rpm] hierarchy level:

Specify a limit from 1 through 500. The default maximum number is 100.

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 and the RPM server 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.

Configuring TWAMP

You can configure the Two-Way Active Measurement Protocol (TWAMP) on on all M Series and T Series routers that support Multiservices PICs (running in either Layer 2 or Layer 3 mode), and on MX Series routers with or without a Multiservices DPC. Only the responder (server) side of TWAMP is supported.

For more information on TWAMP, see RFC 5357, A Two-Way Active Measurement Protocol (TWAMP).

To configure TWAMP properties, include the twamp statement at the [edit services rpm] hierarchy level:

The TWAMP configuration process includes the following tasks:

• Configuring TWAMP Interfaces
• Configuring TWAMP Servers

Configuring TWAMP Interfaces

To specify the service PIC logical interface that provides the TWAMP service, include the twamp-server statement at the [edit interfaces sp-fpc/pic/port unit logical-unit-number hierarchy level:

Note: On MX Series routers that do not include a Multiservices DPC, you can configure TWAMP properties, but you can omit specifying the twamp-server statement.

Configuring TWAMP Servers

You can specify a number of TWAMP server properties, some of which are optional, by including the server statement at the [edit services rpm twamp] hierarchy level:

• To specify the list of allowed control client hosts that can connect to this server, include the client-list statement at the [edit services rpm twamp server] hierarchy level. Each value you include must be a Classless Interdomain Routing (CIDR) address (IP address plus mask) that represents a network of allowed hosts. You can include multiple client lists, each of which can contain a maximum of 64 entries. You must configure at least one client address to enable TWAMP.
• You must specify the authentication mode by including the authentication-mode statement at the [edit services rpm twamp server] hierarchy level. There is no default value. You can configure authenticated or encrypted mode, based on RFC 4656; if there is no authentication or encryptions mode specified, you should set the value to none. This statement is required in the TWAMP configuration.
• To specify the inactivity timeout period in seconds, include the inactivity-timeout statement at the [edit services rpm twamp server] hierarchy level. By default, the value is 1800; the range is 0 through 3600 seconds.
• To specify the maximum number of concurrent connections the server can have to client hosts, include the maximum-connections statement at the [edit services rpm twamp server] hierarchy level. The allowed range of values is 1 through 2048 and the default value is 64. You can also limit the number of connections the server can make to a particular client host by including the maximum-connections-per-client statement.
• To specify the maximum number of sessions the server can have running at one time, include the maximum-sessions statement at the [edit services rpm twamp server] hierarchy level. The allowed range of values is 1 through 2048 and the default value is 64. You can also limit the number of sessions the server can have on a single connection by including the maximum-sessions-per-connection statement.
• To specify the TWAMP server listening port, include the port statement at the [edit services rpm twamp server] hierarchy level. The range is 1 through 65,535. This statement is mandatory.

For examples of TWAMP configuration, see Examples: Configuring Real-Time Performance Monitoring.