SR Linux OAM and diagnostics tools

Bidirectional Forwarding Detection (BFD) is a lightweight mechanism used to monitor the liveliness of a remote neighbor. Because of this lightweight nature, BFD can send and receive messages at a much higher rate than other control plane hello mechanisms. This attribute allows connection failures to be detected faster than other hello mechanisms.

SR Linux supports BFD asynchronous mode, where BFD control packets are sent between two systems to activate and maintain BFD neighbor sessions between them.

BFD can be configured to monitor connectivity for the following:

• BGP peers

• Next-hops for static routes

• OSPF adjacencies

• IS-IS adjacencies

See ‟Bidirectional Forwarding Detection” in the SR Linux OAM and Diagnostics Guide for configuration information.

Micro-BFD, where BFD sessions are established for individual members of a LAG, is also supported. If the BFD session for one of the links indicates a connection failure, the link is taken out of service from the perspective of the LAG.

See ‟Micro-BFD” in the SR Linux OAM and Diagnostics Guide for configuration information.

SR Linux supports seamless bidirectional forwarding detection (S-BFD), which is a simplified mechanism that speeds up a BFD session by eliminating the negotiation and state establishment process. This is accomplished primarily by predetermining the session discriminator and using specific mechanisms to distribute the discriminators to a remote network entity. This allows client applications or protocols to quickly initiate and perform connectivity tests.

See ‟Seamless bidirectional forwarding detection (S-BFD)” in the SR Linux OAM and Diagnostics Guide for configuration information.

The SR Linux supports sFlow version 5 behavior and formats. sFlow is used to monitor data traffic flows traversing different points in a network. The sFlow functionality uses an sFlow agent and an sFlow collector. The agent is software that runs on a network element and samples and reports flow headers and statistics. The collector is software that typically runs on a remote server and receives the flow headers and statistics from one or more sFlow agents.

On the SR Linux, sFlow samples flow data and reports the samples to configured sFlow collectors. Up to eight sFlow collectors can be configured. When sFlow is enabled on an interface, the sFlow agent streams interface statistics to the configured sFlow collectors.

See the ‟sFlow” chapter in the SR Linux OAM and Diagnostics Guide for configuration information and examples.

SR Linux features an interactive traffic monitoring tool that samples packets entering the system on any interface matching a set of parameters, and streams the header details either to the current login session or to a specified output file.

When the traffic monitoring tool is activated, mirroring policies are dynamically populated on all ingress ports, and matching packets are sent to the CPM for display. Header information for the matching packets is displayed in either tcpdump format or hex format, depending on the options chosen.

When the traffic monitoring tool is deactivated, the mirroring policies are automatically removed from all ingress interfaces.

See the ‟Interactive traffic monitoring” chapter of the SR Linux Troubleshooting Toolkit guide for usage information.

SR Linux includes a packet-trace tool that reports the forwarding behavior of a probe packet. The probe packet is injected into a specified interface forwarding context, and the packet-trace tool records the forwarding destination or egress port for the probe packet, as well as any matched ACL records or reasons for discarding the packet. The probe packet can be specified in Scapy format, base64 format, or pcap file format. See the ‟Packet-trace tool” chapter of the SR Linux Troubleshooting Toolkit guide for usage information.

Traffic mirroring sends copies of IPv4 and IPv6 packets from a designated source to a designated destination.

The source for the mirrored traffic can be an interface (port), a subinterface (VLAN), a LAG, or an ACL filter. The mirrored traffic can be copied to a local destination, such as a locally-attached traffic analyser (local mirroring), or encapsulated into a tunnel toward a remote destination (remote mirroring).

See the "Mirroring" chapter of the SR Linux OAM and Diagnostics Guide for usage information and configuration examples.

Two-Way Active Measurement Protocol (TWAMP) is a standards-based method to measure the IP performance between two devices including packet loss, delay, and jitter. TWAMP leverages the methodology and architecture of One-Way Active Measurement Protocol (OWAMP) to define a method to measure two-way or round-trip metrics.

There are four logical entities in TWAMP: the control client, the session sender, the server, and the session reflector. The control client and session sender are typically implemented in one physical device and the server and session reflector in a second physical device. SR Linux acts as the server and the session reflector.

See ‟TWAMP” in the SR Linux OAM and Diagnostics Guide for configuration information.

The Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 is a standards-based method to measure the IP performance without the use of a control channel to pre-signal session parameters.

The PDU structure allows for the collection of frame delay, frame delay range, inter-frame delay variation, and frame loss ratio. The RFC 8972 STAMP Optional Extensions specification maintains the existing structure of the STAMP PDU but redefines existing fields and adds the capability to include TLVs. SR Linux supports RFC 8762 and the structural changes with TLV processing in the options draft RFC 8972.

For each routed network instance, the STAMP session sender transmits STAMP test packets to the destination UDP port of the session reflector. The session reflector receives the packets, processes the STAMP test packet, and sends them back to the session sender. The session sender receives the reflected packets and uses the timestamps and sequence numbers to calculate delay and loss performance metrics. The session reflector supports a prefix list which filters based on IPv4 or IPv6 addressing. The reflector is stateful and uses the tuple sSIP, DIP, SP, DP, or SSID to identify individual STAMP test sessions.

See ‟STAMP” in the SR Linux OAM and Diagnostics Guide for configuration information.

A link measurement test is a method for measuring and reporting delay information for directly connected IP peers. Link measurement uses the STAMP protocol defined in RFC 8762 to measure delay for an IP interface. The feature uses reporting options and thresholds to determine the values to be reported. This allows for the network element to advertise delay metrics for the IP interface using the IGP. The unidirectional delay values can be used to influence delay sensitive paths through the network.

See ‟Link measurement” in the SR Linux OAM and Diagnostics Guide for configuration information.

Performance monitoring encompasses a variety of tools and protocols designed to measure, report, analyze, and optimize network performance, allowing network administrators to detect and resolve issues proactively. SR Linux supports performance monitoring using STAMP for delay and packet loss measurements in IP networks.

The STAMP OAM performance monitoring architecture for delay and loss measurement consists of the following foundational components:

• session: This is the overall collection of the test parameters, measurement intervals, thresholds and storage of results. It is the overall container that defines the attributes of the session.

• standard performance monitoring packets: SR Linux supports STAMP to measure performance metrics such as delay and packet loss.

• measurement interval: These are time-based non-overlapping windows that capture results that are received in that window of time.

• data structures: These are the unique counters and measurement results that represent the specific protocol.

• bin group: These are ranges in microseconds that count the results that fit into the range.

See ‟Performance monitoring” in the SR Linux OAM and Diagnostics Guide for configuration information.