Liveness Monitoring
|
Feature Name |
Release |
Description |
|---|
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.
IP Endpoint Liveness Monitoring
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
IP Endpoint Delay Measurement and Liveness Monitoring |
Release 7.4.1 |
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. |
The Segment Routing Performance Measurement (SR-PM) for IP endpoint liveness is a type of node liveness that involves testing whether an IP endpoint or a device identified by an IP address is available to send and receive data.
IP endpoint liveness is verified by sending a request to the IP address of the endpoint and waiting for a response. The probe could be an ICMP echo request (Ping), a TCP packet, a UDP packet, or any other type of packet that the endpoint would respond to.
-
If a response is received, the endpoint is considered live.
-
If no response is received within a certain time frame, the endpoint is considered down or unreachable.
IP endpoint dynamically measures the liveness towards a specified IP endpoint. IP endpoints can be located in a default or nondefault VRFs. IP endpoint is any device in the network a device identified by an IP address.
Liveness of an IP endpoint is verified by sending a request to the IP address of the endpoint and waiting for a response, which is referred to as a probe.
The endpoint of a probe is defined by an IP address, which can be either IPv4 or IPv6. This IP address can be any address that the sender can reach, such as a local interface or a remote node or host, either within an operator's network or accessible via a VRF.
The endpoint of a probe can be any IP address reachable by the sender. For example, a local interface or a remote node or host located within an operator's network or reachable through a VRF.
The IP address of the endpoint can be reached through an IP path, MPLS, LSP , or IP tunnel (GRE).
-
When the endpoint is reachable using an MPLS LSP (for example, SR, LDP, RSVP-TE, SR Policy), the forwarding stage imposes the corresponding MPLS transport labels.
-
When the endpoint is reachable via a GRE tunnel, the forwarding stage imposes the corresponding GRE header.
-
When the endpoint is reachable via a VRF in an MPLS network, the forwarding stage imposes the corresponding MPLS service labels. In the forward path, the sender node uses the configured VRF for the endpoint address. In the return path, the reflector node derives the VRF based on which incoming VRF label the probe packet is received with.
You can configure the following parameters in the performance-measurement command:
-
Endpoint: The endpoint of a probe is defined by an IP address, which can be either IPv4 or IPv6. This IP address can be any address that the sender can reach, such as a local interface or a remote node or host, either within an operator's network or accessible via a VRF.
The endpoint of a probe can be any IP address reachable by the sender. For example, a local interface or a remote node or host located within an operator's network or reachable through a VRF.
Use the performance-measurement endpoint command to configure a probe endpoint source and destination addresses on a sender node.
-
VRF: You can define the endpoint point IP address belonging to a specific VRF. Use the performance-measurement endpoint {ipv4 | ipv6} ip_addr [vrf WORD] command to configure an endpoint to define the VRF. Endpoint segment list configuration is not supported under nondefault VRF.
-
VRF-awareness allows operators to deploy probes in the following scenarios:
-
Managed Customer Equipment (CE) scenarios:
-
PE to CE probes
-
CE to CE probes
-
-
Unmanaged Customer Equipment (CE) scenarios:
-
PE to PE probes
-
PE to PE (source from PE-CE interface) probes
-
-
-
-
Source address: You can define the source of the endpoint using the endpoint specific source address and the global source address.
Global source address configuration is applied to all the endpoints when the endpoint specific source address configuration isn’t specified. endpoint specific configuration overrides all the global source address configuration for those specific endpoints for which source addresses are configured.
For Micro-SID configuration for IPv4 endpoint sessions, if IPv6 global source address is configured, then it applies the configured global IPv6 source address for the IPv6 header in the SRv6 packet. If IPv6 global address is not configured, then It does not form a valid SRv6 packet.
You can use the source-address keyword under the performance-measurement command to define the global source address or use the keyword under performance-measurement endpoint to define endpoint specific source address.
Usage Guidelines and Limitations
-
Liveness session without segment list for an endpoint in a non-default VRF is not supported.
-
SR Performance Measurement endpoint session over BVI interface is not supported.
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.
Configuration Example
RouterA(config)# performance-measurement
RouterA(config-perf-meas)# endpoint ipv4 10.1.1.5
RouterA(config-pm-ep)# source-address ipv4 10.1.1.1
RouterA(config-pm-ep)# liveness-detection
RouterA(config-pm-ep-ld)# exit
RouterA(config-pm-ep)# exit
RouterA(config-perf-meas)# liveness-profile endpoint default
RouterA(config-pm-ld-ep)# liveness-detection
RouterA(config-pm-ld-ep-ld)# multiplier 5
RouterA(config-pm-ld-ep-ld)# exit
Running Configuration
performance-measurement
endpoint ipv4 10.1.1.5
source-address ipv4 10.1.1.1
liveness-detection
!
!
liveness-profile endpoint default
liveness-detection
multiplier 5
!
!
!
end
Verification
RouterA# show performance-measurement endpoint ipv4 10.1.1.5
--------------------------------------------------------------------------------
0/RSP0/CPU0
--------------------------------------------------------------------------------
Endpoint name: IPv4-10.1.1.5-vrf-default
Source address : 10.1.1.1
VRF name : default
Liveness Detection : Enabled
Profile Keys:
Profile name : default
Profile type : Endpoint Liveness Detection
Segment-list : None
Session State: Down
Missed count: 0
SR Policy Liveness Monitoring
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
SR Performance Measurement Named Profiles |
Release 7.3.1 |
You can use this feature to create specific performance measurement delay and liveness profiles, and associate it with an SR policy. This way, a delay or liveness profile can be associated with a policy for which the performance measurement probes are enabled, and performance measurement is precise, and enhanced. The performance-measurement delay-profile sr-policy command was updated with the name profile keyword-argument combination. The performance-measurement liveness-profile sr-policy command was updated with the name profile keyword-argument combination. The performance-measurement delay-measurement command was updated with delay-profile name profile . The performance-measurement liveness-detection command was updated with liveness-profile name profile |
|
SR Policy Liveness Monitoring |
Release 7.3.1 |
This feature allows you to verify end-to-end traffic forwarding over an SR Policy candidate path by periodically sending performance monitoring packets. |
SR Policy liveness monitoring allows you to verify end-to-end traffic forwarding over an SR Policy candidate path by periodically sending performance monitoring (PM) packets. The head-end router sends PM packets to the SR policy's endpoint router, which sends them back to the head-end without any control-plane dependency on the endpoint router.
The following are benefits to using SR-PM liveness monitoring:
-
Allows both liveness monitoring and delay measurement using a single-set of PM packets as opposed to running separate monitoring sessions for each purpose. This improves the overall scale by reducing the number of PM sessions required.
-
Eliminates network and device complexity by reducing the number of monitoring protocols on the network (for example, no need for Bidirectional Failure Detection [BFD]). It also simplifies the network and device operations by not requiring any signaling to bootstrap the performance monitoring session.
-
Improves interoperability with third-party nodes because signaling protocols aren't required. In addition, it leverages the commonly supported TWAMP protocol for packet encoding.
-
Improves liveness detection time because PM packets aren't punted on remote nodes
-
Provides a common solution that applies to data-planes besides MPLS, including IPv4, IPv6, and SRv6.
How it works?
The workflow associated with liveness detection over SR policy is described in the following sequence.
Consider an SR policy programmed at head-end node router 1 towards end-point node router 5. This SR policy is enabled for liveness detection using the loopback measurement-mode.
-
A: The head-end node creates and transmits the PM probe packets.
The IP destination address (DA) on the probe packets is set to the loopback value of the head-end node itself.
A transmit (Tx) timestamp is added to the payload.
Optionally, the head-end node may also insert extra encapsulation (labels) to enforce the reverse path at the endpoint node.
Finally, the packet is injected into the data-plane using the same encapsulation (label stack) of that of the SR policy being monitored.
-
B: The network delivers the PM probe packets as it would user traffic over the SR policy.
-
C: The end-point node receives the PM probe packets.
Packets are switched back based on the forwarding entry associated with the IP DA of the packet. This would typically translate to the end-point node pushing the prefix SID label associated with the head-end node.
If the head-end node inserted label(s) for the reverse path, then the packets are switched back at the end-point node based on the forwarding entry associated with the top-most reverse path label.
-
D: Headend node receives the PM probe packets.
A received (Rx) timestamp stored.
If the head-end node receives the PM probe packets, the head-end node assume that the SR policy active candidate path is up and working.
If the head-end node doesn't receive the specified number of consecutive probe packets (based on configured multiplier), the head-end node assumes the candidate path is down and a configured action is trigerred.
Usage Guidelines and Limitations
The following usage guidelines and limitations apply:
-
SR-PM liveness-detection over SR Policy is supported on manually configured SR Policies and On-Demand SR Policies (ODN).
-
SR-PM liveness-detection over SR Policy is not supported on PCE-initiated SR Policies.
-
SR-PM liveness-detection and delay-measurement aren't supported together
-
When liveness-profile isn't configured, SR Policies use the default values for the liveness-detection profile parameters.
Configure SR Policy Liveness Monitoring in an MPLS Network
Configuring SR Policy liveness monitoring involves the following steps:
-
Configuring a performance measurement liveness profile to customize generic probe parameters
-
Enabling liveness monitoring under SR Policy by associating a liveness profile, and customizing SR policy-specific probe parameters
Liveness monitoring parameters are configured under performance-measurement liveness-profile sub-mode. The following parameters are configurable:
-
liveness-profile {sr-policy default | name name}
Parameters defined under the sr-policy default liveneness-profile apply to any SR policy with liveness monitoring enabled and that does not reference a non-default (named) liveneness-profile.
-
probe: Configure the probe parameters.
-
tx-interval: Interval for sending probe packet. The default value is 3000000 microseconds and the range is from 30000 to 15000000 microseconds.
-
tos dscp value: The default value is 48 and the range is from 0 to 63. You can modify the DSCP value of the probe packets, and use this value to priortize the probe packets from headend to tailend.
-
sweep destination ipv4 127.x.x.x range range: Configure SR Policy ECMP IP-hashing mode. Specifiy the number of IP addresses to sweep. The range is from 0 (default, no sweeping) to 128. The option is applicable to IPv4 packets.
Note
The destination IPv4 headendaddress 127.x.x.x – 127.y.y.y is used in the Probe messages to take advantages of 3-tuple IP hashing (source-address, destination-address, and local router ID) for ECMP paths of SR-MPLS Policy.
The destination IPv4 address must be 127/8 range (loopback), otherwise it will be rejected.
Note
One PM session is always created for the actual endpoint address of the SR Policy.
-
liveness-detection: Configure the liveness-detection parameters:
-
multiplier: Number of consecutive missed probe packets before the PM session is declared as down. The range is from 2 to 10, and the default is 3.
Note
The detection-interval is equal to (tx-interval * multiplier).
Enabling Liveness Monitoring under SR Policy
Enable liveness monitoring under SR Policy, associate a liveness-profile, and configure SR Policy-specific probe parameters under the segment-routing traffic-eng policy performance-measurement sub-mode. The following parameters are configurable:
-
liveness-detection: Enables end-to-end SR Policy Liveness Detection for all segment-lists of the active and standby candidate-path that are in the forwarding table.
-
liveness-profile name name: Specifies the profile name for named profiles.
-
invalidation-action {down | none}:
-
Down (default): When the PM liveness session goes down, the candidate path is immediately operationally brought down.
-
None: When the PM liveness session goes down, no action is taken. If logging is enabled, the failure is logged but the SR Policy operational state isn’t modified.
-
-
logging session-state-change: Enables Syslog messages when the session state changes.
-
reverse-path label {BSID-value | NODE-SID-value}: Specifies the MPLS label to be used for the reverse path for the reply. If you configured liveness detection with ECMP hashing, you must specify the reverse path. The default reverse path uses IP Reply.
-
BSID-value: The Binding SID (BSID) label for the reverse SR Policy. (This is practical for manual SR policies with a manual BSID.)
-
NODE-SID-value: The absolute SID label of the (local) Sender Node to be used for the reverse path for the reply.
-
Configuration Examples
Configure a Default SR-Policy PM Liveness-Profile
The following example shows a default sr-policy liveness-profile:
RP/0/RSP0/CPU0:ios(config)# performance-measurement
RP/0/RSP0/CPU0:ios(config-perf-meas)# liveness-profile sr-policy default
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# probe
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tx-interval 150000
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# tos dscp 52
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-probe)# exit
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy)# liveness-detection
RP/0/RSP0/CPU0:ios(config-pm-ld-srpolicy-ld)# multiplier 5
Running Configuration:
performance-measurement
liveness-profile sr-policy default
liveness-detection
multiplier 5
!
probe
tos dscp 52
tx-interval 150000
!
!
!
end
Configure a Named (Non-Default) SR-Policy PM Liveness-Profile
The following example shows a named sr-policy liveness-profile:
Router(config)# performance-measurement
Router(config-perf-meas)# liveness-profile name sample-profile
Router(config-pm-ld-profile)# probe
Router(config-pm-ld-probe)# tx-interval 150000
Router(config-pm-ld-probe)# tos dscp 52
Router(config-pm-ld-probe)# exit
Router(config-pm-ld-profile)# liveness-detection
Router(config-pm-ld-profile-ld)# multiplier 5
Router(config-pm-ld-profile-ld)#commit
Running Configuration:
performance-measurement
liveness-profile name sample-profile
liveness-detection
multiplier 5
!
probe
tos dscp 52
tx-interval 150000
!
!
!
end
Configure a SR-Policy PM Liveness-Profile with Sweep Parameters
The following example shows a named liveness-profile with sweep parameters:
Router(config)# performance-measurement
Router(config-perf-meas)# liveness-profile name sample-profile
Router(config-pm-ld-profile)# probe
Router(config-pm-ld-probe)# tx-interval 150000
Router(config-pm-ld-probe)# tos dscp 52
Router(config-pm-ld-probe)# sweep
Router(config-pm-ld-probe-sweep)# destination ipv4 127.0.0.1 range 25
Router(config-pm-ld-probe-sweep)# exit
Router(config-pm-ld-probe)# exit
Router(config-pm-ld-profile)# liveness-detection
Router(config-pm-ld-profile-ld)# multiplier 5
Router(config-pm-ld-profile-ld)#commit
Running Configuration
performance-measurement
liveness-profile name sample-profile
liveness-detection
multiplier 5
!
probe
tos dscp 52
sweep
destination ipv4 127.0.0.1 range 25
!
tx-interval 150000
!
!
!
end
Enable Liveness Monitoring Under SR Policy
The following example shows how to enable liveness monitoring under SR Policy, associate a liveness-profile, and configure the invalidation action:
RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng
RP/0/RSP0/CPU0:ios(config-sr-te)# policy FOO
RP/0/RSP0/CPU0:ios(config-sr-te-policy)# performance-measurement
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)# liveness-detection
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# liveness-profile name sample-profile
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# invalidation-action none
Running Config
segment-routing
traffic-eng
policy FOO
performance-measurement
liveness-detection
liveness-profile name sample-profile
invalidation-action none
!
!
!
!
!
end
Enable Liveness Monitoring under SR Policy with Optional Parameters
The following example shows how to enable liveness monitoring under SR Policy, associate a liveness-profile, and configure reverse path label and session logging:
RP/0/RSP0/CPU0:ios(config)# segment-routing traffic-eng
RP/0/RSP0/CPU0:ios(config-sr-te)# policy BAA
RP/0/RSP0/CPU0:ios(config-sr-te-policy)# performance-measurement
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)# liveness-detection
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# liveness-profile name sample-profile
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# invalidation-action down
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# logging session-state-change
RP/0/RSP0/CPU0:ios(config-sr-te-policy-live-detect)# exit
RP/0/RSP0/CPU0:ios(config-sr-te-policy-perf-meas)# reverse-path label 16001
Running Config
segment-routing
traffic-eng
policy BAA
performance-measurement
liveness-detection
logging
session-state-change
!
liveness-profile name sample-profile
invalidation-action down
!
reverse-path
label 16001
!
!
!
!
!
end
SR Policy Liveness Monitoring - Hardware Offloading
|
Feature Name |
Release |
Description |
||
|---|---|---|---|---|
|
SR Policy Liveness Monitoring - Hardware Offloading |
Release 7.10.1 |
You can now hardware offload the liveness monitoring in performance measurement to the router hardware, which is the Network Processing Unit (NPU). This feature helps you optimize and scale the measurement operation, helping you meet delay-bound Service Level Agreements (SLAs). Previously, this feature was software driven. The feature introduces a new keyword npu-offload under the performance-measurement liveness-profile name liveness profile command.
|
Performance Measurement (PM) hardware offload feature allows the offload of PM liveness monitoring session to the Network Processing Unit (NPU) on the platform, which considerably improves scale and reduces the overall network convergence detection time.
This improvement is done by sending rapid failure detection probes (messages) and detecting policy or path failures quickly and help routing protocols in recalculating the routing table.
This feature is required in order to quickly react on delay-bound Service Level Agreement (SLAs), for example 5G low-latency, where SRTE policy can quickly re-optimize once the SLA is violated.
Advantages of the PM Hardware Offloading feature are as listed:
-
Probes are sent every 3.3 milliseconds
-
Complete liveness of the endpoint is now reduced to 10ms from 50ms when the operator configures the multiplier to be 3 (10ms = 3.3ms * 3).
-
Currently, the hardware offload supports only liveness monitoring .
Note |
The hardware offload does not support delay and loss measurement yet. |
Usage Guidelines and Limitations
The following usage guidelines and limitations apply:
-
The NPU offload generates PM probes (Packets Per Second) with a maximum limit. PPS is directly proportional with the number of sessions and transmit interval. If the PPS exceeds the limit supported by the offload engine, the stretch algorithm activates. This algorithm doubles the transmit interval until the PPS is within the supported limit. Use 'show performance-measurement pps' command to verify the maximum probes per second (PPS) supported by offload engine and total pps currently in use.
Configuration Example
Note |
The Hw-module profile offload 4 command is a prerequisite for LC CPU sessions to work. Once you use the ‘hw-module profile offload 4’ command, the Bidirectional Forwarding Detection for IPv6 (BFDv6) will not work even if the Performance Measurement sessions are hosted only on LC CPU and not offloaded to the offload processor. Use the 4th option 4 PM-HW-Offload and Bsync in hw-module profile offload command to configure the Hardware Profile Offloading. |
The following example allows you to enable Performance Measurement Liveness Hardware (NPU) offload in the SR environment.
Router(config)#performance-measurement
Router(config-perf-meas)#liveness-profile name hwo_profile
Router(config-pm-ld-profile)#npu-offload
Router(config-pm-ld-profile-npu-offload)#enable
Router(config-pm-ld-profile-npu-offload)#commitRunning Configuration
The running configuration for this feature is as shown:
performance-measurement
liveness-profile name
npu-offload
enable
!
!
! Verification
Use the show command to verify the running configuration as shown:
Router# show performance-measurement sessions detail
Transport type : SR Policy
Measurement type : Liveness Detection
Policy name : srte_c_90005_ep_10.2.2.2
Color : 90005
Endpoint : 10.2.2.2
Instance : 7
preference : 20
Protocol-origin : Configured
Discriminator : 20
Segment-list : route_12_2
Atomic path:
Hops : 10.2.2.2
Session ID : 45
Trace ID : 3111803555
NPU Offloaded session : True
NPU number : 0
NPU session state : Session created
Retry count : 0
Last NPU notification:
Session state : Up
Timestamp : Feb 28 2023 16:28:09.411
Timestamping Enabled : True
Liveness Detection: Enabled
Session State: Up
Last State Change Timestamp: Feb 28 2023 16:28:09.411
Missed count: 0 
Feedback