Segment Routing Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Network performance metrics is a critical measure for traffic engineering (TE) in service provider networks. Network performance
metrics include the following:
Packet loss
Delay
Delay variation
Bandwidth utilization
These network performance metrics provide network operators information about the performance characteristics of their networks
for performance evaluation and help to ensure compliance with service level agreements. The service-level agreements (SLAs)
of service providers depend on the ability to measure and monitor these network performance metrics. Network operators can
use Segment Routing Performance Measurement (SR-PM) feature to monitor the network metrics for links and end-to-end TE label
switched paths (LSPs).
The following table explains the functionalities supported by performance measurement feature for measuring delay for links
or SR policies.
Table 1. Performance Measurement Functionalities
Functionality
Details
Profiles
You can configure different profiles for different types of delay measurements. Delay profile type interfaces is used for
link-delay measurement. Delay profile type sr-policy is used for SR policy delay measurements. Delay profile allows you to schedule probe and configure metric advertisement parameters for delay measurement.
Protocols
Two-Way Active Measurement Protocol (TWAMP) Light (using RFC 5357 with IP/UDP encap).
Probe and burst scheduling
Schedule probes and configure metric advertisement parameters for delay measurement.
Metric advertisements
Advertise measured metrics periodically using configured thresholds. Also supports accelerated advertisements using configured
thresholds.
Measurement history and counters
Maintain packet delay and loss measurement history and also session counters and packet advertisement counters.
Liveness Monitoring
Liveness refers to the ability of the network to confirm that a specific path, segment, or a node is operational and capable
of forwarding packets. Liveness checks are essential for maintaining network availability and reliability.
Benefits
Fault Detection: You can quickly identify if a device is down, which allows for immediate response and troubleshooting.
Load Balancing: You can identify if the devices in a network are live, so work can be distributed more evenly across the network, preventing
overloading of specific components and improving overall performance.
System Health: You can provide an ongoing snapshot of a system's health, helping to identify potential issues before they become significant
problems.
Maintenance Planning: Liveness information can also help with maintenance planning, as system administrators can understand which components are
live or down and plan maintenance and downtime accordingly without significant disruption to services.
Security: Regular liveness checks can also play a role in maintaining network security. Administrators can take proactive steps to
mitigate the damage and prevent future incidents by identifying unusual activity that might indicate a security breach or
attack.
You can determine liveness for SR Policy and IP Endpoint.
Delay Measurement
Delay measuremnt is a mechanism used to measure the latency or delay experienced by data packets when they traverse a network.
The PM for delay measuremnt uses the IP/UDP packet format defined in RFC 5357 (TWAMP-Light) for probes. Two-Way Active Measurement
Protocol (TWAMP) adds two-way or round-trip measurement capabilities. TWAMP employs time stamps applied at the echo destination
(reflector) to enable greater accuracy. In the case of TWAMP Light, the Session-Reflector doesn’t necessarily know about the
session state. The Session-Reflector simply copies the Sequence Number of the received packet to the Sequence Number field
of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture
allows for collection of two-way metrics.
Benefits
Network Troubleshooting: You can quickly and easily identify areas in your network with high delay and resolve network problems
using delay measurement.
Network Planning and Optimization: You can easily understand the performance of your network under various conditions and
design a network that can handle expected traffic loads.
Quality of Service (QoS): You can ensure quality of service standards are being met by continuously monitoring the delay in
your network.
Supported Delay Measurement Methods
You can measure delay using the following methods:
Use to monitor delay experienced by data packets in a single link or path between two nodes in a network.
: Use to monitor the amount of time it takes for a data packet to travel from a source device to a specific IP endpoint within
a network.
: Use to to monitor the end-to-end delay experienced by the traffic sent over an SR policy.
Link Delay Measurement
Table 2. Feature History Table
Feature Name
Release Information
Feature Description
Link Delay Measurement using TWAMP Light Encoding
Release 7.3.1
The PM for link delay uses the IP/UDP packet format defined in RFC 5357 (TWAMP-Light) for probes. Two-Way Active Measurement
Protocol (TWAMP) adds two-way or round-trip measurement capabilities. TWAMP employs time stamps applied at the echo destination
(reflector) to enable greater accuracy.
The PM for link delay uses the IP/UDP packet format defined in RFC 5357 (TWAMP-Light) for probes. Two-Way Active Measurement
Protocol (TWAMP) adds two-way or round-trip measurement capabilities. TWAMP employs time stamps applied at the echo destination
(reflector) to enable greater accuracy. In the case of TWAMP Light, the Session-Reflector doesn’t necessarily know about the
session state. The Session-Reflector simply copies the Sequence Number of the received packet to the Sequence Number field
of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture
allows for collection of two-way metrics.
The following figure explains the PM query and response for link delay.
Figure 1. Performance Measurement for Link Delay
The PM query and response for link delay can be described in the following steps:
The local-end router sends PM query packets periodically to the remote side once the egress line card on the router applies
timestamps on packets.
Ingress line card on the remote-end router applies time-stamps on packets as soon as they are received.
The remote-end router sends the PM packets containing time-stamps back to the local-end router. The remote-end router time-stamps
the packet just before sending it for two-way measurement.
The local-end router time-stamps the packet as soon as the packet is received for two-way measurement.
One-way delay and optionally two-way delay is measured using the time-stamp values in the PM packet.
Restrictions and Usage Guidelines for PM for Link Delay
The following restrictions and guidelines apply for the PM for link delay feature for different links.
For LSPs, remote-end line card needs to be MPLS and multicast MAC address capable.
For broadcast links, only point-to-point (P2P) links are supported. P2P configuration on IGP is required for flooding the
value.
For link bundles, the hashing function may select a member link for forwarding but the reply may come from the remote line
card on a different member link of the bundle.
For one-way delay measurement, clocks should be synchronized on two end-point nodes of the link using PTP.
Link delay measurement is supported on IPv4 unnumbered interfaces. An IPv4 unnumbered interface is identified by a node ID
(a loopback address) and the local SNMP index assigned to the interface. Note that the reply messages could be received on
any interface, since the packets are routed at the responder based on the loopback address used to identify the link.
Configuration Example: PM for Link Delay
This example shows how to configure performance-measurement functionalities for link delay as a global default profile. The
default values for the different parameters in the PM for link delay is given as follows:
probe measurement mode: The default measurement mode for probe is two-way delay measurement. If you are configuring one-way delay measurement, hardware
clocks must be synchronized between the local-end and remote-end routers using precision time protocol (PTP).
protocol: Interface delay measurement uses TWAMP-Light (RFC5357) with IP/UDP encap.
burst-interval: Interval for sending probe packet. The default value is 3000 milliseconds and the range is from 30 to 15000 milliseconds.
computation interval: Interval for metric computation. Default is 30 seconds; range is 1 to 3600 seconds.
periodic advertisement: Periodic advertisement is enabled by default.
periodic-advertisement interval: The default value is 120 seconds and the interval range is from 30 to 3600 seconds.
periodic-advertisement threshold: The default value of periodic advertisement threshold is 10 percent.
periodic-advertisement minimum change: The default value is 1000 microseconds (usec) and the range is from 0 to 10000 microseconds.
accelerated advertisement: Accelerated advertisement is disabled by default.
accelerated-advertisement threshold: The default value is 20 percent and the range is from 0 to 100 percent.
accelerated-advertisement minimum change: The default value is 1000 microseconds and the range is from 1 to 100000 microseconds.
Configuring the UDP port for TWAMP-Light protocol is optional. By default, PM uses port 862 as the TWAMP-reserved UDP destination
port.
The UDP port is configured for each PM measurement probe type (delay, loss, protocol, authentication mode, etc.) on querier
and responder nodes. If you configure a different UDP port, the UDP port for each PM measurement probe type must match on
the querier and the responder nodes.
Note
The same UDP destination port is used for delay measurement for links and SR Policy.
This example shows how to configure the UDP destination port.
RP/0/0/CPU0:router# show performance-measurement summary detail location 0/2/CPU0
Thu Dec 12 14:09:59.162 PST
-------------------------------------------------------------------------------
0/2/CPU0
-------------------------------------------------------------------------------
Total interfaces : 1
Total SR Policies : 0
Total RSVP-TE tunnels : 0
Total Maximum PPS : 2000 pkts/sec
Total Interfaces PPS : 0 pkts/sec
Maximum Allowed Multi-hop PPS : 2000 pkts/sec
Multi Hop Requested PPS : 0 pkts/sec (0% of max allowed)
Dampened Multi Hop Requested PPS : 0% of max allowed
Inuse Burst Interval Adjustment Factor : 100% of configuration
Interface Delay-Measurement:
Total active sessions : 1
Counters:
Packets:
Total sent : 26
Total received : 26
Errors:
TX:
Reason interface down : 0
Reason no MPLS caps : 0
Reason no IP address : 0
Reason other : 0
RX:
Reason negative delay : 0
Reason delay threshold exceeded : 0
Reason missing TX timestamp : 0
Reason missing RX timestamp : 0
Reason probe full : 0
Reason probe not started : 0
Reason control code error : 0
Reason control code notif : 0
Probes:
Total started : 3
Total completed : 2
Total incomplete : 0
Total advertisements : 0
SR Policy Delay-Measurement:
Total active sessions : 0
Counters:
Packets:
Total sent : 0
Total received : 0
Errors:
TX:
Reason interface down : 0
Reason no MPLS caps : 0
Reason no IP address : 0
Reason other : 0
RX:
Reason negative delay : 0
Reason delay threshold exceeded : 0
Reason missing TX timestamp : 0
Reason missing RX timestamp : 0
Reason probe full : 0
Reason probe not started : 0
Reason control code error : 0
Reason control code notif : 0
Probes:
Total started : 0
Total completed : 0
Total incomplete : 0
Total advertisements : 0
RSVP-TE Delay-Measurement:
Total active sessions : 0
Counters:
Packets:
Total sent : 0
Total received : 0
Errors:
TX:
Reason interface down : 0
Reason no MPLS caps : 0
Reason no IP address : 0
Reason other : 0
RX:
Reason negative delay : 0
Reason delay threshold exceeded : 0
Reason missing TX timestamp : 0
Reason missing RX timestamp : 0
Reason probe full : 0
Reason probe not started : 0
Reason control code error : 0
Reason control code notif : 0
Probes:
Total started : 0
Total completed : 0
Total incomplete : 0
Total advertisements : 0
Global Delay Counters:
Total packets sent : 26
Total query packets received : 26
Total invalid session id : 0
Total missing session : 0
RP/0/0/CPU0:router# show performance-measurement interfaces detail
Thu Dec 12 14:16:09.692 PST
-------------------------------------------------------------------------------
0/0/CPU0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
0/2/CPU0
-------------------------------------------------------------------------------
Interface Name: GigabitEthernet0/2/0/0 (ifh: 0x1004060)
Delay-Measurement : Enabled
Loss-Measurement : Disabled
Configured IPv4 Address : 10.10.10.2
Configured IPv6 Address : 10:10:10::2
Link Local IPv6 Address : fe80::3a:6fff:fec9:cd6b
Configured Next-hop Address : Unknown
Local MAC Address : 023a.6fc9.cd6b
Next-hop MAC Address : 0291.e460.6707
Primary VLAN Tag : None
Secondary VLAN Tag : None
State : Up
Delay Measurement session:
Session ID : 1
Last advertisement:
Advertised at: Dec 12 2019 14:10:43.138 (326.782 seconds ago)
Advertised reason: First advertisement
Advertised delays (uSec): avg: 839, min: 587, max: 8209, variance: 297
Next advertisement:
Threshold check scheduled in 1 more probe (roughly every 120 seconds)
Aggregated delays (uSec): avg: 751, min: 589, max: 905, variance: 112
Rolling average (uSec): 756
Current Probe:
Started at Dec 12 2019 14:15:43.154 (26.766 seconds ago)
Packets Sent: 9, received:9
Measured delays (uSec): avg: 795, min: 631, max: 1199, variance: 164
Next probe scheduled at Dec 12 2019 14:16:13.132 (in 3.212 seconds)
Next burst packet will be sent in 0.212 seconds
Burst packet sent every 3.0 seconds
Probe samples:
Packet Rx Timestamp Measured Delay (nsec)
Dec 12 2019 14:15:43.156 689223
Dec 12 2019 14:15:46.156 876561
Dec 12 2019 14:15:49.156 913548
Dec 12 2019 14:15:52.157 1199620
Dec 12 2019 14:15:55.156 794008
Dec 12 2019 14:15:58.156 631437
Dec 12 2019 14:16:01.157 656440
Dec 12 2019 14:16:04.157 658267
Dec 12 2019 14:16:07.157 736880
You can also use the following commands for verifying the PM for link delay on the local-end router.
Command
Description
show performance-measurement history probe interfaces [interface]
Displays the PM link-delay probe history for interfaces.
show performance-measurement history aggregated interfaces [interface]
Displays the PM link-delay aggregated history for interfaces.
show performance-measurement history advertisement interfaces [interface]
Displays the PM link-delay advertisement history for interfaces.
show performance-measurement counters [interface interface] [location location-name]
Displays the PM link-delay session counters.
You can also use the following commands for verifying the PM for link-delay configuration on the remote-end router.
Command
Description
show performance-measurement responder summary [locationlocation-name]
Displays the PM for link-delay summary on the remote-end router (responder).
show performance-measurement responder interfaces [interface]
Displays PM for link-delay for interfaces on the remote-end router.
show performance-measurement responder counters [interfaceinterface] [locationlocation-name]
Displays the PM link-delay session counters on the remote-end router.
Delay Normalization
Performance measurement (PM) measures various link characteristics like packet loss and delay. Such characteristics can be
used by IS-IS as a metric for Flexible Algorithm computation. Low latency routing using dynamic delay measurement is one of
the primary use cases for Flexible Algorithm technology.
Delay is measured in microseconds. If delay values are taken as measured and used as link metrics during the IS-IS topology
computation, some valid ECMP paths might be unused because of the negligible difference in the link delay.
The Delay Normalization feature computes a normalized delay value and uses the normalized value instead. This value is advertised
and used as a metric during the Flexible Algorithm computation.
The normalization is performed when the delay is received from the delay measurement component. When the next value is received,
it is normalized and compared to the previous saved normalized value. If the values are different, then the LSP generation
is triggered.
The following formula is used to calculate the normalized value:
Dm – measured Delay
Int – configured normalized Interval
Off – configured normalized Offset (must be less than the normalized interval Int)
Dn – normalized Delay
a = Dm / Int (rounded down)
b = a * Int + Off
If the measured delay (Dm) is less than or equal to b, then the normalized delay (Dn) is equal to b. Otherwise, Dn is b + Int.
Example
The following example shows a low-latency service. The intent is to avoid high-latency links (1-6, 5-2). Links 1-2 and 5-6
are both low-latency links. The measured latency is not equal, but the difference is insignificant.
We can normalize the measured latency before it is advertised and used by IS-IS. Consider a scenario with the following:
Interval = 10
Offset = 3
The measured delays will be normalized as follows:
Dm = 29
a = 29 / 10 = 2 (2.9, rounded down to 2)
b = 2 * 10 + 3 = 23
In this case, Dm (29) is greater than b (23); so Dn is equal to b+I (23 + 10) = 33
Dm = 31
a = 31 / 10 = 3 (3.1, rounded down to 3)
b = 3 * 10 + 3 = 33
In this case, Dm (31) is less than b (33); so Dn is b = 33
The link delay between 1-2 and 5-6 is normalized to 33.
Configuration
Delay normalization is disabled by default. To enable and configure delay normalization, use the delay normalize intervalinterval [offsetoffset] command.
interval – The value of the normalize interval in microseconds.
offset – The value of the normalized offset in microseconds. This valude must be smaller than the value of normalized interval.
This feature measures the end-to-end delay and monitors liveness of a specified IP endpoint node, including VRF-aware (awareness
of multiple customers belonging to different VRFs).
This feature is supported on IPv4, IPv6, and MPLS data planes.
Delay for an IP endpoint is the amount of time it takes for a data packet to travel from a source device to a specific IP
endpoint within a network.
To measure a delay for a packet, also called a probe, is sent from a source device to the target IP endpoint.
The time from when the packet leaves the source to when it arrives at the endpoint is measured and recorded as the delay.
You can measure one-way delay, Two-way delay, and Roundtrip delay or delay in loop-back mode. For more information on Delay
measurement, see Link Delay Measurement and Measurement Modes.
Collecting IP Endpoint Probe Statistics
Statistics associated with the probe for delay metrics are available via Histogram and Streaming Telemetry.
Model Driven Telemetry (MDT) is supported for the following data:
Summary, endpoint, session, and counter show command bags.
History buffers data
Model Driven Telemetry (MDT) and Event Driven Telemetry (EDT) are supported for the following data:
Delay metrics computed in the last probe computation-interval (event: probe-completed)
Delay metrics computed in the last aggregation-interval; that is, end of the periodic advertisement-interval (event: advertisement-interval
expired)
Delay metrics last notified (event: notification-triggered)
SRv6 Endpoint Delay in Default VRF (Endpoint can be Node SID, Flex-Algo SID, Packed uSID carrier)
IPv6 Endpoint Delay in VRF (static uDT6)
IPv6 Endpoint Delay in VRF (dynamic uDT6 encap)
IPv4 Endpoint Delay in VRF or GRT (static uDT4)
IPv4 Endpoint Delay in VRF or GRT (dynamic uDT4 encap)
Guidelines and Limitations
You can specify a custom labeled path through one or more user-configured segment-lists. User-configured segment-list represents
the forwarding path from sender to reflector when the probe is configured in delay-measurement mode.
SR PM is supported on hardware that supports Precision Time Protocol (PTP). This requirement applies to both one-way and two-way
delay measurement.
See the "Configuring Precision Time Protocol" chapter in the System Management Configuration Guide for Cisco 8000 Series Routers for Restrictions for PTP and the Timing Hardware Support Matrix.
Examples of the custom segment-list include:
Probe in delay-measurement mode with a segment-list that includes Flex-Algo prefix SID of the endpoint
Probe in delay-measurement mode with a segment-list that includes a SID-list with labels to reach the endpoint or the sender
(forward direction)
Probe in delay-measurement mode with a segment-list that includes BSID associated with SR policy to reach the end point.
Endpoint segment list configuration is not supported under nondefault VRF.
IP Endpoint Liveness Detection in an SR MPLS Network
IP endpoint liveness detection leverages the loopback measurement-mode. The following workflow describes the sequence of events.
The sender creates and transmits the PM probe packets.
The IP destination address (DA) on the probe packets is set to the loopback value of the sender itself.
The transmit timestamp (T1) is added to the payload.
The probe packet is encapsulated with the label corresponding to the endpoint.
The network delivers the PM probe packets following the LSP toward the endpoint.
The end-point receives the PM probe packets.
Packets are forwarded back to the sender based on the forwarding entry associated with the IP DA of the PM probe packet. If
an LSP exists, the probe packet is encapsulated with the label of the sender.
The sender node receives the PM probe packets.
The received timestamp (T4) stored.
If the sender node doesn't receive the specified number of probe packets (based on the configured multiplier), the sender
node declares the PM session as down.
The following figure illustrates a liveness detection probe toward an IP endpoint learned by the IGP. The network interconnecting
the sender and reflector provides MPLS connectivity with Segment Routing.
The liveness detection multiplier is set to 5 to specify the number of consecutive missed probe packets before the PM session
is declared as down.
Feedback