OAM fault and performance tools and protocols
This chapter provides information about the operation, administration, and maintenance (OAM) tools and protocols. The tools and protocols are used for:
-
fault detection and isolation
-
performance measurement
This chapter covers the following sections:
IP OAM tools and protocols
This section provides information about the IP OAM tools and protocols.
ICMP ping and trace
Overview
Internet Control Message Protocol (ICMP) is part of the IP suite as defined in RFC 792, Internet Control Message Protocol, for IPv4 and RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. ICMP and ICMPv6 send and receive control and error messages used to manage the behavior of the TCP/IP stack. ICMP and ICMPv6 provide the following:
-
debugging tools and error reporting mechanisms to assist in troubleshooting an IP network
-
the ability to send and receive error and control messages to far-end IP entities
Ping
The ping command uses an echo request message to elicit an echo response from a host or gateway. The ping6 command is the IPv6 version of the ping command. See Performing an ICMP ping for more information.
Traceroute
The traceroute command is used to trace the route that the packets take from the current system to the destination. It uses the time to live (TTL) parameter to elicit an ICMP time exceeded response from each gateway along the path to the host. The traceroute6 command is the IPv6 version of the traceroute command. See Performing an ICMP trace for more information.
Performing an ICMP ping
Use the ping (IPv4) or ping6 (IPv6) command to contact an IP address. Use this command in any mode.
ping for IPV4
--{ running }--[ ]--
# ping 192.168.1.1 network-instance default
Pinging 192.168.1.1 in srbase-default
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.030 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6165ms
rtt min/avg/max/mdev = 0.027/0.030/0.033/0.005 ms
Performing an ICMP trace
To display the path a packet takes to a destination, use the traceroute (IPv4) or traceroute6 (IPv6) command.
To trace the route using TCP SYN packets instead of UDP or ICMP echo packets, use the tcptraceroute command.
traceroute for IPv4
--{ running }--[ ]--
# traceroute 1.1.1.1 network-instance mgmt
Using network instance srbase-mgmt
traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 60 byte packets
1 172.18.18.1 (172.18.18.1) 1.268 ms 1.260 ms 1.256 ms
2 172.21.40.1 (172.21.40.1) 1.253 ms 1.848 ms 1.851 ms
3 172.22.35.230 (172.22.35.230) 1.835 ms 1.834 ms 1.828 ms
4 66.201.62.1 (66.201.62.1) 3.222 ms 3.222 ms 3.216 ms
5 66.201.34.17 (66.201.34.17) 5.474 ms 5.475 ms 5.480 ms
6 * * *
7 206.81.81.10 (206.81.81.10) 32.577 ms 32.542 ms 32.400 ms
8 10.1.1.1 (10.1.1.1) 22.627 ms 22.637 ms 22.638 ms
TWAMP
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.
Components
The following are the four logical entities in TWAMP:
-
control client: initiates the TWAMP control session and negotiates the test session parameters with the server
-
server: responds to the control client request with the capacities that are supported and negotiates test session parameters
-
session sender: transmits test packets to the session reflector
-
session reflector: transmits a packet to the session sender in response to each packet it receives
These four functional elements are typically coupled together. The control client and session sender are implemented in one physical device which is referred to as the client. The server and session reflector are implemented in a second physical device which is referred to as the server. SR Linux supports the server and the session reflector.
See Configuring a TWAMP server for more information about steps to configure a TWAMP server.
Protocols
The following protocols are used in TWAMP sessions:
-
TWAMP control protocol (TCP port 862): used to establish and manage control sessions between the control client and the server
-
TWAMP test protocol (configurable UDP port): used to generate and send test traffic between the session sender and session reflector, and to measure network performance metrics like delay
Establishing a control session
The control client initiates a TCP connection and exchanges TWAMP control messages over this connection. The server accepts the TCP control session from the control client and responds with a server greeting message. This greeting includes the modes that are supported by the server. The modes are in the form of a bit mask. Each bit in the mask represents a functionality supported on the server.
SR Linux server mode support includes:
-
unauthenticated server
-
individual session control (mode bit 4)
-
reflected octets (mode bit 5)
-
symmetrical size test packet (mode bit 6)
To start testing, the control client communicates the test parameters to the server, requesting any of the modes that the server supports. If the server agrees to conduct the described tests, the test begins as soon as the control client sends a start sessions or start-n-session message.
Executing a test session
The session sender initiates the test session by sending a stream of UDP-based TWAMP test packets to the session reflector. The session reflector responds to each received packet with a UDP-response TWAMP test packet. The exchange of TWAMP test PDUs is referred to as a TWAMP test. The session sender calculates the various delay and loss metric based on the received TWAMP test PDUs . The TWAMP test PDU does not achieve symmetrical packet size in both directions unless the frame is padded with a minimum of 27 bytes. The session sender is responsible for applying the required padding. After the frame is appropriately padded, the session reflector reduces the padding by the number of bytes needed to provide symmetry.
The control client can terminate individual test by sending the appropriate stop message, or terminate all tests for a control channel by terminating the TCP control channel.
TWAMP statistics
The following TWAMP statistics are available in SR Linux:
-
system-level TWAMP statistics
-
server statistics
-
client connection statistics
-
control connection statistics
-
session reflector statistics
See Displaying TWAMP statistics for more information.
A clear command is available at the server network-instance level to clear all test session transmit and receive statistics and error counters. See Clearing TWAMP session statistics for more information.
Configuring a TWAMP server
Configure TWAMP server
The following example configures a TWAMP server.
--{ + candidate shared default }--[ ]--
# info oam twamp
oam {
twamp {
server {
network-instance default {
admin-state enable
servwait 900
control-packet-dscp 12
enforce-test-session-start-time true
client-connection 192.15.20.9/32 {
maximum-connections 32
maximum-sessions 32
}
}
}
}
}Displaying TWAMP statistics
To display system-level TWAMP statistics, use the info from state oam twamp command.
Displaying TWAMP statistics
The following example displays TWAMP statistics.
--{ + candidate shared default }--[ ]--
# info from state oam twamp
oam {
twamp {
server {
network-instance default {
admin-state enable
oper-state up
servwait 60
control-packet-dscp CS7
enforce-test-session-start-time true
maximum-connections 64
maximum-sessions 128
modes [
unauthenticated
individual-session-control
reflect-octets
symmetrical-size
]
statistics {
test-sessions-active 1
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 2
test-packets-transmitted 2
control-connections-active 1
control-connections-rejected 0
}
client-connection 10.32.5.0/24 {
maximum-connections 64
maximum-sessions 128
statistics {
test-sessions-active 1
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 2
test-packets-transmitted 2
control-connections-active 1
control-connections-rejected 0
}
}
client-connection 10.11.1.0/24 {
maximum-connections 64
maximum-sessions 128
statistics {
test-sessions-active 0
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 0
test-packets-transmitted 0
control-connections-active 0
control-connections-rejected 0
}
}
client-connection 10.12.1.0/24 {
maximum-connections 32
maximum-sessions 32
statistics {
test-sessions-active 0
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 0
test-packets-transmitted 0
control-connections-active 0
control-connections-rejected 0
}
}
client-connection 2001:db8:101:1:1::/120 {
maximum-connections 64
maximum-sessions 128
statistics {
test-sessions-active 0
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 0
test-packets-transmitted 0
control-connections-active 0
control-connections-rejected 0
}
}
client-connection 2001:db8:101:1:1::/120 {
maximum-connections 32
maximum-sessions 32
statistics {
test-sessions-active 0
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 0
test-packets-transmitted 0
control-connections-active 0
control-connections-rejected 0
}
}
client-connection 2001:db8:101:1:1::/120 {
maximum-connections 64
maximum-sessions 128
statistics {
test-sessions-active 0
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 0
test-packets-transmitted 0
control-connections-active 0
control-connections-rejected 0
}
}
control-connection 10.32.5.0 client-tcp-port 58116 server-ip 10.20.1.3 server-tcp-port 862 {
state active
control-packet-dscp 20
statistics {
test-sessions-active 1
test-sessions-completed 0
test-sessions-rejected 0
test-sessions-aborted 0
test-packets-received 2
test-packets-transmitted 2
}
}
session-reflector {
test-session 10.32.5.0 sender-udp-port 20100 reflector-ip 10.20.1.3 reflector-udp-port 862 {
test-session-id 0A:14:01:03:EA:0B:06:CC:1A:36:F3:B2:A3:97:A2:55
parent-connection-client-ip 32.32.5.2
parent-connection-client-tcp-port 58116
parent-connection-server-ip 10.20.1.3
parent-connection-server-tcp-port 862
test-packet-dscp 0
last-sequence-number-transmitted 1
last-sequence-number-received 0
statistics {
test-packets-received 2
test-packets-transmitted 2
}
}
}
}
}
statistics {
dropped-connections {
tcp-connection-closed 0
tcp-connection-fatal-error 0
tcp-unexpected-event 0
message-send-error 0
memory-allocation-error 0
no-client-prefix-match 0
maximum-global-limit-exceed 0
maximum-prefix-limit-exceed 0
unspecified-mode 0
unsupported-mode 0
control-command-not-valid 0
incorrect-stop-session-count 0
connection-timeout 0
no-internal-resource 0
non-zero-sid-in-client-control-message 0
invalid-invalid-hmac 0
}
dropped-connection-states {
idle 0
setup-wait 0
started 0
active 0
process-started 0
process-stop 0
process-tw-session 0
}
rejected-session {
invalid-ip-address-version 0
non-local-ip-destination 0
bad-type-p 0
padding-too-big 0
non-zero-mbz-value 0
non-zero-session-sender-sid 0
timeout-too-large 0
maximum-global-session-exceed 0
maximum-prefix-session-exceed 0
client-source-ip-unreachable 0
udp-port-in-use 0
duplicate-session 0
no-internal-resource 0
refwait-timeout 0
}
dropped-test-packet {
incorrect-packet-size 0
incorrect-source-address 0
arrived-before-start-time 0
no-start-sessions 0
invalid-error-estimate 0
reply-error 0
invalid-server-octets 0
invalid-symmetric-mbz 0
}
}
}
}
Clearing TWAMP session statistics
You can clear the TWAMP session statistics for each network instance using the tools oam twamp server network-instance default clear command.
Clearing TWAMP session statistics
The following example clears TWAMP session statistics for each network instance.
--{ + candidate shared default }--[ ]--
# tools oam twamp server network-instance default clearSTAMP
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 negotiate test session parameters.
The STAMP test PDU 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 test 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.
STAMP operation
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 SIP, DIP, SP, DP, and SSID to identify individual STAMP test sessions.
See Configuring STAMP session reflector for more information about how to configure a session reflector.
Session sender packet format
The session sender uses the tuple SIP, DIP, SP, and DP but uses the SSID to identify individual STAMP test sessions. The following table represents the STAMP test PDU (RFC8972) sent by the session sender encapsulated in a generic Ethernet header, with a description of the key protocol elements.
| Field | Description |
|---|---|
|
Sequence Number |
Packet sequence number generated based on the transmission sequence. For each new session, its value starts at 0 and is incremented by one with each transmitted packet. |
|
Timestamp |
Timestamp when a test packet is sent. |
|
Error Estimate |
Estimated error field. The format is as follows:
|
| SSID | Session Sender ID (SSID) automatically generated by the system. |
| MBZ | Must-Be-Zero (MBZ). The value must be 0. This field is used to ensure data packet symmetry between the session sender and session reflector. |
Session reflector packet format
The following table represents the STAMP test PDU (RFC8972) sent by the session reflector encapsulated in a generic Ethernet header, with a description of the key protocol elements.
| Fields | Description |
|---|---|
|
Sequence Number |
Session reflector packet sequence number. For each new session, its value starts at 0 and is incremented by one with each transmitted packet. |
|
Timestamp |
Session reflector timestamp (T3) |
|
Error Estimate |
Session reflector estimated error field. The format is as follows:
|
| SSID | Session Sender ID (SSID) automatically generated by the system. |
|
MBZ |
Must-Be-Zero. The value must be 0. This field is used to ensure data packet symmetry between the Session-Sender and Session-Reflector. |
|
Receive Timestamp |
Timestamp when a test packet is received on the session reflector (T2). |
|
Session-Sender Sequence Number |
Sequence Number field of the STAMP Test request packet. |
|
Session-Sender Timestamp |
Session sender timestamp field copied from the original the STAMP Test request packet (T1). |
|
Session-Sender Error Estimate |
Session sender Error Estimate field copied from the original the STAMP Test request packet. |
|
Session-Sender TTL |
Session sender TTL value copied from the original STAMP packet. |
Interoperability of STAMP and TWAMP Light session reflector
-
UDP packets with a length less than 44 bytes are processed using TWAMP Light processing rules, which involves simple padding and symmetrical packet size handling.
-
UDP packets with a length equal to 44 bytes are processed as STAMP packets.
-
For UDP packets with a length equal to 45 bytes or more, the 45th byte is checked for the flags structure (100xxxxx).
-
If found, the packets are processed as STAMP packets.
-
If not found, the packet is assumed to be a TWAMP Light padded packet and processed accordingly. The TWAMP Light packet uses all zeros padding to avoid matching the 100xxxxx pattern by accident.
-
-
Multiple TLVs in a STAMP test packet are parsed using the length field.
-
If a TWAMP Light test packet mistakenly matches the 100xxxxx pattern at byte 45, the reflector attempts to parse the TLV. Failure to parse results in marking the byte as 110xxxxx and halting further STAMP TLV processing. However, the base STAMP packet continues to be processed.
- TWAMP Light packets arriving on a STAMP session reflector must use all zeros padding to avoid unintentional mismatching.
STAMP statistics
The following STAMP statistics are available in SR Linux:
-
system-level session reflector statistics
-
session reflector statistics for each network instance
-
test session statistics
See Displaying STAMP statistics for more information.
Configuring STAMP session reflector
To configure a STAMP session reflector for a network instance, use the oam stamp command and specify the network instance, IP address prefix, and the UDP port as shown in the example.
Configuring STAMP session reflector
The following example configures a session reflector.
--{ + candidate shared default }--[ ]--
# info oam stamp
oam {
stamp {
session-reflector {
network-instance default {
description test
admin-state enable
udp-port 862
ip-prefix 192.20.13.20/32 {
}
}
}
}
}Displaying STAMP statistics
To display system-level STAMP session reflector statistics, use the info from state oam stamp command.
Displaying STAMP statistics
The following example displays STAMP statistics.
--{ + candidate shared default }--[ ]--
# info from state oam stamp
oam {
stamp {
session-reflector {
inactivity-timer 900
statistics {
test-frames-received 400
test-frames-sent 400
test-session-count 4
reflector-table-entries-full 0
packet-discards-on-reception 0
packet-discards-on-transmission 0
session-reflector-not-found 0
reflectors-configured 1
reflectors-operational 1
reflectors-not-operational 0
}
network-instance default {
admin-state enable
udp-port 862
oper-state up
ip-prefix 10.11.1.0/24 {
}
ip-prefix 10.10.11.0/24 {
}
ip-prefix 10.10.12.0/24 {
}
ip-prefix 10.10.14.0/24 {
}
ip-prefix 10.20.1.0/24 {
}
ip-prefix 10.12.1.0/24 {
}
ip-prefix 10.13.1.0/24 {
}
ip-prefix 10.14.1.0/24 {
}
ip-prefix 2001:db8:101:1:1/120 {
}
ip-prefix 2001:db8:102:1:1/120 {
}
ip-prefix 2001:db8:103:1:1/120 {
}
ip-prefix 2001:db8:104:1:1/120 {
}
ip-prefix 2001:db8:105:1:1/120 {
}
ip-prefix 2001:db8:106:1:1/120 {
}
ip-prefix 2001:db8:107:1:1/120 {
}
ip-prefix 2001:db8:108:1:1/120 {
}
statistics {
test-frames-received 400
test-frames-sent 400
test-sessions 4
prefix-match-failure 0
session-reflector-udp-port-registration-failure 0
malformed-packet 0
packet-discards-source-destination-equal 0
}
test-session-statistics 10.20.1.3 session-sender-udp 44000 session-reflector-ip 11.20.1.2 session-reflector-udp 862 session-identifier 1736 {
last-sequence-number-received 99
last-sequence-number-transmitted 99
test-frames-received 100
test-frames-sent 100
malformed-tlv 0
}
test-session-statistics 10.10.3.3 session-sender-udp 44000 session-reflector-ip 20.10.3.2 session-reflector-udp 862 session-identifier 1737 {
last-sequence-number-received 99
last-sequence-number-transmitted 99
test-frames-received 100
test-frames-sent 100
malformed-tlv 0
}
test-session-statistics 2001:db8:103:1:1 session-sender-udp 44000 session-reflector-ip fc00::b14:102 session-reflector-udp 862 session-identifier 1738 {
last-sequence-number-received 99
last-sequence-number-transmitted 99
test-frames-received 100
test-frames-sent 100
malformed-tlv 0
}
test-session-statistics 2001:db8:104:1:1 session-sender-udp 44000 session-reflector-ip fc00::140a:302 session-reflector-udp 862 session-identifier 1739 {
last-sequence-number-received 99
last-sequence-number-transmitted 99
test-frames-received 100
test-frames-sent 100
malformed-tlv 0
}
}
MPLS OAM tools and protocols
This section provides information about the MPLS OAM tools and protocols.
LSP ping and trace
The LSP diagnostics include implementations of LSP ping and LSP trace based on RFC 8029, Detecting Multiprotocol Label Switched (MPLS) Data Plane Failures. LSP ping provides a mechanism to detect data plane failures in MPLS LSPs. LSP ping and LSP trace are modeled after the ICMP echo request or reply used by ping and trace to detect and localize faults in IP networks.
For a specific LDP FEC, LSP ping verifies whether the packet reaches the egress label edge router (LER), while for LSP trace, the packet is sent to the control plane of each transit Label Switching Router (LSR) that performs various checks to see if it is intended to be a transit LSR for the path.
The downstream mapping TLV is used in LSP ping and LSP trace to provide a mechanism for the sender and responder nodes to exchange and validate interface and label stack information for each downstream hop in the path of an LDP FEC.
See the following topics for more information about performing LSP ping and trace:
ECMP considerations for LSP ping and LSP trace
If an LSP trace is initiated without the destination IP address, the sender node does not include multi-path information in the Downstream Mapping TLV of the echo request message (multipath type=0). The responder node replies with a Downstream Mapping TLV for each outgoing interface which is part of the ECMP next hop set for the FEC. The sender node selects the first Downstream Mapping TLV to use for subsequent probes one hop further toward the destination.
If an LSP trace is initiated with the destination IP address, the sender node includes the multipath information in the Downstream Mapping TLV in the echo request message (multipath type=8). The ecmp-interface-select and ecmp-next-hop-select options allow the LER to exercise a specific ECMP path. If both the options are specified, the ecmp-interface-select takes precedence. The ecmp-interface-select and ecmp-next-hop-select options can be used to direct the echo request message at the sender node to be sent out to a specific outgoing interface which is part of an ECMP path set for the FEC.
LSP ping and trace for LDP tunnels
- tools oam lsp-ping ldp fec <prefix>
- tools oam lsp-trace ldp fec <prefix>
Supported parameters include destination-ip, source-ip, timeout, ecmp-next-hop-select, and traffic-class. However, the only mandatory parameter is fec.
Results from the lsp-ping and lsp-trace operations are displayed using info from state commands.
Performing an LSP ping to an LDP tunnel endpoint
To check connectivity to an LDP tunnel endpoint, use the tools oam lsp-ping ldp command, specifying the IPv4 and IPv6 FEC prefix of the LDP tunnel. To display the results, use the info from state oam lsp-ping ldp command, specifying the session ID output from the lsp-ping.
Perform an LSP ping to an LDP tunnel endpoint (IPv4)
--{ + running }--[ ]--
# tools oam lsp-ping ldp fec 10.20.1.6/32
/oam/lsp-ping/ldp/fec[prefix=10.20.1.6/32]:
Initiated LSP Ping to prefix 10.20.1.6/32 with session id 49152
Display results of the LSP ping (IPv4)
--{ + running }--[ ]--
# info from state oam lsp-ping ldp fec 10.20.1.6/32 session-id 49152
oam {
lsp-ping {
ldp {
fec 10.20.1.6/32 {
session-id 49152 {
test-active false
statistics {
round-trip-time {
minimum 4292
maximum 4292
average 4292
standard-deviation 0
}
}
path-destination {
ip-address 127.0.0.1
}
sequence 1 {
probe-size 48
request-sent true
out-interface ethernet-1/33.1
reply {
received true
reply-sender 10.20.1.6
udp-data-length 40
mpls-ttl 255
round-trip-time 4292
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}Perform an LSP ping to an LDP tunnel endpoint (IPv6)
--{ + running }--[ ]--
# tools oam lsp-ping ldp fec fc00::a14:106/128
/oam/lsp-ping/ldp/fec[prefix=fc00::a14:106/128]:
Initiated LSP Ping to prefix fc00::a14:106/128 with session id 49169
Display results of the LSP ping (IPv6)
--{ + running }--[ ]--
# info from state oam lsp-ping ldp fec fc00::a14:106/128 session-id 49169
oam {
lsp-ping {
ldp {
fec fc00::a14:106/128 {
session-id 49169 {
test-active false
statistics {
round-trip-time {
minimum 47539
maximum 47539
average 47539
standard-deviation 0
}
}
path-destination {
ip-address ::ffff:127.0.0.0
}
sequence 1 {
probe-size 60
request-sent true
out-interface ethernet-1/31.1
reply {
received true
reply-sender fc00::a14:106
udp-data-length 40
mpls-ttl 255
round-trip-time 47539
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}
Performing an LSP trace for an LDP tunnel
To trace the path to any midpoint or endpoint of an LDP tunnel, use the tools oam lsp-trace command, specifying the IPv4 and IPv6 FEC prefix of the LDP tunnel. To display the results, use the info from state oam lsp-trace ldp command, specifying the session ID output from the lsp-trace.
Perform an LSP trace to an LDP tunnel endpoint (IPv4)
--{ + running }--[ ]--
# tools oam lsp-trace ldp fec 10.20.1.6/32
/oam/lsp-trace/ldp/fec[prefix=10.20.1.6/32]:
Initiated LSP Trace to prefix 10.20.1.6/32 with session id 49153
Display results of the LSP trace (IPv4)
--{ + running }--[ ]--
# info from state oam lsp-trace ldp fec 10.20.1.6/32 session-id 49153
oam {
lsp-trace {
ldp {
fec 10.20.1.6/32 {
session-id 49153 {
test-active false
path-destination {
ip-address 127.0.0.1
}
hop 1 {
probe 1 {
probe-size 76
probes-sent 1
reply {
received true
reply-sender 10.20.1.2
udp-data-length 60
mpls-ttl 1
round-trip-time 4824
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.4.4
downstream-interface-address 10.10.4.4
mpls-label 1 {
label 2002
protocol ldp
}
}
}
}
hop 2 {
probe 1 {
probe-size 76
probes-sent 1
reply {
received true
reply-sender 10.20.1.4
udp-data-length 60
mpls-ttl 2
round-trip-time 4693
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.9.6
downstream-interface-address 10.10.9.6
mpls-label 1 {
label 2000
protocol ldp
}
}
}
}
hop 3 {
probe 1 {
probe-size 76
probes-sent 1
reply {
received true
reply-sender 10.20.1.6
udp-data-length 32
mpls-ttl 3
round-trip-time 4597
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}
}Perform an LSP trace to an LDP tunnel endpoint (IPv6)
--{ + running }--[ ]--
# tools oam lsp-trace ldp fec fc00::a14:106/128
/oam/lsp-trace/ldp/fec[prefix=fc00::a14:106/128]:
Initiated LSP Trace to prefix fc00::a14:106/128 with session id 49168
Display results of the LSP trace (IPv6)
--{ + running }--[ ]--
# info from state oam lsp-trace ldp fec fc00::a14:106/128 session-id 49168
oam {
lsp-trace {
ldp {
fec fc00::a14:106/128 {
session-id 49168 {
test-active false
path-destination {
ip-address ::ffff:127.0.0.0
}
hop 1 {
probe 1 {
probe-size 112
probes-sent 1
reply {
received true
reply-sender fc00::a14:102
udp-data-length 84
mpls-ttl 1
round-trip-time 41527
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv6-numbered
downstream-router-address fe80::201:4ff:feff:1e
downstream-interface-address fe80::201:4ff:feff:1e
mpls-label 1 {
label 2008
protocol ldp
}
}
}
}
hop 2 {
probe 1 {
probe-size 112
probes-sent 1
reply {
received true
reply-sender fc00::a14:104
udp-data-length 84
mpls-ttl 2
round-trip-time 76569
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv6-numbered
downstream-router-address fe80::201:6ff:feff:3
downstream-interface-address fe80::201:6ff:feff:3
mpls-label 1 {
label 2001
protocol ldp
}
}
}
}
hop 3 {
probe 1 {
probe-size 112
probes-sent 1
reply {
received true
reply-sender fc00::a14:106
udp-data-length 32
mpls-ttl 3
round-trip-time 41739
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}
}
LSP ping and trace for segment routing tunnels
- tools oam lsp-ping sr-isis prefix-sid <prefix>
- tools oam lsp-trace sr-isis prefix-sid <prefix>
Supported parameters include destination-ip, source-ip, timeout, ecmp-next-hop-select, igp-instance, and traffic-class. However, the only mandatory parameter is the prefix-sid.
Results from the lsp-ping and lsp-trace operations are displayed using info from state commands.
In the case of ECMP, even when the destination IP is configured, the SR Linux node may not exercise all NHLFEs.
Performing an LSP ping to a segment routing prefix
To check connectivity to a segment routing prefix, use the tools oam lsp-ping sr-isis command. To display the results, use the info from state oam lsp-ping sr-isis command, specifying the session ID output from the lsp-ping.
Perform an LSP ping to a destination segment routing prefix
# tools oam lsp-ping sr-isis prefix-sid 10.20.1.6/32
/oam/lsp-ping/sr-isis/prefix-sid[prefix=10.20.1.6/32]:
Initiated LSP Ping to prefix 10.20.1.6/32 with session id 49152
Display results of the LSP ping
--{ + running }--[ ]--
# info from state oam lsp-ping sr-isis prefix-sid 10.20.1.6/32 session-id 49152
oam {
lsp-ping {
sr-isis {
prefix-sid 10.20.1.6/32 {
session-id 49152 {
test-active false
statistics {
round-trip-time {
minimum 4292
maximum 4292
average 4292
standard-deviation 0
}
}
path-destination {
ip-address 127.0.0.1
}
sequence 1 {
probe-size 48
request-sent true
out-interface ethernet-1/33.1
reply {
received true
reply-sender 10.20.1.6
udp-data-length 40
mpls-ttl 255
round-trip-time 4292
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}Performing an LSP trace to a segment routing prefix
To trace the path to any midpoint or endpoint of a segment routing tunnel, use the tools oam lsp-trace command. To display the results, use the info from state oam lsp-trace sr-isis command, specifying the session ID output from the lsp-trace.
Perform an LSP trace to a destination segment routing prefix
# tools oam lsp-trace sr-isis prefix-sid 10.20.1.6/32
/oam/lsp-trace/sr-isis/prefix-sid[prefix=10.20.1.6/32]:
Initiated LSP Trace to prefix 10.20.1.6/32 with session id 49153
Display results of the LSP trace
--{ + running }--[ ]--
# info from state oam lsp-trace sr-isis prefix-sid 10.20.1.6/32 session-id 49153
oam {
lsp-trace {
sr-isis {
prefix-sid 10.20.1.6/32 {
session-id 49153 {
test-active false
path-destination {
ip-address 127.0.0.1
}
hop 1 {
probe 1 {
probe-size 76
probes-sent 1
reply {
received true
reply-sender 10.20.1.2
udp-data-length 60
mpls-ttl 1
round-trip-time 2768
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.4.4
downstream-interface-address 10.10.4.4
mpls-label 1 {
label 27000
protocol isis
}
}
}
}
hop 2 {
probe 1 {
probe-size 76
probes-sent 1
reply {
received true
reply-sender 10.20.1.4
udp-data-length 60
mpls-ttl 2
round-trip-time 3414
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.9.6
downstream-interface-address 10.10.9.6
mpls-label 1 {
label 27000
protocol isis
}
}
}
}
hop 3 {
probe 1 {
probe-size 76
probes-sent 1
reply {
received true
reply-sender 10.20.1.6
udp-data-length 32
mpls-ttl 3
round-trip-time 4429
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}
}
LSP ping and trace for uncolored SR-MPLS TE policy
- tools oam lsp-ping te-policy sr-uncolored policy <policy name> protocol-origin <value>
- tools oam lsp-trace te-policy sr-uncolored policy <policy-name> protocol-origin protocol-origin <value>
Supported parameters include destination-ip, source-ip, interval, segment-list-index, timeout, ecmp-interface-select mpls-ttl, ecmp-next-hop-select, send-count, traffic-class, and probe-size. The mandatory parameters are, policy and protocol-origin.
Results from the lsp-ping and lsp-trace operations are displayed using info from state commands.
Performing an LSP ping to an uncolored SR-MPLS TE policy
To check connectivity to a SR-TE tunnel using an uncolored SR-MPLS TE policy, execute the tools oam lsp-ping te-policy sr-uncolored policy command, specifying the uncolored SR-MPLS TE policy name and the protocol origin. To display the results, use the info from state oam lsp-ping te-policy sr-uncolored policy protocol-origin session-id command, specifying the session ID output from the lsp-ping.
Perform an LSP ping to an uncolored SR-MPLS TE policy
--{ + running }--[ ]--
# tools oam lsp-ping te-policy sr-uncolored policy polABCEF protocol-origin local
/:
Initiated LSP Ping for TE-policy polABCEF with session id 49152.
Please check "info from state oam" for result
Display results of the LSP ping
--{ + running }--[ ]--
# info from state oam lsp-ping te-policy sr-uncolored policy polABCEF protocol-origin local session-id 49152
oam {
lsp-ping {
te-policy {
sr-uncolored {
policy polABCEF protocol-origin local {
session-id 49152 {
test-active false
statistics {
round-trip-time {
minimum 83
maximum 83
average 83
standard-deviation 0
}
}
path-destination {
ip-address 127.0.0.1
}
sequence 1 {
probe-size 64
request-sent true
out-interface ethernet-1/31.1
reply {
received true
reply-sender 10.20.1.6
udp-data-length 40
mpls-ttl 255
round-trip-time 83
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}
}
Performing an LSP trace to an uncolored SR-MPLS TE policy
To trace the path of a SR-TE tunnel using an uncolored SR-MPLS TE policy, execute the tools oam lsp-trace te-policy sr-uncolored policy command, specifying the uncolored SR-MPLS TE policy name and the protocol origin. To display the results, use the info from state oam lsp-trace te-policy sr-uncolored policy protocol-origin session-id command, specifying the session ID output from the lsp-trace.
Perform an LSP trace to an uncolored SR-MPLS TE policy
--{ + running }--[ ]--
# tools oam lsp-trace te-policy sr-uncolored policy polABCEF protocol-origin local
/:
Initiated LSP Trace for TE-policy polABCEF with session id 49153.
Please check "info from state oam" for result
Display results of the LSP trace
--{ + running }--[ ]--
# info from state oam lsp-trace te-policy sr-uncolored policy polABCEF protocol-origin local session-id 49153
oam {
lsp-trace {
te-policy {
sr-uncolored {
policy polABCEF protocol-origin local {
session-id 49153 {
test-active false
path-destination {
ip-address 127.0.0.1
}
hop 1 {
probe 1 {
probe-size 188
probes-sent 1
reply {
received true
reply-sender 10.20.1.2
udp-data-length 32
mpls-ttl 1
round-trip-time 165172
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 4
}
}
probe 2 {
probe-size 156
probes-sent 1
reply {
received true
reply-sender 10.20.1.2
udp-data-length 68
mpls-ttl 1
round-trip-time 54673
return-code label-switched-at-stack-depth-n
return-subcode 3
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.3.3
downstream-interface-address 10.10.3.3
mpls-label 1 {
label IMPLICIT_NULL
protocol isis
}
mpls-label 2 {
label 70019
protocol isis
}
mpls-label 3 {
label 70009
protocol isis
}
}
}
}
hop 2 {
probe 1 {
probe-size 156
probes-sent 1
reply {
received true
reply-sender 10.20.1.3
udp-data-length 32
mpls-ttl 2
round-trip-time 103751
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 3
}
}
probe 2 {
probe-size 124
probes-sent 1
reply {
received true
reply-sender 10.20.1.3
udp-data-length 64
mpls-ttl 2
round-trip-time 8262
return-code label-switched-at-stack-depth-n
return-subcode 2
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.5.5
downstream-interface-address 10.10.5.5
mpls-label 1 {
label IMPLICIT_NULL
protocol isis
}
mpls-label 2 {
label 70009
protocol isis
}
}
}
}
hop 3 {
probe 1 {
probe-size 124
probes-sent 1
reply {
received true
reply-sender 10.20.1.5
udp-data-length 32
mpls-ttl 3
round-trip-time 57971
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 2
}
}
probe 2 {
probe-size 92
probes-sent 1
reply {
received true
reply-sender 10.20.1.5
udp-data-length 60
mpls-ttl 3
round-trip-time 101694
return-code label-switched-at-stack-depth-n
return-subcode 1
}
downstream-detailed-mapping 1 {
mtu 1500
address-type ipv4-numbered
downstream-router-address 10.10.10.6
downstream-interface-address 10.10.10.6
mpls-label 1 {
label IMPLICIT_NULL
protocol isis
}
}
}
}
hop 4 {
probe 1 {
probe-size 92
probes-sent 1
reply {
received true
reply-sender 10.20.1.6
udp-data-length 32
mpls-ttl 4
round-trip-time 14393
return-code replying-router-is-egress-for-fec-at-stack-depth-n
return-subcode 1
}
}
}
}
}
}
}
}
}
Ethernet OAM tools and protocols
This section provides information about the Ethernet OAM tools and protocols.
Ethernet connectivity fault management
Ethernet connectivity fault management (ETH-CFM) is a set of Ethernet-layer OAM protocols that provide capabilities to detect, verify, isolate, and report Ethernet connectivity faults. The connectivity and fault management functions are co-defined by IEEE802.1ag and ITU-T Y.1731.
ETH-CFM components
Naming conventions
The IEEE and the ITU-T use their own nomenclature to describe the administrative contexts and functions. This introduces a level of complexity to configuration, discussion, and vendor's naming conventions. Naming conventions lists the IEEE and the ITU-T nomenclature of the ETH-CFM components.
| IEEE 802.1ag naming | ITU-T Y.1731 naming | Function |
|---|---|---|
| Maintenance Domain (MD) | Maintenance Entity (ME) | Administrative scope and reach |
| Maintenance Domain Level | MEG Level | Numerical identifier of the domain |
| Maintenance Association (MA) | Maintenance Entity Group (MEG) | Grouping of service endpoints |
| Maintenance Association Endpoint (MEP) | MEG Endpoint (MEP) | Terminating and origination endpoints |
Maintenance domain
Maintenance domain (MD) or Maintenance entity (ME) is the administrative container that defines the scope, reach, and boundary for testing and faults. It is the area of ownership and management responsibility.
SR Linux supports the following domain name formats:
-
none
-
DNS name string
-
MAC address
-
string
See Configuring a maintenance domain for more information.
Maintenance domain level
Maintenance domain level (MD level) or Maintenance entity group level (MEG level) is the numerical value (0-7) representing the width of the domain. The wider the domain or higher the numerical value, the farther the ETH-CFM packets can travel. The level establishes the processing boundary for the packets. ETH-CFM packets with higher numerical level values flow through MEPs and MIPs configured with equal or lower level values.
See Configuring a maintenance domain for more information.
Maintenance association
Maintenance association (MA) or Maintenance entity group (MEG) is the construct where the different management entities are contained. Each MA is uniquely identified by its MA-ID. The MA-ID comprises the MD level, MA name, and associated format. The MA short name formats (0 to 255) are divided between the IEEE (0 to 31, 64 to 255) and the ITU-T (32 to 63), with five currently defined (1 to 4, 32). Even though the different standards bodies do not have specific support for the other's formats, the domain and association formats can be mixed. The interpretation of the information in the PDU is based on the domain format.
The following formats are supported:
-
vid
-
string
-
integer
-
VPN ID
-
icc-format
See Configuring a maintenance association for more information.
Maintenance association endpoints
Maintenance Association Endpoints (MEP) or MEG Endpoints (MEP) are active ETH-CFM entities that initiate, process, and terminate ETH-CFM functions while following the domain nesting rules. MEPs are configured on the Ethernet interfaces, Ethernet subinterfaces, and LAG subinterfaces. LAG subinterface support is only available on SXR platforms.
A MEP is the unique identifier within the association. Each MEP is uniquely identified by the MA-ID and MEP-ID tuple. This management entity is responsible for initiating, processing, and terminating ETH-CFM packets. MEPs form boundaries that prevent the ETH-CFM packets from flowing beyond their specific scope of responsibility. MEPs within the same MA and at the same level (MA-ID) represent points within a single network instance. The number of MEPs per MA is limited to 64. Each local MEP maintains its own remote MEP database. If there are two Up MEPs in mac-vrf-1 and a remote mac-vrf has a single MEP, the MEP count for the mac-vrf-1 equals six. Each of the local MEPs in the mac-vrf-1 has three entries: itself, the other local Up MEP, and the remote mac-vrf MEP. Exceeding this value generates an error indicating that the remote MEP or local MEP cannot be added because the maximum limit has reached.
A MEP has an up or down direction. It indicates the directions that the packets are generated. The up MEP generates packets toward the switch fabric. The down MEP generates packets toward the line away from the fabric.
A MEP has an active and passive side. Packets that enter the active side of the MEP are compared to the existing MD level and processed accordingly where equal or lower levels are terminated and processed. Higher levels transparently pass through. Packets that enter the passive side of the MEP are exposed to the same processing rules as the active side. However, the passive side of the MEP silently discards those levels that are equal to or lower without processing.
See Configuring a maintenance association end point for more information.
Automatically discover remote MEPs
Remote MEPs can be statically configured as association MEPs using the oam ethcfm domain association association-meps command. As soon as the static remote MEPs are added, the process for timing out the MEP commences.
The MEPs automatically add remote MEPs to the remote MEP database when you enable the remote-mep-auto-discovery command at the maintenance association context. The ETH-CCM packets trigger an addition of the peer MEP ID to the remote MEP database. The remote MEPs added through auto-discovery are uniquely identified. These auto-discovered MEPs can be configured with an aging-timer to remove them from the remote MEP database following a timeout condition that lasts for the duration of the aging timer. These auto-discovered MEPs appear in the MA as association MEPs. These remote MEPs are treated the same way as the statically configured MEPs after they are discovered. When auto-discovery is enabled for remote MEPs, the unexpected connectivity defects are not identified and the defXcon defects are not raised.
See Configuring remote MEP auto-discovery for more information.
Remote MEP ID to MAC address resolution
The Ethernet continuity check messages (ETH-CCMs) contain the pertinent information about the peer. The source Ethernet address in a received ETH-CCM packet is used to generate an entry in the remote MEP-ID to MAC address mapping table for the receiving local MEPs within the same MA. ETH-CFM test protocols, such as ETH-LBM (loopback) and ETH-LTM (linktrace), require a target. This remote MEP-ID resolution table allows the test to target the remote MEP-ID instead of the Layer-2 Ethernet MAC address. A lookup is performed for the local MEP to resolve the remote MEP ID to a Layer-2 MAC address. If the lookup is successful, the test uses the Layer 2 MAC address as the destination address in the Ethernet header. If the lookup is unsuccessful, the ETH-CFM test fails to initiate.
You can clear the automatically learned MAC address of remote MEPs from the Layer 2 address resolution mapping table at multiple levels of the hierarchy. See Clearing the learned remote MEP MAC address for more information.
MAC address assignment to MPs
The allocation of MAC addresses to maintenance points (MPs) varies depending on platform capabilities and configuration modes. The default MP MAC address assignment is platform-specific. A hierarchical preference model is available to select the appropriate MAC address configuration for each MP, based on the configured allocation mode.
MAC address allocation modes in IXR platforms
The IXR platform restricts allocation of MP MAC addressing. The first five-byte prefix (40-bits) of the MEP MAC address must be the same when configured on the same line card. This means the same allocation mode and the mac-pool(if the allocation mode is mac-pool) must be consistent for each line card. This requirement is enforced.
The following are the MAC address allocation modes in IXR platforms that determine the MAC address allocation strategy for the node:
-
oam ethcfm mac-allocation mode port {platform default}
-
oam ethcfm mac-allocation mode mac-pool
An MP can use one of the following two MAC address pools per line card:
-
custom-mac-pool
-
system-generated MAC address pool
-
MAC address allocation modes in SXR platforms
The SXR platforms do not restrict the MAC addressing for MPs. The following are the MAC address allocation modes in SXR platforms that determine the MAC address allocation strategy for the entire network:
- oam ethcfm mac-allocation mode port
-
oam ethcfm mac-allocation mode mac-pool
-
oam ethcfm mac-allocation mode any {platform default}
MP uses one of the following two MAC address pools:
-
custom-mac-pool
-
system-generated MAC address pool
-
-
Note: Because the SXR platforms do not restrict the MP MAC addressing, Nokia recommends that you do not change the default MAC allocation mode, any for SXR platforms. This provides maximum flexibility.
MAC address allocation mode - port
When you configure the MAC address allocation mode as port, the MP uses the port or LAG MAC address advertised by the hardware. The MAC address is derived from the pool based on the host for the MEP, interface port or interface LAG MAC. Any mac-pool or custom-address configurations under the MP are ignored when the MAC allocation mode is set to port.
MAC address allocation mode - mac-pool
For MPs that require a custom MAC address, you can configure a user-defined pool with a starting MAC address and a count of the number of contiguous MAC addresses in the custom MAC address pool. The last byte of the starting MAC address is incremented to create a list of unique MAC addresses for the pool. This custom pool defines the available range of MAC addresses.
The ETH-CFM application on an IXR platform ensures that the combination of starting-mac and the count in the custom pool does not cause any change to the first five bytes of the MAC address. If the starting-mac and count exceed the last byte FF boundary, an error message is displayed indicating that this is not a valid configuration.
For SXR platforms, if the starting-mac and count exceed the last byte FF boundary, the MAC addresses increase the first five-byte prefix rolling over the next available incremental hexadecimal value. The next available hexadecimal value in the first five byte prefix may not be in the last byte of that prefix. Changes to the first byte of a MAC address could have implications for the global/local, or unicast/multicast bits. If the combination of starting-mac and count would cause a change to the first byte of the MAC address, the configuration is rejected.
The system-generated MAC address pool is reserved for ETH-CFM. This pool has a fixed count of 64 MAC addresses with the same first five-byte prefix.
The hierarchical preference is as follows: custom-mac-pool,
system-generated MAC address pool. If neither of the pools are configured, the
ETH-CFM application does not allow the mac-pool mode to be
configured. An error message, ETHCFM mac-allocation mode setting
inconsistent with MP configuration is displayed.
MAC address allocation mode - any
SXR platforms offer flexibility with no restrictions on MAC address assignment, supporting a configurable custom MAC address, mac-pool, or any allocation mode that allows you to mix different allocation schemes. The hierarchical preference is as follows: custom MAC address, custom MAC pool address, system MAC pool address, port hardware address.
ETH-CFM statistics
The IXR platforms provide a system-level CFM transmit and receive counter.
The SXR platforms support system-level and MEP-level statistics with a breakdown for each OpCode. The system maintains an aggregate view of CFM statistics on the node. Every MEP on the system maintains statistics for each OpCode.
See Displaying ETH-CFM statistics for more information.
These statistics are cleared using tools commands.
See Clearing ETH-CFM system statistics and Clearing ETH-CFM statistics for each MEP for more information.
Ethernet continuity check message
An Ethernet continuity check message (ETH-CCM) is a multicast frame that is used for fault detection, notification, and recovery. A CCM is generated by a MEP at a configurable periodic interval and multicast to all other MEPs in the same MA. This is not an echo request/echo response model but a model that multicasts to all endpoints along the datapath. To identify faults, the receiving MEP maintains an internal list of all of the remote MEPs from which it should receive the CCMs. This list is based on the remote MEP ID configuration within the MA. When the local MEP does not receive a CCM from one of the configured remote MEPs within a preconfigured period, it raises an alarm. Several other defect conditions can be detected and the detection of the these defect conditions is specific to the SR Linux platform.
The following consideration applies to the IXR platform:
When CCM is configured on a LAG member port, it may not accurately represent local and remote MEP defect conditions if the LAG member port enters an operational down state. In such cases, the local and remote defects will reflect the conditions at the time the LAG member port went down. CCM will resolve any stale defect states after the LAG member port returns to an operational state, using the standard CCM defect detection algorithm.
See Configuring ETH-CCM for more information.
ETH-CCM hold time
ETH-CCM hold time prevents a MEP from timing out a peer (defRemoteCCM) until an additional time (ccm-hold-time) has elapsed.
The IEEE 802.1ag standard and ITU-T Y.1731 recommendations specify a non-configurable timeout of 3.5 times the CCM interval to determine if a peer has timed out. When CCM is enabled, the ccm-hold-time delay-timeout option provides additional time before declaring a peer lost because of timeout. If a CCM arrives before the delay-timeout reaches zero, the peer does not timeout.
See Configuring ETH-CCM for more information about configuring the ccm-hold-time.
Down MEP CCM local fault action
When a down MEP CCM experiences a connectivity fault equal to or greater than the local MEP's lowest fault priority defect, the local fault action will operationally affect the interface or subinterface on which the MEP is configured.
You can enable or disable this action by configuring the ccm-local-fault and specifying the local fault action to be either permit or deny respectively. The behaviour is as follows:
-
When the ccm-local-fault is configured as permit, the CCM defects affect the operational state of the interface or subinterface on which the MEP is configured.
-
When the ccm-local-fault is configured as deny, a CCM defect, regardless of its priority does not negatively affect the operational state of the interface or subinterface on which the MEP is configured.
-
When transitioning the ccm-local-fault configuration from permit to deny, any negative operational effects on the interface or subinterface are removed.
-
When transitioning the ccm-local-fault configuration from deny to permit, any local MEP fault where the transition is configured is analyzed and necessary action is taken on the interface or subinterface on which the MEP is configured
See Configuring ETH-CCM for more information about configuring the local fault action.
Ethernet remote defect indication
The Ethernet Remote Defect Indication function (ETH-RDI) is used by a MEP to communicate to its peer MEPs that a defect condition has been encountered. Defect conditions such as signal failure may result in the transmission of frames with ETH-RDI information. ETH-RDI is used only when ETH-CCM transmission is enabled. ETH-RDI is a bit in the CCM PDU.
ETH-RDI has the single-ended fault management application. The receiving MEP detects an RDI defect condition, which gets correlated with other defect conditions for this MEP. The absence of received ETH-RDI on all MEPs in the association indicates the absence of defects in the entire MEG.
A MEP that is in a defect condition transmits frames with ETH-RDI information. A MEP, upon receiving frames with ETH-RDI information, determines that its peer MEP has encountered a defect condition.
Ethernet loopback
Ethernet loopback messages (ETH-LBMs) are unicast or multicast frames transmitted by a MEP to verify connectivity to a particular maintenance point, reporting destination reachability. A MEP responds to ETH-LBMs with loopback reply (ETH-LBR) messages.
Ethernet loopback tests are performed using the tools oam ethcfm domain association mep on-demand loopback command. See Performing an Ethernet CFM loopback test for more information. A MEP can only have a single active LBM test executing at a specific time. A MEP stores one test result, and the subsequent test results are overwritten.
Ethernet linktrace
Ethernet linktrace messages (ETH-LTMs) are multicast frames transmitted by a MEP to trace the path (hop-by-hop) to a peer MEP in the same MA. The peer MEP responds with an Ethernet linktrace reply message (ETH-LTR) after successfully inspecting the linktrace message. If the received linktrace message that has a TTL greater than one, a lookup is performed for the target unicast MAC in the LTM PDU. The message is then processed (responded to and forwarded) along the path if the target MAC address is found in the FDB.
Configuring ETH-CFM tools and protocols
This section provides information about how to configure ETH-CFM tools and examples of common configurations.
Configuring a maintenance domain
To configure a maintenance domain (MD), you specify the domain ID, domain name format, domain name, and the level in the ethcfm context. The supported domain name formats include, none, dns-like, mac-address, and string. The domain level is used to indicate the nesting relationship between the current domain and other domains. The domain level value ranges from 0 to 7.
Configuring an MD
The following example configures an MD.
--{ + candidate shared default }--[ ]--
# info oam ethcfm
oam {
ethcfm {
domain MD1 {
domain-format string
level 1
md-name {
name domain1
}
}
}
}Configuring a maintenance association
To configure a maintenance association (MA), you specify the MA ID, MA name format and the name. The supported MA name formats include, vlan-id, string, integer, vpn-id, and icc-based.
Configuring an MA
The following example configures an MA.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain MD1
oam {
ethcfm {
domain MD1 {
domain-format string
level 1
md-name {
name domain1
}
association MA1 {
association-format string
ma-name {
name association1
}
}
}
}
}Configuring a maintenance association end point
Perform the following steps to configure a maintenance association end point (MEP):
-
Configure an association MEP by specifying the network-instance and the MEP ID of the association-mep in the association context. If the MEP is non-subinterface based, hosted on the interface, the network-instance is not required. See Configuring an association MEP for an example of an association MEP configuration.
-
Enable the MEP, specify the interface-ref, and direction in the mep context.
The down MEP configuration scenarios are described in the following table.
Table 4. Down MEP configuration scenarios MAC-VRF service point to point and multi-point (L2 subinterface)
IP-VRF service and default network instance (L3 subinterface)
Physical port (interface)
Down MEP on L2 subinterfaces including L2 subinterfaces on LAG (SXR only) for all supported encapsulations; single, double, and untagged
Down MEP on L3 subinterfaces including L3 subinterface on LAG (SXR only) for all supported encapsulations; single, double, and untagged
Down MEP on the Ethernet interface and LAG member interfaces (SXR only). The CFM packets are sent untagged
Down MEP is not supported for EVPN-MPLS, EVPN-VPLS, and VxLAN
Down MEP is not supported on the MP-BGP connection interconnecting the IP VRF to remote sites
Domain level 0 and 1 only
See Configuring a local down MEP for an example of a local down MEP configuration.
Up MEPs are supported in MAC-VRF L2 subinterfaces including the L2 subinterfaces on LAG (SXR only) for all supported encapsulations; tagged, single, double, and untagged. UP MEPs are not supported for EVPN-MPLS, EVPN-VPLS, and VxLAN. See Configuring a local up MEP for an example of a local up MEP configuration.
Configuring an association MEP
The following example configures an association MEP. An association MEP is a list of MEPs in the association. The MEP configuration is required to transition one of the association MEPs to a local MEP.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain MD1 association MA1
oam {
ethcfm {
domain MD1 {
association MA1 {
association-format string
ma-name {
name association1
}
network-instance {
name oam-test
}
association-meps 1 {
}
association-meps 2 {
}
}
}
}
}Configuring a local down MEP
The following example configures a local down MEP.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain MD1 association MA1 mep 1
oam {
ethcfm {
domain MD1 {
association MA1 {
association-meps 1 {
}
mep 1 {
admin-state enable
direction down
interface-ref {
interface ethernet-1/10
subinterface 3
}
}
}
}
}
}Configuring a local up MEP
The following example configures a local up MEP.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain MD3 association MA3 mep 1
oam {
ethcfm {
domain MD3 {
association MA3 {
association-meps 1 {
}
mep 1 {
admin-state enable
direction up
interface-ref {
interface ethernet-1/20
subinterface 2
}
}
}
}
}
}Configuring remote MEP auto-discovery
There are two methods to add remote MEPs to the remote MEP database:
-
Manually configure a MEP. See Configuring a maintenance association end point for more information about configuring a MEP.
-
Configure remote MEP auto-discovery
To automatically add the remote MEP IDs contained in the received CCM to the remote MEP database, you enable the admin-state of the remote-mep-auto-discovery command and optionally specify the aging-timer value for a specific association.
Configuring remote MEP auto-discovery
The following example configures remote MEP auto discovery.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain MD2 association MD2
oam {
ethcfm {
domain MD2 {
association MD2 {
association-format string
ma-name {
name association2
}
remote-mep-auto-discovery {
admin-state enable
aging-timer 86400
}
}
}
}
}Configuring ETH-CCM
Perform the following steps to enable ETH-CCM and configure the ETH-CCM parameters:
-
Configure a maintenance domain. See Configuring a maintenance domain for more information.
-
Configure a maintenance association. See Configuring a maintenance association for more information.
-
Configure maintenance end points. See Configuring a maintenance association end point for more information.
-
To transmit CCM, enable the admin state of the ccm-transmit command under the continuity-check context.
-
To configure the lowest priority defect for the local MEP, configure the oam ethcfm domain association mep continuity-check lowest-priority-defect command.
-
To enable and disable local fault action, configure the oam ethcfm domain association mep continuity-check ccm-local-fault command.
-
To generate CCM at periodic intervals, specify the ccm-interval time in the association context.
-
To configure CCM hold time, specify the time in the ccm-hold-time parameter delay-timeout option under the association context.
-
To configure the sender ID TLV information to be included in the ETH-CCM and ETH-LTM packets, you specify how the Sender ID TLV information is included using the sender-id-permission-type command (SXR only).
Before configuring the sender-id-permission-type as chassis, ensure that you have performed the global sender ID configuration as follows:
-
Configure the sender ID using the oam ethcfm sender-id command.
-
If you configure the oam ethcfm sender-id chassis-type as local, then specify the local name in the chassis-local-name option. See Configuring chassis type as local for sender ID TLV for an example configuration.
-
If you configure the oam ethcfm sender-id chassis-type as system, then do not configure the chassis-local-name option. See Configuring chassis type as system for sender ID TLV for an example configuration.
-
-
To automatically add remote MEP-IDs in the received CCM, enable the admin-state of the remote-mep-auto-discovery command and optionally specify the aging-timer value for a specific association.
Configuring ETH-CCM
The following example enables the Ethernet continuity check and configures the ETH-CCM parameters.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain MD1 association MA1
oam {
ethcfm {
domain MD1 {
association MA1 {
association-format string
sender-id-permission-type chassis
ccm-interval 10ms
ma-name {
name association1
}
network-instance {
name test
}
ccm-hold-time {
delay-timeout 10
}
remote-mep-auto-discovery {
admin-state enable
aging-timer 86400
}
association-meps 1 {
}
mep 1 {
admin-state enable
direction down
ccm-ltm-priority 1
interface-ref {
interface ethernet-1/10
subinterface 1
}
continuity-check {
ccm-transmit enable
ccm-local-fault {
action permit
}
}
}
}
}
}
}Configuring chassis type as local for sender ID TLV
--{ + candidate shared default }--[ ]--
# info oam ethcfm sender-id
oam {
ethcfm {
sender-id {
chassis-type local
chassis-local-name Nokia123
}
}
}Configuring chassis type as system for sender ID TLV
--{ + candidate shared default }--[ ]--
# info oam ethcfm sender-id
oam {
ethcfm {
sender-id {
chassis-type system
}
}
}Configuring MAC address allocation modes
You can configure MAC address allocation mode using the oam ethcfm mac-allocation mode command. The MAC address allocation mode, any applies only to SXR platforms.
See Configuring MAC address mode in IXR platforms for an example of a MAC address mode configuration in IXR platforms.
See Configuring MAC address mode in SXR platforms for an example of a MAC address mode configuration in SXR platforms.
You can then assign the MAC address allocation to a MEP as shown in the example, Assigning the mac-allocation to a MEP.
Configuring MAC address mode in IXR platforms
This example configures MAC address mode in IXR platforms.
--{ + candidate shared default }--[ ]--
# info oam ethcfm mac-allocation
oam {
ethcfm {
mac-allocation {
mode mac-pool
custom-mac-pool pool1 {
starting-mac 00:00:00:00:00:FE
count 1
}
}
}
}Configuring MAC address mode in SXR platforms
This example configures MAC address mode in SXR platforms.
--{ + candidate shared default }--[ ]--
# info oam ethcfm mac-allocation
oam {
ethcfm {
mac-allocation {
mode any
custom-mac-pool pool1 {
starting-mac 00:00:00:00:00:FE
count 64
}
}
}
}Assigning the mac-allocation to a MEP
This example assigns the MAC address allocation to a MEP.
--{ + candidate shared default }--[ ]--
# info oam ethcfm domain md-1
oam {
ethcfm {
domain md-1 {
domain-format none
association as-1 {
association-format string
ma-name {
name name-1
}
network-instance {
name n-1
}
association-meps 1 {
}
mep 1 {
admin-state enable
direction down
interface-ref {
interface ethernet-1/1
subinterface 1
}
mac-address {
custom-mac-pool {
name pool1
index 1
}
}
}
}
}
}
}Performing an Ethernet CFM loopback test
To initiate an ETH-CFM loopback test, execute the tools oam ethcfm domain association mep on-demand loopback command, specifying the domain, association, MEP, and test parameters such as target MAC address/remote MEP ID. See Initiating ETH-CFM linktrace test using MAC address and Initiating ETH-CFM linktrace test using remote MEP ID for examples of ETH-CFM loopback test initiation using MAC address and remote MEP ID respectively.
To display the results, use the info from state oam ethcfm domain association mep loopback command, specifying the domain, association, and MEP. See Displaying ETH-CFM loopback test results for an example of an ETH-CFM loopback test result.
To terminate an ETH-CFM loopback test, execute the tools oam ethcfm domain association mep terminate-active-test loopback, specifying the domain, association, and MEP information. See Terminating ETH-CFM loopback test for an example of an ETH-CFM loopback test termination.
Initiating an ETH-CFM loopback test using MAC address
The following example initiates the ETH-CFM loopback test using MAC address.
--{ + candidate shared default }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 11 on-demand loopback target 00:01:01:FF:00:1F
/oam/ethcfm/domain[domain-id=MD1]/association[association-id=MA1]/mep[mep-id=11]:
Loopback Test from '.oam.ethcfm.domain{.domain_id=="MD1"}.association{.association_id=="MA1"}.mep{.mep_id==11}' to 00:01:01:FF:00:1F is initiated.
Initiating ETH-CFM loopback test using remote MEP ID
The following example initiates the ETH-CFM loopback test using remote MEP ID.
--{ + candidate shared default }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 11 on-demand loopback target 10
/oam/ethcfm/domain[domain-id=MD1]/association[association-id=MA1]/mep[mep-id=11]:
Loopback Test from '.oam.ethcfm.domain{.domain_id=="MD1"}.association{.association_id=="MA1"}.mep{.mep_id==11}' to 00:01:01:FF:00:1F is initiated.
Displaying ETH-CFM loopback test results
The following displays the ETH-CFM loopback test results.
--{ + running }--[ ]--
# info from state /oam ethcfm domain MD1 association MA1 mep 11 loopback
oam {
ethcfm {
domain MD1 {
association MA1 {
mep 11 {
loopback {
status inactive
next-sequence-number 31
unicast-latest-run {
test-status completed
start-time 2024-10-29T14:11:32.807Z
end-time 2024-10-29T14:11:34.470Z
remote-mep-id 10
destination-mac-address 00:01:01:FF:00:1F
priority 7
data-length 0
interval 0s
sequence-number 21
statistics {
sent-packets 10
received-in-order 10
received-out-of-order 0
received-unexpected-sequence-number 0
received-bad-msdu 0
packet-loss 0.00
}
}
}
}
}
}
}
}
Terminating ETH-CFM loopback test
The following example terminates the ETH-CFM loopback test.
--{ + candidate shared default }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 11 terminate-active-test loopbackPerforming an Ethernet CFM linktrace test
To initiate an Ethernet CFM linktrace test, use the tools oam ethcfm domain association mep on-demand linktrace command, specifying the domain, association, MEP, and test parameters such as target MAC address/remote MEP ID and TTL value. See Initiating ETH-CFM linktrace test using MAC address and Initiating ETH-CFM linktrace test using remote MEP ID for examples of ETH-CFM linktrace test initiation using MAC address and MEP ID respectively.
To display the results, use the info from state oam ethcfm domain association mep linktrace command, specifying the domain, association, and MEP. See Displaying ETH-CFM linktrace test results for an example of an ETH-CFM linktrace test result.
To terminate an ETH-CFM linktrace test, execute the tools oam ethcfm domain association mep terminate-active-test linktrace command, specifying the domain, association, and MEP information. See Terminating ETH-CFM linktrace test for an example of an ETH-CFM linktrace test termination.
Initiating ETH-CFM linktrace test using MAC address
The following example initiates the ETH-CFM linktrace test using MAC address.
--{ + candidate shared default }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 11 on-demand linktrace target 00:01:01:FF:00:1F
/oam/ethcfm/domain[domain-id=MD1]/association[association-id=MA1]/mep[mep-id=11]:
Linktrace Test from '.oam.ethcfm.domain{.domain_id=="MD1"}.association{.association_id=="MA1"}.mep{.mep_id==11}' to 00:01:01:FF:00:1F is initiated.
Initiating ETH-CFM linktrace test using remote MEP ID
The following example initiates the ETH-CFM linktrace test using remote MEP ID.
--{ + candidate shared default }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 11 on-demand linktrace target 10
/oam/ethcfm/domain[domain-id=MD1]/association[association-id=MA1]/mep[mep-id=11]:
Linktrace Test from '.oam.ethcfm.domain{.domain_id=="MD1"}.association{.association_id=="MA1"}.mep{.mep_id==11}' to 00:01:01:FF:00:1F is initiated.
Displaying ETH-CFM linktrace test results
--{ + running }--[ ]--
# info from state /oam ethcfm domain MD1 association MA1 mep 11 linktrace
oam {
ethcfm {
domain MD1 {
association MA1 {
mep 11 {
linktrace {
status inactive
next-transaction-number 1804289384
latest-run {
test-status completed
start-time 2024-10-29T14:13:29.987Z
end-time 2024-10-29T14:13:36.988Z
remote-mep-id 10
destination-mac-address 00:01:01:FF:00:1F
priority 7
transaction-id 1804289383
ttl 64
reply 1 {
reply-ttl 63
forwarded false
terminal-mep true
ltr-relay hit
ingress-action ok
ingress-mac 00:01:01:FF:00:1F
last-egress-identifier {
integer 0
mac-address 00:01:03:FF:00:20
}
next-egress-identifier {
integer 0
mac-address 00:00:00:00:00:00
}
}
}
}
}
}
}
}
}
Terminating ETH-CFM linktrace test
The following example terminates the ETH-CFM linktrace test.
--{ + candidate shared default }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 11 terminate-active-test linktraceDisplaying ETH-CFM statistics
To display system-level statistics, use the info from state oam ethcfm statistics command. See Displaying system-level ETH-CFM statistics for an example of ETH-CFM statistics at the system level.
To display MEP-level statistics, use the info from state oam ethcfm domain association mep command, specifying the domain name, association name, and MEP ID. Per OpCode statistics are only available on the SXR. IXR reports a system wide receive-count and transmit-count. See Displaying MEP-level ETH-CFM statistics for an example of ETH-CFM statistics at the MEP level.
Displaying system-level ETH-CFM statistics
The following example displays the ETH-CFM statistics at the system level (SXR example).
--{ + candidate shared default }--[ ]--
# info from state oam ethcfm statistics
oam {
ethcfm {
statistics {
receive-count 3
transmit-count 3
receive-congestion-drops 0
transmit-congestion-drops 0
error-discards 0
opcode total {
transmitted 2598
received 2598
}
opcode other {
transmitted 0
received 0
}
opcode ccm {
transmitted 2595
received 2595
}
opcode lbr {
transmitted 0
received 3
}
opcode lbm {
transmitted 3
received 0
}
opcode ltr {
transmitted 0
received 1
}
opcode ltm {
transmitted 1
received 0
}
opcode dmr {
transmitted 0
received 0
}
opcode dmm {
transmitted 0
received 0
}
opcode slr {
transmitted 0
received 0
}
opcode slm {
transmitted 0
received 0
}
}
}
}Displaying MEP-level ETH-CFM statistics
The following example displays the ETH-CFM statistics at the MEP level.
--{ + candidate shared default }--[ ]--
# info from state oam ethcfm domain MD1 association MA1 mep 30
oam {
ethcfm {
domain MD1 {
association MA1 {
mep 30 {
admin-state enable
direction down
mac-address AA:BB:CC:AC:AC:AC
ccm-ltm-priority 7
interface-ref {
interface lag1
subinterface 2
}
continuity-check {
ccm-transmit enable
lowest-fault-priority-defect mac-remote-error-xcon
highest-priority-defect-found none
ccm-sequence-error-count 0
sent-interface-status up
sent-port-status up
sent-remote-defect-indicator false
active-defects [
none
]
ccm-local-fault {
action deny
}
}
remote-mep 40 {
mac-address AA:BB:CC:CA:CA:CA
auto-discovered false
receiving-ccm true
remote-mep-state ok
remote-mep-failed-ok-time 374
remote-defect-indicator false
port-status-tlv up
interface-status-tlv up
}
loopback {
status inactive
next-sequence-number 4
unicast-latest-run {
test-status completed
start-time 2024-04-30T11:11:46.483Z
end-time 2024-04-30T11:11:49.498Z
remote-mep-id 0
destination-mac-address AA:BB:CC:CA:CA:CA
priority 7
data-length 0
interval 1s
sequence-number 1
statistics {
sent-packets 10
received-in-order 10
received-out-of-order 0
received-bad-msdu 0
packet-loss 0.00
}
}
}
linktrace {
status inactive
next-transaction-number 1804289384
latest-run {
test-status completed
start-time 2024-04-30T11:11:53.877Z
end-time 2024-04-30T11:12:00.878Z
remote-mep-id 0
destination-mac-address AA:BB:CC:CA:CA:CA
priority 7
transaction-id 1804289383
ttl 64
reply 1 {
reply-ttl 63
forwarded false
terminal-mep true
ltr-relay hit
egress-action ok
egress-mac AA:BB:CC:CA:CA:CA
last-egress-identifier {
integer 0
mac-address AC:AC:AC:CC:BB:AA
}
next-egress-identifier {
integer 0
mac-address 00:00:00:00:00:00
}
}
}
}
opcode total {
transmitted 2598
received 2598
}
opcode other {
transmitted 0
received 0
}
opcode ccm {
transmitted 2595
received 2595
}
opcode lbr {
transmitted 0
received 3
}
opcode lbm {
transmitted 3
received 0
}
opcode ltr {
transmitted 0
received 1
}
opcode ltm {
transmitted 1
received 0
}
opcode dmr {
transmitted 0
received 0
}
opcode dmm {
transmitted 0
received 0
}
opcode slr {
transmitted 0
received 0
}
opcode slm {
transmitted 0
received 0
}
}
}
}
}
}
Clearing the learned remote MEP MAC address
You can clear the automatically learned remote MEP MAC address from the Layer 2 address resolution mapping table at multiple levels of the hierarchy.
Clearing learned remote MEP MAC addresses at system-level
The following example clears automatically learned remote MEP MAC addresses at the system level.
--{ + running }--[ ]--
# tools oam ethcfm delete-learned-remote-macsClearing learned remote MEP MAC addresses at domain-level
The following example clears automatically learned remote MEP MAC addresses at the domain level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 delete-learned-remote-macsClearing learned remote MEP MAC addresses at association-level
The following example clears automatically learned remote MEP MAC addresses at the association level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 association MA1 delete-learned-remote-macsClearing learned remote MEP MAC addresses at MEP-level
The following example clears automatically learned remote MEP MAC addresses at the MEP level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 1 delete-learned-remote-macsClearing learned remote MEP MAC addresses at remote MEP-level
The following example clears automatically learned remote MEP MAC addresses at the remote MEP level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 1 remote-mep 2 delete-learned-remote-macsClearing automatically learned MEPs
You can clear automatically learned remote MEPs from the remote MEP database, including all its attributes and at multiple levels of the hierarchy.
Clearing automatically learned MEPs at system-level
The following example clears automatically learned remote MEPs at the system level.
--{ + running }--[ ]--
# tools oam ethcfm delete-auto-discovered-mepsClearing automatically learned MEPs at domain-level
The following example clears automatically learned remote MEPs at the domain level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 delete-auto-discovered-mepsClearing automatically learned MEPs at association-level
The following example clears automatically learned remote MEPs at the association level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 association MA1 delete-auto-discovered-mepsClearing automatically learned MEPs at remote MEP-level
The following example clears automatically learned remote MEPs at the MEP level.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 1 remote-mep 2 delete-auto-discovered-mepsClearing ETH-CFM system statistics
You can clear the ETH-CFM system statistics under the ethcfm statisticscommand that resets the benchmark in the application.
Clearing ETH-CFM system statistics
The following example clears ETH-CFM system statistics.
--{ running }--[ ]--
# tools oam ethcfm clear-cfm-statisticsClearing ETH-CFM statistics for each MEP
You can clear the ETH-CFM statistics for each MEP under the ethcfm domain association mep-id command that resets the benchmark in the application.
Clearing ETH-CFM statistics for each MEP
The following example clears statistics for each MEP.
--{ + running }--[ ]--
# tools oam ethcfm domain MD1 association MA1 mep 1 clear-cfm-statisticsBidirectional Forwarding Detection
BFD is a lightweight mechanism used to monitor the liveliness of a remote neighbor. It is lightweight enough so that the ongoing sending and receiving mechanism can be implemented in the forwarding hardware. Because of this lightweight nature, BFD can send and receive messages at a much higher rate than other control plane hello mechanisms providing faster detection of connection failures.
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 – see Configuring BFD under the BGP protocol
-
next hops for static routes – see Configuring BFD for static routes
-
OSPF adjacencies – see Configuring BFD under OSPF
-
IS-IS adjacencies – see Configuring BFD under IS-IS
-
link layer LDP adjacencies - see Configuring BFD on an LDP interface
SR Linux supports one BFD session per port/connector, or up to 1152 sessions for an eight slot chassis, depending on the hardware configuration.
On SR Linux systems that support link aggregation groups (LAGs), SR Linux supports micro-BFD, where BFD sessions are established for individual members of a LAG. 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.
Configuring BFD for a subinterface
You can enable BFD with an associated subinterface and set values for intervals and criteria for declaring a session down.
Timer values are in microseconds. The detection interval for the BFD session is calculated by multiplying the value of the negotiated transmission interval by the value specified in this field.
The following example configures BFD for a subinterface.
--{ candidate shared default }--[ ]--
# info bfd
bfd {
subinterface ethernet-1/2.1 {
admin-state enable
desired-minimum-transmit-interval 250000
required-minimum-receive 250000
detection-multiplier 3
}
}
Configuring BFD under the BGP protocol
You can configure BFD under the BGP protocol at the global, group, or neighbor level.
Before enabling BFD, you must first configure it for a subinterface and set timer values. See Configuring BFD for a subinterface.
Configure BFD under the BGP protocol at the global level
--{ candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
failure-detection {
enable-bfd true
}
}
}
}
}
Configure BFD for a BGP peer group
The following example configures BFD for the links between peers within an associated BGP peer group.
--{ * candidate shared default }--[ ]--
# info network-instance default protocols bgp
network-instance default {
protocols {
bgp {
group test {
failure-detection {
enable-bfd true
}
}
}
}
}Configure BFD for BGP neighbors
The following example configures BFD for the link between BGP neighbors.
--{ candidate shared default }--[ ]--
# info network-instance default protocols bgp
network-instance default {
protocols {
bgp {
neighbor 192.168.0.1 {
failure-detection {
enable-bfd true
fast-failover true
}
}
}
}
}
Configuring BFD for static routes
You can use BFD as a failure detection mechanism for monitoring the reachability of next hops for static routes. When BFD is enabled for a static route, it makes an active BFD session between the local router and the defined next hops required as a condition for a static route to be operationally active.
You enable BFD for specific next-hop groups; as a result, BFD is enabled for any static route that refers to the next-hop group. If multiple next hops are defined within the next-hop group, a BFD session is established between the local address and each next hop in the next-hop group.
A static route is considered operationally up if at least one of the configured next-hop addresses can establish a BFD session. If the BFD session fails, the associated next hop is removed from the FIB as an active next hop.
The following example enables BFD for a static route next hop:
--{ * candidate shared default }--[ network-instance black ]--
# info next-hop-groups
next-hop-groups {
group static-ipv4-grp {
admin-state enable
nexthop 1 {
failure-detection {
enable-bfd {
local-address 192.0.2.1
}
}
}
}
}
A BFD session is established between the address configured with the local-address parameter and each next-hop address before that next-hop address is installed in the forwarding table.
All next-hop BFD sessions share the same timer settings, which are taken from the BFD configuration for the subinterface where the address in local-address parameter is configured. See Bidirectional Forwarding Detection.
Configuring BFD under OSPF
For OSPF and OSPFv2, you can enable BFD at the interface level to monitor the connectivity between the router and its attached network.
--{ candidate shared default }--[ ]--
# info network-instance default protocols ospf
network-instance default {
interface ethernet-1/1.1 {
interface-ref {
interface ethernet-1/1
subinterface 1
}
}
protocols {
ospf {
instance o1 {
version ospf-v2
area 1.1.1.1 {
interface ethernet-1/1.1 {
failure-detection {
enable-bfd true
}
}
}
}
}
}
}
Configuring BFD under IS-IS
You can configure BFD at the interface level for IS-IS. You can optionally configure a BFD-enabled TLV to be included for IPv4 or IPv6 on the IS-IS interface.
--{ candidate shared default }--[ ]--
# info network-instance default protocols isis
network-instance default {
interface ethernet-1/1.1 {
interface-ref {
interface ethernet-1/1
subinterface 1
}
}
protocols {
isis {
instance i1 {
ipv4-unicast {
admin-state enable
}
interface ethernet-1/1.1 {
ipv4-unicast {
enable-bfd true
include-bfd-tlv true
}
}
}
}
}
}
Configuring BFD on an LDP interface
You can configure BFD on an IPv4 or IPv6 LDP interface.
--{ +* candidate shared default }--[ ]--
# info network-instance default protocols ldp
network-instance default {
protocols {
ldp {
dynamic-label-block d1
discovery {
interfaces {
hello-holdtime 30
hello-interval 10
interface ethernet-1/1.1 {
ipv4 {
admin-state enable
enable-bfd true
}
ipv6 {
admin-state enable
enable-bfd true
}
}
}
}
}
}
}Viewing the BFD state
Use the info from state command to verify the BFD state for a network-instance.
# info from state bfd network-instance default peer 30
bfd {
network-instance default {
peer 30 {
oper-state up
local-address 192.168.1.5
remote-address 192.168.1.3
remote-discriminator 25
subscribed-protocols bgp_mgr
session-state UP
remote-session-state UP
last-state-transition 2020-01-24T16:22:55.224Z
failure-transitions 0
local-diagnostic-code NO_DIAGNOSTIC
remote-diagnostic-code NO_DIAGNOSTIC
remote-minimum-receive-interval 1000000
remote-control-plane-independent false
active-transmit-interval 250000
active-receive-interval 250000
remote-multiplier 3
async {
last-packet-transmitted 2020-01-24T16:23:19.385Z
last-packet-received 2020-01-24T16:23:18.906Z
transmitted-packets 32
received-packets 32
up-transitions 1
}
}
}
}
Micro-BFD
Micro-BFD refers to running BFD over the individual links in a LAG to monitor the bidirectional liveliness of the Ethernet links that make up the LAG.
A LAG member cannot be made operational within the LAG until the micro-BFD session is fully established. If a micro-BFD session fails, the corresponding Ethernet link is taken out of service from the perspective of the LAG.
Micro-BFD is supported on Ethernet LAG interfaces with an IP interface. Micro-BFD sessions are associated with each individual link. When enabled, the state of the individual links depends on the micro-BFD session state:
-
Micro-BFD sessions must be established between both endpoints of a link before the link can be operationally up.
-
If the micro-BFD session fails, the associated Ethernet link becomes operationally down from the perspective of the LAG.
-
If LACP is not enabled for the LAG and the Ethernet port is up, the system attempts to re-establish the micro-BFD session with the far end of the link.
-
If LACP enabled for the LAG and the Ethernet port is up, the system attempts to re-establish the micro-BFD session with the far end of the link when LACP reaches distributing state.
If a link is not active for forwarding from the perspective of a LAG, ARP can still be performed across the link. For example, when a link is being brought up, and its micro-BFD session is not yet established, ARP can still be performed for the MAC address at the far end of the link, even though the link is not yet part of the LAG.
Micro-BFD packets bypass ingress and egress subinterface/interface ACLs, but received micro-BFD packets can be matched by CPM filters for filtering and logging.
Micro-BFD is supported on all SR Linux systems that also support LAGs: 7250 IXR; 7250 IXR-X1b/X3b , 7220 IXR-D1, D2, and D3; 7220 IXR-H2 and H3.
Configuring micro-BFD for a LAG interface
To configure micro-BFD for a LAG interface, you configure IP addresses to be used as the source address for IP packets and a remote address for the far end of the BFD session.
You can specify the minimum interval in microseconds between transmission of BFD control packets, as well as the minimum acceptable interval between received BFD control packets. The detection-multiplier setting specifies the number of packets that must be missed to declare the BFD session as down.
--{ * candidate shared default }--[ ]--
# info bfd micro-bfd-sessions
micro-bfd-sessions {
lag-interface lag1 {
admin-state enable
local-address 192.35.2.5
remote-address 192.35.2.3
desired-minimum-transmit-interval 250000
required-minimum-receive 250000
detection-multiplier 3
}
}
Viewing the micro-BFD state
Use the info from state command to verify the micro-BFD state for members of a LAG interface.
# info from state micro-bfd-sessions lag-interface lag1 member-interface ethernet 2/1
micro-bfd-sessions
lag-interface lag1 {
admin-state UP
local-address 192.0.2.5
remote-address 192.0.2.3
desired-minimum-transmit-interval 250000
required-minimum-receive 250000
detection-multiplier 3
member-interface ethernet 2/1 {
session-state UP
remote-session-state UP
last-state-transition 2020-01-24T16:22:55.224Z
last-failure-time 2020-01-24T16:22:55.224Z
failure-transitions 0
local-discriminator 25
remote-discriminator 25
local-diagnostic-code NO_DIAGNOSTIC
remote-diagnostic-code NO_DIAGNOSTIC
remote-minimum-receive-interval 1000000
remote-control-plane-independent false
active-transmit-interval 250000
active-receive-interval 250000
remote-multiplier 3
async {
last-clear 2020-01-23T16:21:19.385Z
last-packet-transmitted 2020-01-24T16:23:19.385Z
last-packet-received 2020-01-24T16:23:18.906Z
transmitted-packets 32
received-errored-packets 3
received-packets 32
up-transitions 1
}
}
}
}
Seamless Bidirectional Forwarding Detection (S-BFD)
Overview
BFD detects connection failures faster than other hello mechanisms. However, if many BFD sessions are configured to detect links, very long negotiation times result in reduced system performance. You can configure 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. A per-session state is maintained only at the head-end of a session. The tail-end reflects the BFD control packets back to the head-end.
Initiator and reflector
An S-BFD session is established between an initiator and a reflector. SR Linux supports only one instance of a reflector in each node. A discriminator is assigned to initiator and reflector.
The initiator initiates an S-BFD session on a network node and performs a continuity test by sending S-BFD packets to the reflector. The reflector receives the S-BFD packet and reflects the S-BFD packet back along with the state value based on its current state.
The following information is swapped in the S-BFD response:
-
The source and destination IP addresses
-
The source and destination UDP ports
-
The initiator and reflector discriminators
See Configuring an S-BFD reflector for information about how to configure a reflector. An SR Linux router can be both an initiator and a reflector, thereby allowing you to configure different S-BFD sessions.
S-BFD discriminator
SR Linux supports the following methods of mapping an S-BFD remote IP address with its discriminator:
-
Static configuration
-
Automatic learning using opaque IS-IS routing extensions
You can statically configure an S-BFD remote IP address and discriminator for each network instance. The S-BFD initiator immediately starts sending S-BFD packets if the discriminator value of the far-end reflector is known. A session set up is not required. The INIT state is not present in an S-BFD session. The initiator state changes from AdminDown to Up when it begins to send S-BFD packets. The following table lists the S-BFD packet information that the initiator sends to the reflector.
|
Source IP address |
This is the local session IP address. For IPv6, this is a global unicast address belonging to the node. |
|
Destination IP address |
This is the IP address of the reflector, and it needs to be configured. |
|
My discriminator |
This is the locally assigned discriminator. |
|
Your discriminator |
This is the discriminator value of the reflector, and it needs to be configured. |
See Statically configuring an S-BFD discriminator for more information about how to configure an S-BFD discriminator.
If the initiator receives a valid response from the reflector with an Up state, the initiator declares the S-BFD session state as Up. If the initiator fails to receive a specific number of responses, as determined by the BFD multiplier in the BFD template for the session, the initiator declares the S-BFD session state as Failed. If any of the discriminators change, the session fails and the router attempts to restart with the new values. If the reflector discriminator changes at the far-end peer, the session fails. The mapping may not have been updated locally before the system checks for a new reflector discriminator from the local mapping table. Therefore the session is bounced and brought up with the new values. If any discriminator is deleted, the corresponding S-BFD sessions are deleted.
SR Linux supports automatic mapping of an S-BFD remote IP address with its discriminator using the IS-IS protocol extensions. The IS-IS protocol uses a sub-TLV of the capabilities TLV to advertise and distribute discriminators. See Automatically mapping an S-BFD discriminator for more information.
Routed and controlled return path
S-BFD supports the following forms of returning transmitted S-BFD packets back to the initiator:
-
Routed return
-
Controlled return path
In routed return, S-BFD uses an initiator-reflector model where an initiator sends S-BFD messages to a reflector using the discriminator of the reflectors. The reflector reflects the S-BFD message back to the initiator via IPv4 or IPv6 routing.
In controlled return path for SR-Policy, the initiating node embeds a SID, typically a binding SID that is used by the reflecting node, to determine the correct path back to the initiator. The S-BFD message is then forwarded to a path that is identical or similar to the original path that the message was sent by the initiator.
S-BFD state
S-BFD session state is reported at the network instance, policy, and system levels. See Viewing the S-BFD state for more information.
Statically configuring an S-BFD discriminator
To statically map an S-BFD remote IP address with its discriminator for each network instance, you configure the network-instance bfd seamless-bfd command and specify the peer IP address and discriminator.
Statically configuring an S-BFD discriminator
This is an example for statically configuring an S-BFD discriminator.
--{ + candidate shared default }--[ ]--
# info network-instance default bfd seamless-bfd
network-instance default {
bfd {
seamless-bfd {
peer 192.0.2.0 {
discriminator 30
}
}
}
}Automatically mapping an S-BFD discriminator
SR Linux supports automatic mapping of an S-BFD remote IP address with its discriminator using IGP routing protocol extensions. The IS-IS protocol uses a sub-TLV of the capabilities TLV to distribute S-BFD discriminators. There is no explicit configuration to enable or disable router capability advertisement.
Output from BFD state
This example shows an output of an automatically mapped S-BFD discriminator.
--{ + running }--[ ]--
# info from state bfd
bfd {
total-bfd-sessions 2
total-unmatched-bfd-packets 1
network-instance base {
peer 16385 {
oper-state up
local-address 1.1.1.3
remote-address 127.0.64.1
remote-discriminator 524289
subscribed-protocols SRPOLICY
session-state UP
remote-session-state UP
last-state-transition "2024-05-15T19:15:58.117Z (49 seconds ago)"
failure-transitions 0
local-diagnostic-code NO_DIAGNOSTIC
remote-diagnostic-code NO_DIAGNOSTIC
remote-minimum-receive-interval 1000000
remote-control-plane-independent false
active-transmit-interval 1000000
active-receive-interval 1000000
remote-multiplier 3
te-policy-name C_to_Fipv4
te-policy-segment-list-index 1
te-policy-protocol-origin LOCAL
te-policy-segment-list-lsp-index 216
sr-policy-endpoint 1.1.1.6
async {
last-packet-transmitted "2024-05-15T19:16:43.140Z (4 seconds ago)"
last-packet-received "2024-05-15T19:16:43.146Z (4 seconds ago)"
transmitted-packets 61
received-packets 61
up-transitions 1
}
}
peer 16386 {
oper-state up
local-address 1.1.1.3
remote-address 127.0.64.2
remote-discriminator 524289
subscribed-protocols SRPOLICY
session-state UP
remote-session-state UP
last-state-transition "2024-05-15T19:15:58.119Z (49 seconds ago)"
failure-transitions 0
local-diagnostic-code NO_DIAGNOSTIC
remote-diagnostic-code NO_DIAGNOSTIC
remote-minimum-receive-interval 1000000
remote-control-plane-independent false
active-transmit-interval 1000000
active-receive-interval 1000000
remote-multiplier 3
te-policy-name C_to_Fipv4
te-policy-segment-list-index 2
te-policy-protocol-origin LOCAL
te-policy-segment-list-lsp-index 217
sr-policy-endpoint 1.1.1.6
async {
last-packet-transmitted "2024-05-15T19:16:43.651Z (4 seconds ago)"
last-packet-received "2024-05-15T19:16:43.695Z (4 seconds ago)"
transmitted-packets 62
received-packets 62
up-transitions 1
}
}
}
}
Configuring an S-BFD reflector
To enable and configure an S-BFD reflector, use the network-instance bfd seamless-bfd reflector command. You must allocate the discriminator value from the S-BFD reflector pool that ranges from 524288 to 526335.
Only a single reflector discriminator is supported for each network instance.
Configuring an S-BFD reflector
The following example configures an S-BFD reflector.
--{ + candidate shared default }--[ ]--
# info network-instance default bfd seamless-bfd reflector abc
network-instance default {
bfd {
seamless-bfd {
reflector abc {
local-discriminator 524289
admin-state enable
description test
}
}
}
}Viewing the S-BFD state
Use the info from state command to verify the S-BFD state.
Viewing the S-BFD state at network instance level
The following example displays the S-BFD status at the network instance level.
--{ + running }--[ ]--
# info from state network-instance base bfd seamless-bfd
network-instance base {
bfd {
seamless-bfd {
peer 1.1.1.6 {
discriminator 524289
}
reflector 1.1.1.3 {
local-discriminator 524289
admin-state enable
}
}
}
}
Viewing the S-BFD state at the policy level
The following example displays the S-BFD status at the policy level.
--{ + running }--[ ]--
# info from state network-instance base maintenance-policies policy mp
network-instance base {
maintenance-policies {
policy mp {
revert-timer disable
seamless-bfd {
detection-multiplier 3
desired-minimum-transmit-interval 1000000
hold-down-timer 4
wait-for-up-timer 3
mode linear
threshold 1
}
}
}
}
Viewing the S-BFD state at the system level
The following example displays the S-BFD status at the system level.
--{ + running }--[ ]--
# info from state bfd
bfd {
total-bfd-sessions 2
total-unmatched-bfd-packets 1
network-instance base {
peer 16385 {
oper-state up
local-address 1.1.1.3
remote-address 127.0.64.1
remote-discriminator 524289
subscribed-protocols SRPOLICY
session-state UP
remote-session-state UP
last-state-transition "2024-05-15T19:15:58.117Z (49 seconds ago)"
failure-transitions 0
local-diagnostic-code NO_DIAGNOSTIC
remote-diagnostic-code NO_DIAGNOSTIC
remote-minimum-receive-interval 1000000
remote-control-plane-independent false
active-transmit-interval 1000000
active-receive-interval 1000000
remote-multiplier 3
te-policy-name C_to_Fipv4
te-policy-segment-list-index 1
te-policy-protocol-origin LOCAL
te-policy-segment-list-lsp-index 216
sr-policy-endpoint 1.1.1.6
async {
last-packet-transmitted "2024-05-15T19:16:43.140Z (4 seconds ago)"
last-packet-received "2024-05-15T19:16:43.146Z (4 seconds ago)"
transmitted-packets 61
received-packets 61
up-transitions 1
}
}
peer 16386 {
oper-state up
local-address 1.1.1.3
remote-address 127.0.64.2
remote-discriminator 524289
subscribed-protocols SRPOLICY
session-state UP
remote-session-state UP
last-state-transition "2024-05-15T19:15:58.119Z (49 seconds ago)"
failure-transitions 0
local-diagnostic-code NO_DIAGNOSTIC
remote-diagnostic-code NO_DIAGNOSTIC
remote-minimum-receive-interval 1000000
remote-control-plane-independent false
active-transmit-interval 1000000
active-receive-interval 1000000
remote-multiplier 3
te-policy-name C_to_Fipv4
te-policy-segment-list-index 2
te-policy-protocol-origin LOCAL
te-policy-segment-list-lsp-index 217
sr-policy-endpoint 1.1.1.6
async {
last-packet-transmitted "2024-05-15T19:16:43.651Z (4 seconds ago)"
last-packet-received "2024-05-15T19:16:43.695Z (4 seconds ago)"
transmitted-packets 62
received-packets 62
up-transitions 1
}
}
}
}