3.14. Diagnostics Command Reference
3.14.1. Command Hierarchies
3.14.1.1. OAM Commands
3.14.1.1.1. Base Operational Commands
3.14.1.1.2. ATM Diagnostics
3.14.1.1.3. Find Egress Tool
3.14.1.1.4. IGMP Snooping
3.14.1.1.5. LDP Diagnostics
3.14.1.1.6. LSP Diagnostics
To improve readability, the following lsp-ping and lsp-trace parameters that are common to both commands have been omitted from the tree but are listed here instead.
Parameter options that are common to all lsp-ping cases include:
[detail] [fc fc-name [profile {in | out}]] [interval interval] [send-count send-count] [size octets] [src-ip-address ip-address] [timeout timeout] [ttl label-ttl]
Parameter options that are common to all lsp-trace cases include:
[detail] [downstream-map-tlv downstream-map-tlv] [fc fc-name [profile {in | out}]] [interval interval] [max-fail no-response-count] [max-ttl max-label-ttl] [min-ttl min-label-ttl] [probe-count probes-per-hop] [size octets] [src-ip-address ip-address] [timeout timeout]
3.14.1.1.7. SDP Diagnostics
3.14.1.1.8. Common Service Diagnostics
3.14.1.1.9. VLL Diagnostics
3.14.1.1.10. Ethernet in the First Mile (EFM) Commands
3.14.1.1.11. ETH-CFM OAM Commands
3.14.1.1.12. BIER OAM Commands
3.14.1.2. SAA Commands
To improve readability, the following lsp-ping and lsp-trace parameters that are common to both commands have been omitted from the tree but are listed here instead.
Parameter options that are common to all lsp-ping cases include:
[detail] [fc fc-name [profile {in | out}]] [interval interval] [send-count send-count] [size octets] [src-ip-address ip-address] [timeout timeout] [ttl label-ttl]
Parameter options that are common to all lsp-trace cases include:
[detail] [downstream-map-tlv downstream-map-tlv] [fc fc-name [profile {in | out}]] [interval interval] [max-fail no-response-count] [max-ttl max-label-ttl] [min-ttl min-label-ttl] [probe-count probes-per-hop] [size octets] [src-ip-address ip-address] [timeout timeout]
3.14.1.3. OAM Performance Monitoring, Bin Group, Session, and Streaming Commands
3.14.1.3.1. Bin Group and Base Session Commands
3.14.1.3.2. Session Ethernet Commands
3.14.1.3.3. Session IP Commands
3.14.1.3.4. Session MPLS Commands
3.14.1.3.5. Streaming Commands
3.14.1.3.6. Performance Monitoring Reflector Commands
3.14.1.3.6.1. TWAMP Server
3.14.1.3.6.2. TWAMP Light Reflector (Base Router)
3.14.1.3.7. Seamless BFD Commands
3.14.1.4. Show Commands
3.14.1.7. Debug Commands
3.14.2. Command Descriptions
3.14.2.1. Generic Commands
description
Syntax
Context
Description
This command creates a text description stored in the configuration file for a configuration context. The description command associates a text string with a configuration context to help identify the content in the configuration file.
The no form of this command removes the string from the configuration.
Parameters
shutdown
Syntax
Context
Description
This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.
The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.
Entities are created in the administratively down (shutdown) state. When a no shutdown command is entered, the entity becomes administratively up and then tries to enter the operationally up state.
The no form of this command administratively enables the entity.
3.14.2.2. Base Operational Commands
dns
Syntax
Context
Description
This command performs DNS name resolution. If ipv4-a-record is specified, DNS target addresses are queried for A-records only. If ipv6-aaaa-record is specified, AAAA-records are queried first, and if a successful reply is not received, the DNS server is queried for A-records (applies to the 7750 SR and 7950 XRS).
Parameters
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | 0 to FFFF]H | |
d: | [0 to 255]D | |
ping
Syntax
Context
Description
This command verifies the reachability of a remote host.
Ping for L2-Aware NAT can be initiated from the gateway IPv4 address in the inside routing context or from any IPv4 address in the outside routing context. If the gateway IPv4 address is used as the source address, it must be explicitly configured in the L2-Aware ping command.
To test the relevant NAT policy, any source address can be used for the ping. If the given source address refers to a policy that does not reside on the given router, the message “MINOR: OAM #2160 router ID is not an outside router for this subscriber” is displayed to the operator. The source address does not have to belong to the system.
If the outside routing context is not specified, by default, the Base router is selected. If the specified or the default Base router instance is not the outside routing context for the subscriber, the L2-Aware ping command execution fails and the message “MINOR: OAM #2160 router ID is not an outside router for this subscriber” is displayed to the operator.
The NAT application shares query IDs between L2-Aware pings and ICMP or GRE traffic that has undergone NAT and is destined to a DMZ host. If there is query ID space exhaustion, ICMP/GRE flows destined to DMZs hosts are deleted so their query IDs can be reused for the requested L2-Aware pings.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x[-interface] | |
x:x:x:x:x:x:d.d.d.d[-interface] | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
interface: | up to 32 characters, mandatory for link local addresses | |
ipv4-address: | a.b.c.d (host bits must be 0) | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255] | |
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
traceroute
Syntax
Context
Description
The TCP/IP traceroute utility determines the route to a destination address. DNS lookups of the responding hosts are enabled by default.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255] | |
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
Output
p2mp-lsp-ping
Syntax
Context
Description
This command performs an in-band connectivity test for an RSVP P2MP LSP. The echo request message is sent on the active P2MP instance and is replicated in the data path over all branches of the P2MP LSP instance. By default, all egress LER nodes that are leaves of the P2MP LSP instance replies to the echo request message.
LDP P2MP generic-identifier along with source IP address of the head-end node can be used to uniquely identify LDP P2MP LSP in a 7750 SR or 7950 XRS network. LDP p2mp-identifier is a mandatory parameter to test LSP ping. LDP P2MP identifier specified to configure a tunnel-interface on head-end node must be used as p2mp-identifier to test an LSP.
To reduce the scope of the echo reply messages, explicitly enter a list of addresses for the egress LER nodes that are required to reply. A maximum of five addresses can be specified in a single run of the p2mp-lsp-ping command. An LER node can parse the list of egress LER addresses and, if its address is included, it replies with an echo reply message.
The output of the command without the detail option provides a high-level summary of received error codes and success codes. The output of the command with the detail option shows a line for each replying node, as in the output of the LSP ping for a P2P LSP.
The display is delayed until all responses are received or the timer configured in the timeout parameter expires. No other CLI commands can be entered while waiting for the display. Entering A ^C aborts the ping operation. Note that p2mp-lsp-ping is not supported in a VPLS/B-VPLS PMSI context.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
Refer to the “OAM” subsection of the LDP chapter in the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information.
source | ipv4-address | a.b.c.d| |
ipv6-address | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x - [0 to FFFF]H | ||
d - [0t o 255]D | ||
group | mcast-address | |
mcast-v6-address | ||
router | router-name | Base | management |
Default - Base | ||
service-id | [1 to 2147483647] | |
service-name | up to 64 characters | |
sender-addr | ipv4-address | a.b.c.d |
leaf-addr | ipv4-address | a.b.c.d |
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified fc and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, the fc and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in an egress network queue. The egress network queue is selected according to the fc and profile parameter values determined by the classification of the echo request packet that is being replied to at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 21 summarizes this behavior.
Table 21: p2mp-lsp-ping Request Packet and Behavior
Request Packet | Behavior |
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
p2mp-lsp-trace
Syntax
Context
Description
This command discovers and displays the hop-by-hop path for a source-to-leaf (S2L) sub-LSP of an RSVP P2MP LSP.
The LSP trace capability allows the user to trace the path of a single S2L path of a P2MP LSP. Its operation is like p2mp-lsp-ping, but the sender of the echo reply request message includes the downstream mapping TLV to request the downstream branch information from a branch LSR or bud LSR. The branch LSR or bud LSR also includes the downstream mapping TLV to report the information about the downstream branches of the P2MP LSP. An egress LER does not include this TLV in the echo response message.
The parameter probe-count operates in the same way as in LSP Trace on a P2P LSP. It represents the maximum number of probes sent per TTL value before stops waiting for echo reply messages. If a response is received from the traced node before reaching maximum number of probes, then no more probes are sent for the same TTL. The sender of the echo request then increments the TTL and uses the information it received in the downstream mapping TLV to start sending probes to the node downstream of the last node which replied. This continues until the egress LER for the traced S2L path replies.
Like p2mp-lsp-ping, an LSP trace probe reports on all egress LER nodes that eventually receive the echo request message, but only the traced egress LER node replies to the last probe.
Any branch LSR node or bud LSR node in the P2MP LSP tree may receive a copy of the echo request message with the TTL in the outer label expiring at this node. However, only a branch LSR or bud LSR that has a downstream branch over which the traced egress LER is reachable responds.
When a branch LSR or bud LSR responds, it sets the global return code in the echo response message to RC=14 - “See DDMAP TLV for Return Code and Return Sub-Code” and the return code in the DDMAP TLV corresponding to the outgoing interface of the branch used by the traced S2L path to RC=8 - “Label switched at stack-depth <RSC>”. Note that p2mp-lsp-trace is not supported in a VPLS/B-VPLS PMSI context.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, the fc and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in an egress network queue. The egress network queue is selected according to the fc and profile parameter values determined by the classification of the echo request packet that is being replied to at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 22 summarizes this behavior.
Table 22: p2mp-lsp-trace Request Packet and Behavior
Request Packet | Behavior |
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of an echo reply message corresponding to the outstanding message request.
Output
The following is an example of p2mp-lsp-trace information.
3.14.2.3. ATM Diagnostics
The commands described in this section apply only to the 7750 SR.
atm-ping
Syntax
Context
Description
This command tests ATM path connectivity and round trip time on an ATM VCC.
Parameters
port-id | slot/mda/port | ||
bundle-id | bundle-<type>-slot/mda.<bundle-num> | ||
bundle | keyword | ||
type | ima | ||
bundle-num | 1 to 336 | ||
bpgrp-id | bpgrp-<type>-<bpgrp-num> | ||
bpgrp | keyword | ||
type | ima | ||
bpgrp-num | 1 to 2000 | ||
aps-id | aps-group-id | ||
aps | keyword | ||
group-id | 1 to 128 | ||
vpi | 0 to 4095 (NNI) | ||
0 to 255 (UNI) | |||
vci | 1, 2, 5 to 65535 | ||
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
3.14.2.4. Find Egress Tool
oam
Syntax
Context
Description
This command enables OAM debugging.
find-egress
Syntax
Context
Description
This command executes the OAM find-egress test injecting the specified packet ID into the specified ingress port.
Parameters
build-packet
Syntax
Context
Description
This command enables the context to configure packet header templates or the OAM test packet to be used when running an oam find-egress test.
packet
Syntax
Context
Description
This command configures a packet to be launched by the OAM find-egress tool.
The no form of this command removes the packet number value.
Parameters
field-override
Syntax
Context
Description
This command enables the context to configure an override value for a field within a header within a packet to be launched by the OAM find-egress tool.
header
Syntax
Context
Description
This command enables the context to configure header parameters.
The no form of this command deletes the associated header.
Parameters
control-word
Syntax
Context
Description
This command creates a control-word header for inclusion in a build packet instance.
dot1q
Syntax
Context
Description
This command creates a Dot1Q header and enables the context to define the associated parameters.
prio-code-point
Syntax
Context
Description
This command defines the priority code point to be used in the test Dot1Q header.
The no form of this command removes the priority code point value.
Default
prio-code-point 0 (BE)
Parameters
prio-code-point
Syntax
Context
Description
This command configures a Priority Code Point (PCP) for an IEEE 802.1Q packet header to be launched by the OAM find-egress tool.
The no form of this command removes the priority code point value.
Default
no override
Parameters
tag-protocol-id
Syntax
Context
Description
This command defines the Dot1Q tag protocol ID to be used in the test Dot1Q header.
The no form of this command removes the tag protocol ID value.
Default
tag-protocol-id 0x8100 (33024)
Parameters
vlan-id
Syntax
Context
Description
This command defines the Dot1Q VLAN ID to be used in the test Dot1Q header.
The no form of this command removes the VLAN ID value.
Parameters
ethernet
Syntax
Context
Description
This command causes the associated header to be defined as an Ethernet header template and enables the context to define the Ethernet parameters.
The no form of this command removes the Ethernet header association.
dst-mac-address
Syntax
Context
Description
This command defines the destination MAC address for the Ethernet header.
The no form of this command deletes the configured MAC address.
Default
dst-mac-address 00:00:00:00:00:00
Parameters
src-mac-address
Syntax
Context
Description
This command defines the source MAC address for the Ethernet header.
The no form of this command deletes the configured MAC address.
Default
no override
Parameters
gre
Syntax
Context
Description
This command creates a GRE header for inclusion in test OAM build packet instance.
gtp-user
Syntax
Context
Description
This command causes the associated header to be defined as a GTP user header template and enables the context to define the GTP parameters.
tunnel-endpoint-id
Syntax
Context
Description
This command defines the GTP tunnel endpoint ID for the GTP user header.
The no form of this command removes the tunnel endpoint ID value.
Default
tunnel-endpoint-id 0
Parameters
tunnel-endpoint-id
Syntax
Context
Description
This command debugs the GTP tunnel endpoint ID for the GTP user header.
The no form of this command removes the tunnel endpoint ID value.
Default
no override
Parameters
ipsec-auth
Syntax
Context
Description
This command causes the associated header to be defined as an IPsec header template and enters the context to define the IPsec parameters. This same context can be used for IPv4 and IPv6 packets.
security-param-index
Syntax
Context
Description
This command defines the security index to be used in the IPsec header. This same context can be used for IPv4 and IPv6 packets.
The no form of this command removes the security parameter index value.
Default
security-param-index 1
Parameters
ipv4
Syntax
Context
Description
This command causes the associated header to be defined as an IPv4 header template and enables the context to define the IPv4 parameters.
dscp
Syntax
Context
Description
This command defines the DSCP value to be used in the IPv4 header.
The no form of this command reverts to the default.
Default
dscp be
Parameters
dst-ipv4-address
Syntax
Context
Description
This command defines the destination IPv4 address to be used in the IPv4 header.
The no form of this command removes the destination IPv4 address value.
Default
dst-ipv4-address 0.0.0.0
Parameters
more-fragments
Syntax
Context
Description
This command defines if the MF flag should be set in the associated IPv4 header.
The no form of this command reverts to the default value.
Default
more-fragments 0
Parameters
src-ipv4-address
Syntax
Context
Description
This command defines the source IPv4 address to be used in the IPv4 header.
The no form of this command removes the source IPv4 address.
Default
src-ipv4-address 0.0.0.0
Parameters
ipv6
Syntax
Context
Description
This command causes the associated header to be defined as an IPv6 header template and enters the context to define the IPv6 parameters.
dscp
Syntax
Context
Description
This command defines the DSCP value to be used in the IPv6 header.
The no form of this command removes the DSCP name.
Parameters
dst-ipv6-address
Syntax
Context
Description
This command defines the destination IPv6 address to be used in the IPv6 header.
The no form of this command removes the IPv6 address.
Parameters
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | 0 to FFFF]H | |
d: | [0 to 255]D | |
src-ipv6-address
Syntax
Context
Description
This command defines the source IPv6 address to be used in the IPv6 header.
The no form of the removes the source IPv6 address.
Parameters
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | 0 to FFFF]H | |
d: | [0 to 255]D | |
ipv6-fragment
Syntax
Context
Description
This command causes the associated header to be defined as an IPv6 fragment header template.
l2tp
Syntax
Context
Description
This command causes the associated header to be defined as an L2TP header template and enables the context to define the L2TP parameters.
session-id
Syntax
Context
Description
This command defines the session ID to be used in the L2TP header.
The no form of this command removes the session ID value.
Default
session-id 0
Parameters
tunnel-id
Syntax
Context
Description
This command defines the tunnel ID to be used in the L2TP header.
The no form of this command removes the tunnel ID value.
Default
tunnel-id 0
Parameters
mpls
Syntax
Context
Description
This command causes the associated header to be defined as an MPLS label header template and enables the context to define the MPLS parameters.
label
Syntax
Context
Description
This command defines the MPLS value to be used in the MPLS header.
The no form of this command removes the label value.
Default
label 0
Parameters
traffic-class
Syntax
Context
Description
This command defines the traffic class value to be used in the MPLS header.
The no form of this command removes the traffic class value.
Default
traffic-class 0 (BE)
Parameters
pbb
Syntax
Context
Description
This command configures a test Provider Backbone Bridge (PBB) packet header to be launched by the OAM find-egress tool.
i-sid
Syntax
Context
Description
This command defines the iSID value to be used in the test PBB header.
The no form of this command reverts to the default value.
Default
i-sid 0
Parameters
tag-protocol-id
Syntax
Context
Description
This command defines the PBB Tag Protocol Identifier (TPID) to be used in the test PBB header.
The no form of this command reverts to the default.
Default
tag-protocol-id 0x88E7 (35047)
Parameters
tag-protocol-id
Syntax
Context
Description
This command defines the PBB TPID to be used in the PBB header.
The no form of this command reverts to the default.
Default
tag-protocol-id 0
Parameters
tcp
Syntax
Context
Description
This command creates a TCP header and enables the context to define the associated parameters.
dst-tcp-port
Syntax
Context
Description
This command defines the destination TCP port to be used in the test TCP header.
The no form of this command reverts to the default.
Default
dst-tcp-port 0
Parameters
dst-tcp-port
Syntax
Context
Description
This command defines the destination TCP port to be used in the TCP header.
The no form of this command reverts to the default.
Default
no override
Parameters
src-tcp-port
Syntax
Context
Description
This command defines the source TCP port to be used in the test TCP header.
The no form of this command reverts to the default.
Default
src-tcp-port 0
Parameters
src-tcp-port
Syntax
Context
Description
This command defines the source TCP port to be used in the TCP header.
The no form of this command reverts to the default.
Default
no override
Parameters
udp
Syntax
Context
Description
This command creates a UDP header and enables the context to define the associated parameters.
dst-udp-port
Syntax
Context
Description
This command defines the destination TCP port to be used in the test TCP header.
The no form of this command reverts to the default.
Default
dst-udp-port 0
Parameters
dst-udp-port
Syntax
Context
Description
This command defines the destination TCP port to be used in the TCP header.
The no form of this command reverts to the default.
Default
no override
Parameters
src-udp-port
Syntax
Context
Description
This command defines the source UDP port to be used in the test UDP header.
The no form of this command reverts to the default.
Default
src-udp-port 0
Parameters
src-udp-port
Syntax
Context
Description
This command defines the source UDP port to be used in the UDP header.
The no form of this command reverts to the default.
Default
no override
Parameters
header-sequence
Syntax
Context
Description
This command configures the sequence of headers for a packet to be launched by the OAM find-egress tool.
Parameters
3.14.2.5. IGMP Snooping
mfib-ping
Syntax
Context
Description
This command determines the list of SAPs which egress a certain IP multicast stream (identified by source unicast and destination multicast IP addresses) within a VPLS service. An MFIB ping packet is always sent via the data plane.
An MFIB ping is forwarded across the VPLS following the MFIB. If an entry for the specified source unicast and destination multicast IP addresses exist in the MFIB for that VPLS, then the packet is forwarded along those paths, provided they are active. A response is generated only when there is an egress SAP binding for the specified IP multicast stream.
An MFIB ping reply can be sent using the data plane or the control plane. The return-control option configures the reply to be sent using the control plane. If return-control is not specified, the reply is sent using the data plane.
Special Cases
Parameters
If the octet size specified is less than the minimum packet, the minimum sized packet necessary to send the request is used.
The message interval value must be expired before the next message request is sent.
Upon the expiration of the message time out, the requesting router assumes that the message response is not received. A request timeout message is displayed by the CLI for each message request sent that expires. Any response received after the request times out is silently discarded.
If the interval is set to 1 second where the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
Output
The following output displays multicast FIB connectivity test information
3.14.2.6. LDP Diagnostics
ldp-treetrace
Syntax
Context
Description
This command allows the user to perform a single run of the LDP ECMP OAM tree trace to discover all ECMP paths of an LDP FEC.
Parameters
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, The FC and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the FC and profile parameter values determined by the classification of the echo request packet, which is being replied to, at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 23 summarizes this behavior.
Table 23: ldp-treetrace Request Packet and Behavior
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
Output
The following is an example of treetrace prefix information.
test-oam
Syntax
Context
Description
This command enables the context to configure Operations, Administration, and Maintenance test parameters.
ldp-treetrace
Syntax
Context
Description
This command creates the context to configure the LDP ECMP OAM tree trace which consists of an LDP ECMP path discovery and an LDP ECMP path probing features.
The no form of this command deletes the configuration for the LDP ECMP OAM tree discovery and path probing under this context.
Output
The following is an example LDP treetrace information.
fc
Syntax
Context
Description
This command indicates the forwarding class and profile of the MPLS echo request packet.
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, The FC and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the FC and profile parameter values determined by the classification of the echo request packet, which is being replied to, at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 24 summarizes this behavior.
Table 24: fc Request Packet and Behavior
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
Default
no fc
Parameters
path-discovery
Syntax
Context
Description
This command creates the context to configure the LDP ECMP OAM path discovery.
The ingress LER builds the ECMP tree for a given FEC (egress LER) by sending LSP Trace messages and including the LDP IPv4 Prefix FEC TLV as well as the downstream mapping TLV. It inserts an IP address range drawn from the 127/8 space. When received by the downstream LSR, it uses this range to determine which ECMP path is exercised by any IP address or a sub-range of addresses within that range based on its internal hash routine. When the MPLS Echo reply is received by the ingress LER, it records this information and proceeds with the next echo request message targeted for a node downstream of the first LSR node along one of the ECMP paths. The sub-range of IP addresses indicated in the initial reply is used since the objective is to have the LSR downstream of the ingress LER pass this message to its downstream node along the first ECMP path.
The user configures the frequency of running the tree discovery using the command config>test-oam>ldp-treetrace>path-discovery>interval.
The ingress LER gets the list of FECs from the LDP FEC database. New FECs are added to the discovery list at the next tree discovery and not when they are learned and added into the FEC database. The maximum number of FECs to be discovered with the tree building feature is limited to 500. The user can configure FECs to include or exclude using a policy profile by applying the command config>test-oam>ldp-treetrace>path-discovery>policy-statement.
interval
Syntax
Context
Description
This command configures the frequency of the LDP ECMP OAM path discovery. Every interval, the node sends LSP trace messages to attempt to discover the entire ECMP path tree for a given destination FEC.
The no form of this command removes the value from the configuration.
Default
no interval
Parameters
max-path
Syntax
Context
Description
This command configures the maximum number of ECMP paths the path discovery attempts to discover for each run every interval minute.
The no form of this command resets the time out to its default value.
Default
no max-path
Parameters
max-ttl
Syntax
Context
Description
This command configures the maximum number of hops the path discovery traces in the path of each FEC to be discovered.
The no form of this command resets the time out to its default value.
Default
no max-ttl
Parameters
policy-statement
Syntax
Context
Description
This command configures the FEC policy to determine which routes are imported from the LDP FEC database to discover its paths and probing them.
If no policy is specified, the ingress LER imports the full list of FECs from the LDP FEC database. New FECs are added to the discovery list at the next path discovery and not when they are learned and added into the FEC database. The maximum number of FECs to be discovered with path discovery is limited to 500.
The user can configure FECs to include or exclude.
Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified.
The no form of this command removes the policy from the configuration.
Default
no policy-statement
Parameters
retry-count
Syntax
Context
Description
In the path discovery phase of the LDP tree trace feature, this command configures the number of retransmissions of an LSP trace message to discover the path of an LDP FEC when no response is received within the timeout parameter.
In the path-probing phase of the LDP tree trace, this command configures the number of retransmissions of an LSP ping message to probe the path of an LDP FEC when no response is received within the timeout parameter.
The no form of this command resets the retry count to its default value.
Default
no retry-count
Parameters
timeout
Syntax
Context
Description
This command configures the time the node waits for the response to an LSP Trace message discovering the path of an LDP FEC before it declares failure. After consecutive failures equal to the retry-count parameter, the node gives up.
The no form of this command resets the timeout to its default value.
Default
timeout 30
Parameters
path-probing
Syntax
Context
Description
This command creates the context to configure the LDP tree trace path probing phase.
The periodic path exercising runs in the background to test the LDP ECMP paths discovered by the path discovery capability. The probe used is an LSP Ping message with an IP address drawn from the sub-range of 127/8 addresses indicated by the output of the tree discovery for this FEC.
The user configures the frequency of running the path probes using the config>test-oam>ldp-treetrace>path-probing>interval command. If an I/F is down on the ingress LER performing the LDP tree trace, then LSP Ping probes that normally go out this interface are not sent but the ingress LER node does not raise alarms.
The LSP Ping routine updates the content of the MPLS echo request message, specifically the IP address, as soon as the LDP ECMP path discovery phase has output the results of a new computation for the path in question.
interval
Syntax
Context
Description
This command configures the frequency of the LSP Ping messages used in the path probing phase to probe the paths of all LDP FECs discovered by the LDP tree trace path discovery.
The no form of this command resets the interval to its default value.
Default
no interval
Parameters
timeout
Syntax
Context
Description
This command configures the time the node waits for the response to an LSP Ping message probing the path of an LDP FEC before it declares failure. After consecutive failures equal to the retry-count parameter, the node gives up.
The no form of this command resets the time out to its default value.
Default
timeout 1
Parameters
mpls-echo-request-downstream-map
Syntax
Context
Description
This command specifies which format of the downstream mapping TLV to use in all LSP trace packets and LDP tree trace packets originated on this node. The Downstream Mapping (DSMAP) TLV is the original format in RFC 4379 (obsoleted by RFC 8029) and is the default value. The new Downstream Detailed Mapping (DDMAP) TLV is the new enhanced format specified in RFC 6424 and RFC 8029.
This command applies to LSP trace of an RSVP P2P LSP, a MPLS-TP LSP, or LDP unicast FEC, and to LDP tree trace of a unicast LDP FEC. It does not apply to LSP trace of an RSVP P2MP LSP which always uses the DDMAP TLV.
The global DSMAP/DDMAP setting impacts the behavior of both OAM LSP trace packets and SAA test packets of type lsp-trace and is used by the sender node when one of the following events occurs:
- An SAA test of type lsp-trace is created (not modified) and no value is specified for the per-test downstream-map-tlv {dsmap | ddmap | none} option. In this case, the SAA test downstream-map-tlv value defaults to the global mpls-echo-request-downstream-map value.
- An OAM test of type lsp-trace test is executed and no value is specified for the per-test downstream-map-tlv {dsmap | ddmap | none} option. In this case, the OAM test downstream-map-tlv value defaults to the global mpls-echo-request-downstream-map value.
A consequence of the rules above is that a change to the value of mpls-echo-request-downstream-map option does not affect the value inserted in the downstream mapping TLV of existing tests.
Following are the details of the processing of the new DDMAP TLV:
- When either the DSMAP TLV or the DDMAP TLV is received in an echo request message, the responder node includes the same type of TLV in the echo reply message with the proper downstream interface information and label stack information.
- If an echo request message without a Downstream Mapping TLV (DSMAP or DDMAP) expires at a node which is not the egress for the target FEC stack, the responder node always includes the DSMAP TLV in the echo reply message. This can occur in the following cases:
- The user issues a LSP trace from a sender node with a min-ttl value higher than 1 and a max-ttl value lower than the number of hops to reach the egress of the target FEC stack. This is the sender node behavior when the global configuration or the per-test setting of the DSMAP/DDMAP is set to DSMAP.
- The user issues a LSP ping from a sender node with a ttl value lower than the number of hops to reach the egress of the target FEC stack. This is the sender node behavior when the global configuration of the DSMAP/DDMAP is set to DSMAP.
- The behavior in (a) is changed when the global configuration or the per-test setting of the Downstream Mapping TLV is set to DDMAP. The sender node includes in this case the DDMAP TLV with the Downstream IP address field set to the all-routers multicast address as per Section 3.4 of RFC 8029. The responder node then bypasses the interface and label stack validation and replies with a DDMAP TLV with the correct downstream information for the target FEC stack.
- A sender node never includes the DSMAP or DDMAP TLV in an lsp-ping message.
In addition to performing the same features as the DSMAP TLV, the new DDMAP TLV addresses the following scenarios:
- Full validation of an LDP FEC stitched to a BGP IPv4 label route. In this case, the LSP trace message is inserted from the LDP LSP segment or from the stitching point.
- Full validation of a BGP IPv4 label route stitched to an LDP FEC. This includes the case of explicit configuration of the LDP-BGP stitching in which the BGP label route is active in Route Table Manager (RTM) and the case of a BGP IPv4 label route resolved to the LDP FEC due to the IGP route of the same prefix active in RTM. In this case, the LSP trace message is inserted from the BGP LSP segment or from the stitching point.
- Full validation of an LDP FEC which is stitched to a BGP LSP and stitched back into an LDP FEC. In this case, the LSP trace message is inserted from the LDP segments or the or from the stitching points.
- Full validation of an LDP FEC tunneled over an RSVP LSP using LSP trace.
To properly check a target FEC which is stitched to another FEC (stitching FEC) of the same or a different type, or which is tunneled over another FEC (tunneling FEC), it is necessary for the responding nodes to provide details about the FEC manipulation back to the sender node. This is achieved via the use of the new FEC stack change sub-TLV in the Downstream Detailed Mapping TLV (DDMAP) defined in RFC 6424.
When the user configures the use of the DDMAP TLV on a trace for an LSP that does not undergo stitching or tunneling operation in the network, the procedures at the sender and responder nodes are the same as in the case of the DSMAP TLV.
This feature however introduces changes to the target FEC stack validation procedures at the sender and responder nodes in the case of LSP stitching and LSP hierarchy. These changes pertain to the processing of the new FEC stack change sub-TLV in the new DDMAP TLV and the new return code of value 15 Label switched with FEC change.
The no form of this command reverts to the default behavior of using the DSMAP TLV in a LSP trace packet and LDP tree trace packet.
Default
mpls-echo-request-downstream-map dsmap
Parameters
Output
The following output is an example of mpls-echo-request-downstream-map information.
mpls-time-stamp-format
Syntax
Context
Description
This command configures the format of the timestamp used by for lsp-ping, lsp-trace, p2mp-lsp-ping and p2mp-lsp-trace, vccv-ping, vccv-trace, and lsp-trace.
If rfc4379 is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Changing this system-wide setting does not affect tests that are currently in progress, but SAAs starts to use the new timestamp when they are restarted. When an SR OS receives an echo request, it replies with the locally configured timestamp format, and does not try to match the timestamp format of the incoming echo request message.
Default
mpls-time-stamp-format unix
Parameters
3.14.2.7. LSP Diagnostics
3.14.2.8. SDP Diagnostics
sdp-mtu
Syntax
Context
Description
Performs MTU Path tests on an SDP to determine the largest path-mtu supported on an SDP. The size-inc parameter can be used to easily determine the path-mtu of a given SDP-ID. The forwarding class is assumed to be Best-Effort Out-of-Profile. The message reply is returned with IP/GRE encapsulation from the far-end router. OAM request messages sent within an IP/GRE SDP must have the ‘DF’ IP header bit set to 1 to prevent message fragmentation.
To terminate an sdp-mtu in progress, use the CLI break sequence <Ctrl-C>.
Special Cases
With each OAM Echo Request sent using the size-inc parameter, a response line is displayed as message output. The path MTU test displays incrementing packet sizes, the number sent at each size until a reply is received and the response message.
As the request message is sent, its size value is displayed followed by a period for each request sent of that size. Up to three requests are sent unless a valid response is received for one of the requests at that size. Once a response is received, the next size message is sent.
The response message indicates the result of the message request.
After the last reply has been received or response time out, the maximum size message replied to indicates the largest size OAM Request message that received a valid reply.
Parameters
If the incremented size exceeds the end-octets value, no more messages are sent.
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
Output
sdp-ping
Syntax
Context
Description
This command tests SDPs for uni-directional or round trip connectivity and performs SDP MTU Path tests.
The sdp-ping command accepts an originating SDP-ID and an optional responding SDP-ID. The size, number of requests sent, message time-out and message send interval can be specified. All sdp-ping requests and replies are sent with PLP OAM-Label encapsulation, as a service-id is not specified.
For round trip connectivity testing, the resp-sdp keyword must be specified. If resp-sdp is not specified, a uni-directional SDP test is performed.
To terminate an sdp-ping in progress, use the CLI break sequence <Ctrl-C>.
An sdp-ping response message indicates the result of the sdp-ping message request. When multiple response messages apply to a single SDP echo request/reply sequence, the response message with the highest precedence is displayed. Table 25 shows the response messages sorted by precedence.
Table 25: sdp-ping Response Messages
Result of Request | Displayed Response Message | Precedence |
Request time out without reply | Request Timeout | 1 |
Request not sent due to non-existent orig-sdp-id | Orig-SDP Non-Existent | 2 |
Request not sent due to administratively down orig-sdp-id | Orig-SDP Admin-Down | 3 |
Request not sent due to operationally down orig-sdp-id | Orig-SDP Oper-Down | 4 |
Request terminated by user before reply or time out | Request Terminated | 5 |
Reply received, invalid origination-id | Far End: Originator-ID Invalid | 6 |
Reply received, invalid responder-id | Far End: Responder-ID Error | 7 |
Reply received, non-existent resp-sdp-id | Far End: Resp-SDP Non-Existent | 8 |
Reply received, invalid resp-sdp-id | Far End: Resp-SDP Invalid | 9 |
Reply received, resp-sdp-id down (admin or oper) | Far-end: Resp-SDP Down | 10 |
Reply received, No Error | Success | 11 |
Special Cases
Upon request time out, message response, request termination, or request error the following local and remote information is displayed. Local and remote information is dependent upon the SDP ID existence and reception of reply.
Table 26: sdp-ping Test Results
Field | Description | Values |
Request Result | The result of the sdp-ping request message. | Sent - Request Timeout |
Sent - Request Terminated | ||
Sent - Reply Received | ||
Not Sent - Non-Existent Local SDP-ID | ||
Not Sent - Local SDP-ID Down | ||
Originating SDP-ID | The originating SDP-ID specified by orig-sdp. | orig-sdp-id |
Originating SDP-ID Administrative State | The local administrative state of the originating SDP-ID. If the SDP-ID has been shut down, Admin-Down is displayed. If the originating SDP-ID is in the no shutdown state, Admin-Up is displayed. If the orig-sdp-id does not exist, Non-Existent is displayed. | Admin-Up |
Admin-Down | ||
Non-Existent | ||
Originating SDP-ID Operating State | The local operational state of the originating SDP-ID. If orig-sdp-id does not exist, N/A is displayed. | Oper-Up |
Oper-Down | ||
— | ||
Originating SDP-ID Path MTU | The local path-mtu for orig-sdp-id. If orig-sdp-id does not exist locally, N/A is displayed. | orig-path-mtu |
— | ||
Responding SDP-ID | The SDP-ID requested as the far-end path to respond to the sdp-ping request. If resp-sdp is not specified, the responding router does not use an SDP-ID as the return path and N/A is displayed. | resp-sdp-id |
— | ||
Responding SDP-ID Path Used | Displays whether the responding router used the responding sdp-id to respond to the sdp-ping request. If resp-sdp-id is a valid, operational SDP-ID, it must be used for the SDP echo reply message. If the far-end uses the responding sdp-id as the return path, Yes is displayed. If the far-end does not use the responding sdp-id as the return path, No is displayed. If resp-sdp is not specified, N/A is displayed. | Yes |
No | ||
— | ||
Responding SDP-ID Administrative State | The administrative state of the responding sdp-id. When resp-sdp-id is administratively down, Admin-Down is displayed. When resp-sdp-id is administratively up, Admin-Up is displayed. When resp-sdp-id exists on the far-end router but is not valid for the originating router, Invalid is displayed. When resp-sdp-id does not exist on the far-end router, Non-Existent is displayed. When resp-sdp is not specified, N/A is displayed. | Admin-Down |
Admin-Up | ||
Invalid | ||
Non-Existent | ||
— | ||
Responding SDP-ID Operational State | The operational state of the far-end sdp-id associated with the return path for service-id. When a return path is operationally down, Oper-Down is displayed. If the return sdp-id is operationally up, Oper-Up is displayed. If the responding sdp-id is non-existent, N/A is displayed. | Oper-Up |
Oper-Down | ||
— | ||
Responding SDP-ID Path MTU | The remote path-mtu for resp-sdp-id. If resp-sdp-id does not exist remotely, N/A is displayed | resp-path-mtu |
— | ||
Local Service IP Address | The local system IP address used to terminate remotely configured sdp-ids (as the sdp-id far-end address). If an IP address has not been configured to be the system IP address, N/A is displayed. | system-ip-addr |
— | ||
Local Service IP Interface Name | The name of the local system IP interface. If the local system IP interface has not been created, N/A is displayed. | system-interface-name |
— | ||
Local Service IP Interface State | The state of the local system IP interface. If the local system IP interface has not been created, Non-Existent is displayed. | Up |
Down | ||
Non-Existent | ||
Expected Far End Address | The expected IP address for the remote system IP interface. This must be the far-end address configured for the orig-sdp-id. | orig-sdp-far-end-addr |
dest-ip-addr | ||
— | ||
Actual Far End Address | The returned remote IP address. If a response is not received, the displayed value is N/A. If the far-end service IP interface is down or non-existent, a message reply is not expected. | resp-ip-addr |
— | ||
Responders Expected Far End Address | The expected source of the originators sdp-id from the perspective of the remote router terminating the sdp-id. If the far-end cannot detect the expected source of the ingress sdp-id, N/A is displayed. | resp-rec-tunnel-far-end-addr |
— | ||
Round Trip Time | The round trip time between SDP echo request and the SDP echo reply. If the request is not sent, times out or is terminated, N/A is displayed. | delta-request-reply |
— |
Parameters
The DSCP or LSP-EXP mappings on the receive network interface controls the mapping back to the internal forwarding class used by the far-end router that receives the message request. The egress mappings of the egress network interface on the far-end router controls the forwarding class markings on the return reply message.
The DSCP or LSP-EXP mappings on the receive network interface controls the mapping of the message reply at the originating router. This is displayed in the response message output upon receipt of the message reply.
When the OAM message request is encapsulated in an IP/GRE SDP, the IP ‘DF’ (Do Not Fragment) bit is set. If any segment of the path between the sender and receiver cannot handle the message size, the message is discarded. MPLS LSPs are not expected to fragment the message either, as the message contained in the LSP is not an IP packet.
Output
Multiple Response Connectivity Tests — When the connectivity test count is greater than one (1), a single line is displayed per SDP echo request send attempt.
The request number is a sequential number starting with 1 and ending with the last request sent, incrementing by one (1) for each request. This should not be confused with the message-id contained in each request and reply message.
A response message indicates the result of the message request. Following the response message is the round trip time value. If any reply is received, the round trip time is displayed.
After the last reply has been received or response timed out, a total is displayed for all messages sent and all replies received. A maximum, minimum and average round trip time is also displayed. Error response and timed out requests do not apply towards the average round trip time.
3.14.2.9. Common Service Diagnostics
ancp
Syntax
Context
Description
This command sends an OAM request to the access node. ANCP can be used to send OAM messages to the access node. The access node must be able to accept these messages and signals such support by the capability negotiations. If the operator attempts to send an OAM command to an access node that does not support, the operation results in an error.
Parameters
host-connectivity-verify
Syntax
Context
Description
This command triggers the host connectivity verification checks and applies only to the 7450 ESS and 7750 SR.
Parameters
null | port-id | bundle-id | bpgrp-id | lag-id | aps-id | ||
dot1q | port-id | bundle-id | bpgrp-id | lag-id | aps-id | pw-id:[qtag1|cp-conn-prof-id] | ||
qinq | port-id | bundle-id | bpgrp-id | lag-id | pw-id:[qtag1 cp-conn-prof-id].[qtag2 | cp-conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
atm | port-id | aps-id [:vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
frame | port-id | aps-id:dlci | ||
cisco-hdlc | slot/mda/port.channel | ||
cem | slot/mda/port.channel | ||
ima-grp | bundle-id [:vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
port-id | slot/mda/port[.channel] esat-id/slot/port pxc-id.sub-port | ||
bundle-id | bundle-type-slot/mda.-bundle-num | ||
bundle | keyword | ||
type | ima | fr | ppp | ||
bundle-num | 1 to 336 | ||
bpgrp-id | bpgrp-type-bpgrp-num | ||
bgrp | keyword | ||
type | ima | ppp | ||
bgrp-num | 1 to 2000 | ||
aps-id | aps-group-id[.channel] | ||
aps | keyword | ||
group-id | 1 to 128 | ||
ccag-id | ccag-id.path-id[cc-type]:cc-id | ||
ccag | keyword | ||
id | 1 to 8 | ||
path-id | a | b | ||
cc-type | .sap-net | .net-sap | ||
cc-id | 1 to 4094 | ||
eth-tunnel | eth-tunnel-id[:eth-tun-sap-id] | ||
id | 1 to 1024 | ||
eth-tun-sap-id | 0 to 4094 | ||
lag-id | lag-id | ||
lag | keyword | ||
id | 1 to 800 | ||
pw-id | pw-id | ||
pw | keyword | ||
id | 1 to 10239 | ||
qtag1 | * | 0 to 4094 | ||
qtag2 | * | null | 0 to 4094 | ||
vpi | 0 to 4095 (NNI) | ||
0 to 255 (UNI) | |||
vci | 1 | 2 | 5 to 65535 | ||
dlci | 16 to 1022 | ||
tunnel-id | tunnel-id.private | public:tag | ||
tunnel | keyword | ||
id | 1 to 16 | ||
tag | 0 to 4094 | ||
svc-ping
Syntax
Context
Description
This command tests a service ID for correct and consistent provisioning between two service end points.
The svc-ping command accepts a far-end IP address and a service ID for local and remote service testing. The following information can be determined from svc-ping:
Local and remote service existence
- Local and remote service state
- Local and remote service type correlation
- Local and remote customer association
- Local and remote service-to-SDP bindings and state
- Local and remote ingress and egress service label association
Unlike sdp-ping, only a single message is sent per command; no count nor interval parameter is supported and round trip time is not calculated. A time out value of 10 seconds is used before failing the request. The forwarding class is assumed to be Best-Effort Out-of-Profile.
If no request is sent or a reply is not received, all remote information is shown as N/A.
To terminate a svc-ping in progress, use the CLI break sequence <Ctrl-C>.
Upon request time out, message response, request termination, or request error the following local and remote information is displayed. See Table 27. Local and remote information is dependent upon service existence and reception of reply.
Table 27: Svc-ping
Field | Description | Values |
Request Result | The result of the svc-ping request message. | Sent - Request Timeout |
Sent - Request Terminated | ||
Sent - Reply Received | ||
Not Sent - Non-Existent Service-ID | ||
Not Sent - Non-Existent SDP for Service | ||
Not Sent - SDP For Service Down | ||
Not Sent - Non-existent Service Egress Label | ||
Service-ID | The ID of the service being tested. | service-id |
Local Service Type | The type of service being tested. If service-id does not exist locally, N/A is displayed. | Epipe, Ipipe, Fpipe, Apipe |
TLS | ||
IES | ||
Mirror-Dest | ||
— | ||
Local Service Admin State | The local administrative state of service-id. If the service does not exist locally, the administrative state is Non-Existent. | Admin-Up |
Admin-Down | ||
Non-Existent | ||
Local Service Oper State | The local operational state of service-id. If the service does not exist locally, the state is N/A. | Oper-Up |
Oper-Down | ||
— | ||
Remote Service Type | The remote type of service being tested. If service-id does not exist remotely, N/A is displayed. | Epipe, Ipipe, Fpipe, Apipe |
TLS | ||
IES | ||
Mirror-Dest | ||
— | ||
Remote Service Admin State | The remote administrative state of service-id. If the service does not exist remotely, the administrative state is Non-Existent. | Up |
Down | ||
Non-Existent | ||
Local Service MTU | The local service-mtu for service-id. If the service does not exist, N/A is displayed. | service-mtu |
— | ||
Remote Service MTU | The remote service-mtu for service-id. If the service does not exist remotely, N/A is displayed. | remote-service-mtu |
— | ||
Local Customer ID | The local customer-id associated with service-id. If the service does not exist locally, N/A is displayed. | customer-id |
— | ||
Remote Customer ID | The remote customer-id associated with service-id. If the service does not exist remotely, N/A is displayed. | customer-id |
— | ||
Local Service IP Address | The local system IP address used to terminate remotely configured SDP-ID (as the far-end address). If an IP interface has not been configured to be the system IP address, N/A is displayed. | system-ip-address |
— | ||
Local Service IP Interface Name | The name of the local system IP interface. If the local system IP interface has not been created, N/A is displayed. | system-interface-name |
— | ||
Local Service IP Interface State | The state of the local system IP interface. If the local system IP interface has not been created, Non-Existent is displayed. | Up |
Down | ||
Non-Existent | ||
Expected Far-end Address | The expected IP address for the remote system IP interface. This must be the far-end address entered for the svc-ping command. | orig-sdp-far-end-addr |
dest-ip-addr | ||
— | ||
Actual Far-end Address | The returned remote IP address. If a response is not received, the displayed value is N/A. If the far-end service IP interface is down or non-existent, a message reply is not expected. sdp-ping should also fail. | resp-ip-addr |
— | ||
Responders Expected Far-end Address | The expected source of the originator’s sdp-id from the perspective of the remote router terminating the sdp-id. If the far-end cannot detect the expected source of the ingress sdp-id or the request is transmitted outside the sdp-id, N/A is displayed. | resp-rec-tunnel-far-end-address |
— | ||
Originating SDP-ID | The sdp-id used to reach the far-end IP address if sdp-path is defined. The originating sdp-id must be bound to the service-id and terminate on the far-end IP address. If an appropriate originating sdp-id is not found, Non-Existent is displayed. | orig-sdp-id |
Non-Existent | ||
Originating SDP-ID Path Used | Whether the Originating router used the originating sdp-id to send the svc-ping request. If a valid originating sdp-id is found, operational and has a valid egress service label, the originating router should use the sdp-id as the requesting path if sdp-path has been defined. If the originating router uses the originating sdp-id as the request path, Yes is displayed. If the originating router does not use the originating sdp-id as the request path, No is displayed. If the originating sdp-id is non-existent, N/A is displayed. | Yes |
No | ||
— | ||
Originating SDP-ID Administrative State | The local administrative state of the originating sdp-id. If the sdp-id has been shutdown, Admin-Down is displayed. If the originating sdp-id is in the no shutdown state, Admin-Up is displayed. If an originating sdp-id is not found, N/A is displayed. | Admin-Up |
Admin-Up | ||
— | ||
Originating SDP-ID Operating State | The local operational state of the originating sdp-id. If an originating sdp-id is not found, N/A is displayed. | Oper-Up |
Oper-Down | ||
— | ||
Originating SDP-ID Binding Admin State | The local administrative state of the originating sdp-ids binding to service-id. If an sdp-id is not bound to the service, N/A is displayed. | Admin-Up |
Admin-Up | ||
— | ||
Originating SDP-ID Binding Oper State | The local operational state of the originating sdp-ids binding to service-id. If an sdp-id is not bound to the service, N/A is displayed. | Oper-Up |
Oper-Down | ||
— | ||
Responding SDP-ID | The sdp-id used by the far end to respond to the svc-ping request. If the request was received without the sdp-path parameter, the responding router does not use an sdp-id as the return path, but the appropriate responding sdp-id is displayed. If a valid sdp-id return path is not found to the originating router that is bound to the service-id, Non-Existent is displayed. | resp-sdp-id |
Non-Existent | ||
Responding SDP-ID Path Used | Whether the responding router used the responding sdp-id to respond to the svc-ping request. If the request was received via the originating sdp-id and a valid return sdp-id is found, operational and has a valid egress service label, the far-end router should use the sdp-id as the return sdp-id. If the far end uses the responding sdp-id as the return path, Yes is displayed. If the far end does not use the responding sdp-id as the return path, No is displayed. If the responding sdp-id is non-existent, N/A is displayed. | Yes |
No | ||
— | ||
Responding SDP-ID Administrative State | The administrative state of the far-end sdp-id associated with the return path for service-id. When a return path is administratively down, Admin-Down is displayed. If the return sdp-id is administratively up, Admin-Up is displayed. If the responding sdp-id is non-existent, N/A is displayed. | Admin-Up |
Admin-Up | ||
N/A | ||
Responding SDP-ID Operational State | The operational state of the far-end sdp-id associated with the return path for service-id. When a return path is operationally down, Oper-Down is displayed. If the return sdp-id is operationally up, Oper-Up is displayed. If the responding sdp-id is non-existent, N/A is displayed. | Oper-Up |
Oper-Down | ||
— | ||
Responding SDP-ID Binding Admin State | The local administrative state of the responder’s sdp-id binding to service-id. If an sdp-id is not bound to the service, N/A is displayed. | Admin-Up |
Admin-Down | ||
— | ||
Responding SDP-ID Binding Oper State | The local operational state of the responder’s sdp-id binding to service-id. If an sdp-id is not bound to the service, N/A is displayed. | Oper-Up |
Oper-Down | ||
— | ||
Originating VC-ID | The originator’s VC-ID associated with the sdp-id to the far-end address that is bound to service-id. If the sdp-id signaling is off, originator-vc-id is 0. If the originator-vc-id does not exist, N/A is displayed. | originator-vc-id |
— | ||
Responding VC-ID | The responder’s VC-ID associated with the sdp-id to originator-id that is bound to service-id. If the sdp-id signaling is off or the service binding to sdp-id does not exist, responder-vc-id is 0. If a response is not received, N/A is displayed. | responder-vc-id |
— | ||
Originating Egress Service Label | The originating service label (VC-Label) associated with the service-id for the originating sdp-id. If service-id does not exist locally, N/A is displayed. If service-id exists, but the egress service label has not been assigned, Non-Existent is displayed. | egress-vc-label |
— | ||
Non-Existent | ||
Originating Egress Service Label Source | The originating egress service label source. If the displayed egress service label is manually defined, Manual is displayed. If the egress service label is dynamically signaled, Signaled is displayed. If the service-id does not exist or the egress service label is non-existent, N/A is displayed. | Manual |
Signaled | ||
— | ||
Originating Egress Service Label State | The originating egress service label state. If the originating router considers the displayed egress service label operational, Up is displayed. If the originating router considers the egress service label inoperative, Down is displayed. If the service-id does not exist or the egress service label is non-existent, N/A is displayed. | Up |
Down | ||
— | ||
Responding Service Label | The actual responding service label in use by the far-end router for this service-id to the originating router. If service-id does not exist in the remote router, N/A is displayed. If service-id does exist remotely but the remote egress service label has not been assigned, Non-Existent is displayed. | rec-vc-label |
— | ||
Non-Existent | ||
Responding Egress Service Label Source | The responder’s egress service label source. If the responder’s egress service label is manually defined, Manual is displayed. If the responder’s egress service label is dynamically signaled, Signaled is displayed. If the service-id does not exist on the responder or the responder’s egress service label is non-existent, N/A is displayed. | Manual |
Signaled | ||
— | ||
Responding Service Label State | The responding egress service label state. If the responding router considers its egress service label operational, Up is displayed. If the responding router considers its egress service label inoperative, Down is displayed. If the service-id does not exist or the responder’s egress service label is non-existent, N/A is displayed. | Up |
Down | ||
— | ||
Expected Ingress Service Label | The locally assigned ingress service label. This is the service label that the far-end is expected to use for service-id when sending to the originating router. If service-id does not exist locally, N/A is displayed. If service-id exists but an ingress service label has not been assigned, Non-Existent is displayed. | ingress-vc-label |
— | ||
Non-Existent | ||
Expected Ingress Label Source | The originator’s ingress service label source. If the originator’s ingress service label is manually defined, Manual is displayed. If the originator’s ingress service label is dynamically signaled, Signaled is displayed. If the service-id does not exist on the originator or the originators ingress service label has not been assigned, N/A is displayed. | Manual |
Signaled | ||
— | ||
Expected Ingress Service Label State | The originator’s ingress service label state. If the originating router considers its ingress service label operational, Up is displayed. If the originating router considers its ingress service label inoperative, Down is displayed. If the service-id does not exist locally, N/A is displayed. | Up |
Down | ||
— | ||
Responders Ingress Service Label | The assigned ingress service label on the remote router. This is the service label that the far end is expecting to receive for service-id when sending to the originating router. If service-id does not exist in the remote router, N/A is displayed. If service-id exists, but an ingress service label has not been assigned in the remote router, Non-Existent is displayed. | resp-ingress-vc-label |
— | ||
Non-Existent | ||
Responders Ingress Label Source | The assigned ingress service label source on the remote router. If the ingress service label is manually defined on the remote router, Manual is displayed. If the ingress service label is dynamically signaled on the remote router, Signaled is displayed. If the service-id does not exist on the remote router, N/A is displayed. | Manual |
Signaled | ||
— | ||
Responders Ingress Service Label State | The assigned ingress service label state on the remote router. If the remote router considers its ingress service label operational, Up is displayed. If the remote router considers its ingress service label inoperative, Down is displayed. If the service-id does not exist on the remote router or the ingress service label has not been assigned on the remote router, N/A is displayed. | Up |
Down | ||
— |
Parameters
If local-sdp is not specified, the svc-ping request message is sent with GRE encapsulation with the OAM label.
Table 28 indicates whether a message is sent and how the message is encapsulated based on the state of the service ID.
Table 28: Message Encapsulation
Local Service State | local-sdp Not Specified | local-sdp Specified | ||
Message Sent | Message Encapsulation | Message Sent | Message Encapsulation | |
Invalid Local Service | Yes | Generic IP/GRE OAM (PLP) | No | None |
No Valid SDP-ID Bound | Yes | Generic IP/GRE OAM (PLP) | No | None |
SDP-ID Valid But Down | Yes | Generic IP/GRE OAM (PLP) | No | None |
SDP-ID Valid and Up, But No Service Label | Yes | Generic IP/GRE OAM (PLP) | No | None |
SDP-ID Valid, Up and Egress Service Label | Yes | Generic IP/GRE OAM (PLP) | Yes | SDP Encapsulation with Egress Service Label (SLP) |
If remote-sdp is specified, the far-end responder attempts to use an egress sdp-id bound to the service with the message originator as the destination IP address with the VC-Label for the service. The sdp-id defines the encapsulation of the SDP tunnel encapsulation used to reply to the originator; this can be IP/GRE or MPLS. On responder egress, the service-ID must have an associated VC-Label to reach the originator address of the sdp-id and the sdp-id must be operational for the message to be sent.
If remote-sdp is not specified, the svc-ping request message is sent with GRE encapsulation with the OAM label.
Table 29 indicates how the message response is encapsulated based on the state of the remote service ID.
Table 29: Message Response Encapsulation
Remote Service State | Message Encapsulation | |
remote-sdp Not Specified | remote-sdp Specified | |
Invalid Ingress Service Label | Generic IP/GRE OAM (PLP) | Generic IP/GRE OAM (PLP) |
Invalid Service-ID | Generic IP/GRE OAM (PLP) | Generic IP/GRE OAM (PLP) |
No Valid SDP-ID Bound on Service-ID | Generic IP/GRE OAM (PLP) | Generic IP/GRE OAM (PLP) |
SDP-ID Valid But Down | Generic IP/GRE OAM (PLP) | Generic IP/GRE OAM (PLP) |
SDP-ID Valid and Up, but No Service Label | Generic IP/GRE OAM (PLP) | Generic IP/GRE OAM (PLP) |
SDP-ID Valid and Up, Egress Service Label, but VC-ID Mismatch | Generic IP/GRE OAM (PLP) | Generic IP/GRE OAM (PLP) |
SDP-ID Valid and Up, Egress Service Label, but VC-ID Match | Generic IP/GRE OAM (PLP) | SDP Encapsulation with Egress Service Label (SLP) |
Output
vprn-ping
Syntax
Context
Description
This command performs a VPRN ping and applies only to the 7750 SR and 7950 XRS.
Parameters
This variant of the command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic). The configure saa test type vprn-ping service service-name variant can be used in all configuration modes.
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D |
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D |
If the interval is set to 1 second where the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
Output
vprn-trace
Syntax
Context
Description
This command is used to perform a VPRN trace.
Parameters
This variant of the command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic). The configure saa test type vprn-trace service service-name variant can be used in all configuration modes.
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D |
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D |
If the interval is set to 1 second where the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
Output
3.14.2.10. VLL Diagnostics
vccv-ping
Syntax
Context
Description
This command configures a Virtual Circuit Connectivity Verification (VCCV) ping test. A vccv-ping test checks connectivity of a VLL inband. It checks to verify that the destination (target) PE is the egress for the Layer 2 FEC. It provides for a cross-check between the dataplane and the control plane. It is inband which means that the vccv-ping message is sent using the same encapsulation and along the same path as user packets in that VLL. The vccv-ping test is the equivalent of the lsp-ping test for a VLL service. The vccv-ping reuses an lsp-ping message format and can be used to test a VLL configured over both an MPLS and a GRE SDP.
Note that VCCV ping can be initiated on T-PE or S-PE. If initiated on the S-PE, the reply-mode parameter must be used with the ip-routed value The ping from the T-PE can have either values or can be omitted, in which case the default value is used.
If a VCCV ping is initiated from T-PE to neighboring a S-PE (one segment only), then it is sufficient to only use the spoke-sdp-fec-id parameter. However, if the ping is across two or more segments, at least the spoke-sdp-fec-id, src-ip-address ip-addr, dst-ip-address ip-addr, ttl vc-label-ttl parameters are used where:
- The src-ip-address is system IP address of the router preceding the destination router.
- The vc-label-ttl parameter must have a value equal or higher than the number of pseudowire segments.
Note that VCCV ping is a multi-segment pseudowire. For a single-hop pseudowire, only the peer VCCV CC bit of the control word is advertised when the control word is enabled on the pseudowire.
VCCV ping on multi-segment pseudowires require that the control word be enabled in all segments of the VLL. If the control word is not enabled on a spoke SDP, it is signaled peer VCCV CC bits to the far end, consequently the vccv-ping cannot be successfully initiated on that specific spoke SDP.
If the saii-type-2 and taii-type-2 parameters are specified by the user of this command for a FEC129 pseudowire, then these values are used by the vccv-ping echo request message instead of the saii and taii of the spoke-sdp indexed by the spoke-sdp-fec parameter, or any saii and taii received in a switching point TLV for the pseudowire. Furthermore, the user must enter the saii and taii in accordance with the direction of the pseudowire as seen from the node on which the vccv-ping command is executed. However, the values of the saii and taii sent in the echo request message are swapped with respect to the user-entered values to match the order in the installed FEC on the targeted node. The output of the command for FEC129 type 2 pseudowire reflects the order of the saii and taii stored on the targeted node.
This command, when used with the static option, configures a Virtual Circuit Connectivity Verification (VCCV) ping test for static MPLS-TP pseudowires used in a VLL service. It checks to verify that the destination (target) PE is the egress for the Static PW FEC. It provides for a cross-check between the dataplane and the configuration. The vccv-ping static command reuses an lsp-ping message format and can be used to test an MPLS-TP pseudowire VLL configured over an MPLS SDP. VCCV Ping for MPLS-TP pseudowires always uses the VCCV control word (associated channel header) with either an IPv4 channel type (0x0021) or on-demand CV message channel type (0x0025).
Note that vccv-ping static can only be initiated on a T-PE. Both the echo request and reply messages are send using the same, in-band, encapsulation. If the target-fec-type option is not specified, then the target FEC stack contains a static PW FEC TLV. The contents of this TLV are populated based on the source node ID, source global ID, and destination global ID and destination node ID in the vccv-ping command (or taken from the pseudowire context if omitted from the command).
The target-fec-type option allows the user to test a segment of a MS-PW that does not have the same FEC type as the local segment from the T-PE where the vccv-ping command is issued. This is applicable for performing VCCV ping on an MS-PW comprised of static PW FEC segments and dynamically signaled PW ID FEC segments.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
global-id — Specifies the global ID of the SAII of the targeted static PW FEC element. | |
Values | 0 to 4294967295 |
node-id — Specifies the node-id on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d 1 to 4294967295 |
ac-id — Specifies an unsigned integer representing a locally unique SAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
global-id — Specifies the global ID of the SAII of the targeted static PW FEC element. | |
Values | 0 to 4294967295 |
node-id — Specifies the node-id on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d 1 to 4294967295 |
ac-id — Specifies an unsigned integer representing a locally unique SAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
global-id — Specifies the global ID of the far end T-PE of the FEC129 pseudowire. | |
Values | 0 to 4294967295 |
Default | 0 |
node-id — Specifies the node-id on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d 1 to 4294967295 |
ac-id — Specifies an unsigned integer representing a locally unique TAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
spoke-sdp-fec is mutually exclusive with the sdp-id:vc-id parameter.
The LSP-EXP mappings on the receive network interface controls the mapping back to the internal forwarding class used by the far-end 7750 SR that receives the message request. The egress mappings of the egress network interface on the far-end router controls the forwarding class markings on the return reply message. The LSP-EXP mappings on the receive network interface controls the mapping of the message reply at the originating SR.
Table 30: vccv-ping Request Packet and Behavior
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
Output
The following output is an example of VCCV ping information.
vccv-trace
Syntax
Context
Description
This command configures a Virtual Circuit Connectivity Verification (VCCV) automated trace test. The automated VCCV-trace can trace the entire path of a PW with a single command issued at the T-PE or at an S-PE. This is equivalent to LSP-Trace and is an iterative process by which the source T-PE or S-PE node sends successive VCCV-Ping messages with incrementing the TTL value, starting from TTL=1. In each iteration, the T-PE builds the MPLS echo request message in a way like VCCV-Ping. The first message with TTL=1 has the next-hop S-PE T-LDP session source address in the Remote PE Address field in the PW FEC TLV. Each S-PE which terminates and processes the message includes in the MPLS echo reply message the FEC 128 TLV corresponding the PW segment to its downstream node. The source T-PE or S-PE node can then build the next echo reply message with TTL=2 to test the next-next hop for the MS-PW. It copies the FEC TLV it received in the echo reply message into the new echo request message. The process is terminated when the reply is from the egress T-PE or when a time out occurs.
The user can specify to display the result of the VCCV-trace for a fewer number of PW segments of the end-to-end MS-PW path. In this case, the min-ttl and max-ttl parameters are configured accordingly. However, the T-PE/S-PE node still probes all hops up to min-ttl to correctly build the FEC of the desired subset of segments.
Note that if the saii-type-2 and taii-type-2 parameters are specified this command for a FEC129 pseudowire, then these values are used by the vccv-ping echo request message instead of the saii and taii of the spoke SDP indexed by the spoke-sdp-fec parameter, or any saii and taii received in a switching point TLV for the pseudowire. Furthermore, the use must enter the saii and taii in accordance with the direction of pseudowire as seen from the node on which the vccv-trace command is executed. However, the values of the saii and taii sent in the echo request message are swapped with respect to the user-entered values to match the order in the installed FEC on the targeted node. The output of the command for a FEC129 type 2 pseudowire reflects the order of the saii and taii stored on the targeted node.
This command, when used with the static option, configures a VCCV-automated trace test for static MPLS-TP pseudowires used in a VLL service. VCCV trace for MPLS-TP pseudowires always uses the VCCV control word (associated channel header) with either an IPv4 channel type (0x0021) or on-demand CV message channel type (0x0025).
Note that vccv-trace static can only be initiated on a T-PE. Both the echo request and reply messages are send using the same, in-band, encapsulation. The target FEC stack contains a static PW FEC TLV. The contents of this TLV are populated based on the source Node ID, source global ID, and destination global ID and destination node ID taken from the pseudowire context.
The target-fec-type option allows the user to perform a vccv-trace to a segment of a MS-PW that does not have the same FEC type as the local segment from the T-PE where the vccv-trace command is issued. This is applicable for performing VCCV ping on an MS-PW comprised of static PW FEC segments and dynamically signaled PW ID FEC segments.
Parameters
global-id — Specifies the global ID of the SAII of the targeted static PW FEC element. | |
Values | 0 to 4294967295 |
Default | 0 |
node-id — Specifies the node ID on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d 1 to 4294967295 |
ac-id — Specifies an unsigned integer representing a locally unique SAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
global-id — Specifies the global ID of the SAII of the targeted static PW FEC element. | |
Values | 0 to 4294967295 |
Default | 0 |
node-id — Specifies the node ID of the far-end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d 1 to 4294967295 |
ac-id — Specifies an unsigned integer representing a locally unique SAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
The saii-type2 parameter is mutually exclusive with the sdp-id:vc-id parameter.
global-id — Specifies the global ID of this T-PE node. | |
Values | 1 to 4294967295 |
prefix — Specifies the prefix on this T-PE node that the spoke SDP is associated with. | |
ac-id — Specifies an unsigned integer representing a locally unique identifier for the spoke SDP. | |
Values | 1 to 4294967295 |
global-id — Specifies the global ID of the far end T-PE of the FEC129 pseudowire. | |
Values | 0 to 4294967295 |
node-id — Specifies the node ID on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d 1 to 4294967295 |
ac-id — Specifies an unsigned integer representing a locally unique TAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
spoke-sdp-fec is mutually exclusive with the sdp-id:vc-id parameter.
The LSP-EXP mappings on the receive network interface controls the mapping back to the internal forwarding class used by the far-end router that receives the message request. The egress mappings of the egress network interface on the far-end router controls the forwarding class markings on the return reply message. The LSP-EXP mappings on the receive network interface controls the mapping of the message reply at the originating router.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the FC and profile parameter values determined by the classification of the echo request packet, which is being replied to, at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
The ToS byte is not modified. Table 31 summarizes this behavior.
Table 31: vccv trace Request Packet and Behavior
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
Output
Trace with detail:
cpe-ping
Syntax
Context
Description
This ping utility determines the IP connectivity to a CPE within a specified VPLS service.
Parameters
service-id: | 1 to 2147483647 |
svc-name: | 64 characters maximum |
If the interval is set to 1 second where the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
mac-populate
Syntax
Context
Description
This command populates the FDB with an OAM-type MAC entry indicating the node is the egress node for the MAC address and optionally floods the OAM MAC association throughout the service. The mac-populate command installs an OAM MAC into the service FDB indicating the device is the egress node for a MAC address. The MAC address can be bound to a SAP (the target-sap) or can be associated with the control plane in that any data destined to the MAC address is forwarded to the control plane (CPM). As a result, if the service on the node has neither a FDB nor an egress SAP, then it is not allowed to initiate a mac-populate.
The MAC address that is populated in the FDBs in the provider network is given a type OAM, so that it can be treated distinctly from regular dynamically learned or statically configured MACs. Note that OAM MAC addresses are operational MAC addresses and are not saved in the device configuration. An exec file can be used to define OAM MACs after system initialization.
The force option in mac-populate forces the MAC in the table to be type OAM in the case it already exists as a dynamic, static or an OAM induced learned MAC with some other type binding.
An OAM-type MAC cannot be overwritten by dynamic learning and allows customer packets with the MAC to either ingress or egress the network while still using the OAM MAC entry.
The flood option causes each upstream node to learn the MAC (that is, populate the local FDB with an OAM MAC entry) and to flood the request along the data plane using the flooding domain. The flooded mac-populate request is sent via the data plane.
An age can be provided to age an OAM MAC using a specific interval. By default, OAM MAC addresses are not aged and can be removed with a mac-purge or with an FDB clear operation.
When split horizon group (SHG) is configured, the flooding domain depends on which SHG the packet originates from. The target-sap sap-id value dictates the originating SHG information.
Parameters
When the target-sap sap-id value is not specified the MAC is bound to the CPM or CFM. The originating SHG is 0 (zero). When the target-sap sap-id value is specified, the originating SHG is the SHG of the target-sap.
:null | port-id | bundle-id | bpgrp-id | lag-id | aps-id | ||
dot1q | port-id | bundle-id | bpgrp-id | lag-id | aps-id | pw-id:[qtag1|cp-conn-prof-id] | ||
qinq | port-id | bundle-id | bpgrp-id | lag-id | pw-id:[qtag1 cp-conn-prof-id].[qtag2 | cp-conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
atm | port-id | aps-id [:vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
frame | port-id | aps-id:dlci | ||
cisco-hdlc | slot/mda/port.channel | ||
cem | slot/mda/port.channel | ||
ima-grp | bundle-id [:vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
port-id | slot/mda/port[.channel] esat-id/slot/port pxc-id.sub-port | ||
bundle-id | bundle-type-slot/mda.-bundle-num | ||
bundle | keyword | ||
type | ima | fr | ppp | ||
bundle-num | 1 to 336 | ||
bpgrp-id | bpgrp-type-bpgrp-num | ||
bgrp | keyword | ||
type | ima | ppp | ||
bgrp-num | 1 to 2000 | ||
aps-id | aps-group-id[.channel] | ||
aps | keyword | ||
group-id | 1 to 128 | ||
ccag-id | ccag-id.path-id[cc-type]:cc-id | ||
ccag | keyword | ||
id | 1 to 8 | ||
path-id | a | b | ||
cc-type | .sap-net | .net-sap | ||
cc-id | 1 to 4094 | ||
eth-tunnel | eth-tunnel-id[:eth-tun-sap-id] | ||
id | 1 to 1024 | ||
eth-tun-sap-id | 0 to 4094 | ||
lag-id | lag-id | ||
lag | keyword | ||
id | 1 to 800 | ||
pw-id | pw-id | ||
pw | keyword | ||
id | 1 to 10239 | ||
qtag1 | * | 0 to 4094 | ||
qtag2 | * | null | 0 to 4094 | ||
vpi | 0 to 4095 (NNI) | ||
0 to 255 (UNI) | |||
vci | 1 | 2 | 5 to 65535 | ||
dlci | 16 to 1022 | ||
tunnel-id | tunnel-id.private | public:tag | ||
tunnel | keyword | ||
id | 1 to 16 | ||
tag | 0 to 4094 | ||
mac-purge
Syntax
Context
Description
This command removes an OAM-type MAC entry from the FDB and optionally floods the OAM MAC removal throughout the service. A mac-purge can be sent via the forwarding path or via the control plane.
When sending the MAC purge using the data plane, the TTL in the VC label is set to 1.
A MAC address is purged only if it is marked as OAM. A mac-purge request is an HVPLS OAM packet, with the following fields. The Reply Flags is set to 0 (since no reply is expected), the Reply Mode and Reserved fields are set to 0. The Ethernet header has source set to the (system) MAC address, the destination set to the broadcast MAC address. There is a VPN TLV in the FEC Stack TLV to identify the service domain.
If the register option is provided, the R bit in the Address Delete flags is turned on.
The flood option causes each upstream node to be sent the OAM MAC delete request and to flood the request along the data plane using the flooding domain. The flooded mac-purge request is sent via the data plane.
The register option reserves the MAC for OAM testing where it is no longer an active MAC in the FDB for forwarding, but it is retained in the FDB as a registered OAM MAC. Registering an OAM MAC prevents relearns for the MAC based on customer packets. Relearning a registered MAC can only be done through a mac-populate request. The originating SHG is always 0 (zero).
Parameters
mac-ping
Syntax
Context
Description
This command determines the existence of an egress SAP binding of a given MAC within a VPLS service.
A mac-ping packet is sent via the data plane.
A mac-ping is forwarded along the flooding domain if no MAC address bindings exist. If MAC address bindings exist, then the packet is forwarded along those paths, provided they are active. A response is generated only when there is an egress SAP binding for that MAC address or if the MAC address is a “local” OAM MAC address associated with the device’s control plan.
A mac-ping reply can be sent using the data plane or the control plane. The return-control option specifies the reply be sent using the control plane. If return-control is not specified, the request is sent using the data plane.
A mac-ping with data plane reply can only be initiated on nodes that can have an egress MAC address binding. A node without a FDB and without any SAPs cannot have an egress MAC address binding, so it is not a node where replies in the data plane are trapped and sent up to the control plane.
A control plane request is responded to via a control plane reply only.
By default, MAC OAM requests are sent with the system or chassis MAC address as the source MAC. The source option allows overriding of the default source MAC for the request with a specific MAC address.
When a source ieee-address value is specified and the source MAC address is locally registered within a split horizon group (SHG), then this SHG membership is used as if the packet originated from this SHG. In all other cases, SHG 0 (zero) is used. If the mac-trace is originated from a non-zero SHG, such packets do not go out to the same SHG.
Parameters
If the interval is set to 1 second where the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
mac-trace
Syntax
Context
Description
This command displays the hop-by-hop path for a destination MAC address within a VPLS.
The MAC traceroute operation is modeled after the IP traceroute utility which uses ICMP echo request and reply packets with increasing TTL values to determine the hop-by-hop route to a destination IP. The MAC traceroute command uses Nokia OAM packets with increasing TTL values to determine the hop-by-hop route to a destination MAC.
In a MAC traceroute, the originating device creates a MAC ping echo request packet for the MAC to be tested with increasing values of the TTL. The echo request packet is sent via the data plane and awaits a TTL exceeded response or the echo reply packet from the device with the destination MAC. The devices that reply to the echo request packets with the TTL exceeded and the echo reply are displayed.
When a source ieee-address value is specified and the source MAC address is locally registered within a split horizon group (SHG), then this SHG membership is used as if the packet originated from this SHG. In all other cases, SHG 0 (zero) is used. Note that if the mac-ping is originated from a non-zero SHG, such packets do not go out to the same SHG.
Parameters
This variant of the command is only supported in the classic configuration-mode (configure system management-interface configuration-mode classic).
service-id: | 1 to 2147483647 |
svc-name: | up to 64 characters |
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
vxlan-ping
Syntax
Context
Description
Operational command used to validate the VXLAN Tunnel Endpoint (VXLAN) connectivity between peers.
Parameters
service-id: | 1 to 2147483647 |
svc-name: | up to 64 characters |
3.14.2.11. Ethernet in the First Mile (EFM) Commands
efm
Syntax
Context
Description
This command enables Ethernet in the First Mile (EFM) OAM tests loopback tests on the specified port. The EFM OAM remote loopback OAMPDU is sent to the peering device to trigger remote loopback.
When EFM OAM is disabled or shutdown on a port, the dying gasp flag for the OAMPDU is set for the OAMPDUs sent to the peer. This speeds up the peer loss detection time.
Parameters
 | Note: On the 7950 XRS, The XMA ID takes the place of the MDA. |
port-id | slot/mda/port [.channel] | ||
eth-sat-id | esat-id/slot/port | ||
esat | keyword | ||
id | 1 to 20 | ||
pxc-id | pxc-id.sub-port | ||
pxc | keyword | ||
id | 1 to 64 | ||
sub-port | a, b | ||
For EFM OAM tunneling to function properly, EFM OAM tunneling should be configured for VLL services or a VPLS service with two SAPs only.
3.14.2.12. ETH-CFM OAM Commands
auto-mep-discovery
Syntax
Context
Description
This command enables the ability to auto-discover remote MEPs from a peer MEP sending ETH-CC.
The no form of this command disables the ability to auto-discover remote MEPs from a peer MEP sending ETH-CC.
Default
no auto-mep-discovery
bridge-identifier
Syntax
Context
Description
This command configures the ID for the association.
The no form of this command removes the bridge ID and bridge name from the configuration.
Parameters
id-permission
Syntax
Context
Description
This command allows the operator to include the sender-id TLV information that was specified under the config>eth>system>sender-id configuration for service MEPs and MIPs. When this option is present under the maintenance association, the specific MPs in the association includes the sender-id TLV information in ETH-CFM PDUs. MEPs include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs includes this value in the LBR and LTR PDUs.
| Note: LBR functions reflect all TLVs received in the LBM unchanged including the SenderID TLV. Transmission of the Management Domain and Management Address fields are not supported in this TLV. |
Parameters
mhf-creation
Syntax
Context
Description
This command defines the MIP method of creation. MIP creation mode and other factors are part of the MIP creation authority (association or default-domain) logic. The MIP creation algorithm may result in multiple potential MIPs. Only the lowest-level valid MIP is installed. The static creation mode is the exception to the single MIP installation rule.
Under the association context, the level level parameter is not supported as part of this command. The level is derived from the level configuration of the domain.
The no form of this command is only available under the association context, and reverts the current mode of creation to the default none. In order to transition to and from the static mode of operation, the active mhf-creation mode must be none.
Default
mhf-creation none
Parameters
mip-ltr-priority
Syntax
Context
Description
This command allows the operator to set the priority of the Linktrace Response Message (ETH-LTR) from a MIP for this association.
Default
7
Parameters
vlan
Syntax
Context
Description
This command configures the bridge identifier primary VLAN ID. This is informational only, and no verification is done to ensure MEPs on this association are on the configured VLAN.
The no form of this command reverts to the default value.
Default
no vlan
Parameters
ccm-hold-time
Syntax
Context
Description
This command allows a sub second CCM enabled MEP to delay a transition to a failed state if a configured remote CCM peer has timed out. The MEP remains in the UP state for 3.5 times CCM interval + down-delay.
The no form of this command removes the additional delay.
Default
no ccm-hold-time
Parameters
ccm-interval
Syntax
Context
Description
This command configures the CCM transmission interval for all MEPs in the association.
The no form of this command reverts to the default value.
Default
no ccm-interval
Parameters
facility-id-permission
Syntax
Context
Description
This command allows the operator to include the sender-id TLV information that was specified under the config>eth>system>sender-id context for facility base MEPs. When this option is present under the maintenance association, the specific MPs in the association included the sender-id TLV information in ETH-CFM PDUs. MEPs include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs include this value in the LBR and LTR PDUs.
| Note: LBR functions reflect all TLVs received in the LBM unchanged including the SenderID TLV. This command produces an error when a bridge-identifier is configured under the association. Facility MEPs do not support the bridge-identifier. Transmission of the Management Domain and Management Address fields are not supported in this TLV. |
Parameters
remote-mepid
Syntax
Context
Description
This command configures the remote MEP ID. Optionally, the operator may configure a unicast MAC address associated with the remote MEP. This unicast value replaces the default Layer 2 class 1 multicast address that is typically associated with ETH-CC packets.
| Note: This command is not supported with sub second CCM intervals. The unicast-da parameter may only be configured when a single remote MEP exists in the association. |
The no form of this command removes the peer information.
Parameters
md-auto-id
Syntax
Context
Description
This command automatically assigns numerical index values for ma-index and md-index in model-driven management interfaces.
Classic management interfaces use a numerical index as the primary key for ETH-CFM domains and associations. In model-driven interfaces, domains and associations use string names as keys. The domain and association can optionally be created without having to explicitly select and specify a numerical index in model-driven interfaces. In this case, SR OS assigns an index using the configured index range.
ma-index-range
Syntax
Context
Description
This command specifies the range of indexes used by SR OS to automatically assign an index to ETH-CFM associations that are created in model-driven interfaces without an index explicitly specified by the user or client.
An association created with an explicitly-specified index cannot use an index in this range. In classic CLI and SNMP, the ID range cannot be changed while objects exist inside the previous or new range. In MD interfaces, the range can be changed, which causes any previously existing objects in the previous ID range to be deleted and re-created using a new ID in the new range.
The no form of this command removes the range values.
See the md-auto-id command for further details.
Parameters
md-index-range
Syntax
Context
Description
This command specifies the range of indexes used by SR OS to automatically assign an index to ETH-CFM domains that are created in model-driven interfaces without an index explicitly specified by the user or client.
A domain created with an explicitly-specified index cannot use an index in this range. In classic CLI and SNMP, the ID range cannot be changed while objects exist inside the previous or new range. In MD interfaces, the range can be changed, which causes any previously existing objects in the previous ID range to be deleted and re-created using a new ID in the new range.
The no form of this command removes the range values.
See the md-auto-id command for further details.
Parameters
system
Syntax
Context
Description
This command enables the context to configure Connectivity Fault Management General System parameters.
grace-tx-enable
Syntax
Context
Description
This command enables ETH-CFM grace transmission at the system level when a soft reset message is received and processed by the ETH-CFM module. Individual MEP configuration determines which of the two supported grace functions, ETH-VSM or ETH-ED, is used to announce grace.
This command controls the overall capability to transmit grace and does not control which grace announcement to use. This command also has no impact on the reception and processing of grace-style PDUs.
The no form of this command disables ETH-CFM grace transmission at the system level.
Default
grace-tx-enable
sender-id
Syntax
Context
Description
This command allows the operator to include the configured “system name” (chassis3) or a locally configured value in ETH-CFM PDUs sent from MEPs and MIPs. The operator may only choose one of these options to use for ETH-CFM. MEPs include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs include this value in the LBR and LTR PDUs.
| Note: LBR functions reflect all TLVs received in the LBM unchanged, including the SenderID TLV. |
Parameters
eth-test
Syntax
Context
Description
This command initiates an ETH-CFM test. The implementation supports a single ETH-TST PDU to check unidirectional reachability, launched from a source MEP and terminated on the remote MEP with no response PDU toward the source.
Parameters
linktrace
Syntax
Context
Description
The command initiates a linktrace test.
Parameters
loopback
Syntax
Context
Description
The command initiates a loopback test.
Parameters
one-way-delay-test
Syntax
Context
Description
This command issues an ETH-CFM one-way delay test.
Parameters
two-way-delay-test
Syntax
Context
Description
This command issues an ETH-CFM two-way delay test.
Parameters
two-way-slm-test
Syntax
Context
Description
This command configures an Ethernet CFM two-way SLM test in SAA.
Parameters
alarm-notification
Syntax
Context
Description
This command enables the context to allow configuration of the Fault Notification Generation time values for raising the alarm and resetting the CCM defect alarm. These timers are used for network management processes and are not tied into delaying the notification to the fault management system on the network element. These timers do not affect fault propagation mechanisms.
fng-alarm-time
Syntax
Context
Description
This command is used to configure the Fault Notification Generation time values for raising the alarm. This timer is used for network management processes and is not tied into delaying the notification to the fault management system on the network element. This timer does not affect fault propagation mechanisms.
Parameters
fng-reset-time
Syntax
Context
Description
This command configures the Fault Notification Generation time values to reset the CCM defect alarm. This timer is used for network management processes and is not tied into delaying the notification to the fault management system on the network element. This timer does not affect fault propagation mechanisms.
Parameters
interface-support-enable
Syntax
Context
Description
This command enables the AIS function to consider the operational state of the entity on which it is configured. With this command, ETH-AIS on DOWN MEPs are triggered and cleared based on the operational status of the entity on which it is configured. If CCM is also enabled, then transmission of the AIS PDU is based on either the non-operational state of the entity or on any CCM defect condition. AIS generation ceases if both the operational state is UP and the CCM has no defect conditions. If the MEP is not CCM-enabled then the operational state of the entity is the only consideration, assuming this command is present for the MEP. By default, AIS is not generated or stopped based on the state of the entity on which the DOWN MEP is configured.
The no form of this command disables the AIS function to consider the operational state of the entity on which it is configured.
csf-enable
Syntax
Context
Description
This command enables the context to configure the reception and local processing of ETH-CSF frames.
The no form of this command disables the reception of Client Signal Fail (CSF) message parameters.
multiplier
Syntax
Context
Description
This command configures the multiplication factor applied to the receive time that is used to clear the CSF condition.
The no form of this command disables the multiplier used for timing out CSF.
Parameters
3.14.2.13. BIER OAM Commands
bier-ping
Syntax
Context
Description
This command performs connectivity tests on the BIER data plane.
Parameters
bier-trace
Syntax
Context
Description
This command performs trace tests on the BIER data plane.
Parameters
When the test consists of multiple probes, the timeout is the interval, in seconds, between request probes.
A BIER trace test terminates after five consecutive timeouts.
3.14.2.14. SAA Commands
saa
Syntax
Context
Description
This command creates the context to configure the Service Assurance Agent (SAA) tests.
saa
Syntax
Context
Description
This command starts or stops an SAA test that is not configured as continuous.
Parameters
A test cannot be started if it is in a shut-down state. An error message and log event is generated to indicate a failed attempt to start an SAA test run. A test cannot be started if it is in a continuous state.
gtp-ping
Syntax
Context
Description
This command verifies whether a GTPv2 peer is reachable and correctly responds to GTPv2-C Echo Request messages. This command can be executed if no peering exists for the specified peer.
Parameters
oam-pm
Syntax
Context
Description
This command allows the operator to start and stop on-demand OAM-PM sessions.
Parameters
test
Syntax
Context
Description
This command identifies a test and enables the context to provide the test parameters for the named test. After the creation of the test instance, the test can be started in the OAM context.
A test can only be modified while it is shut down.
The no form of this command removes the test from the configuration. To remove a test, it cannot be active at the time.
Parameters
accounting-policy
Syntax
Context
Description
This command associates an accounting policy to the SAA test. The accounting policy must already be defined before it can be associated otherwise an error message is generated.
A notification (trap) is issued whenever a test is completed or terminates.
The no form of this command removes the accounting policy association.
Parameters
continuous
Syntax
Context
Description
This command specifies whether the SAA test is continuous. Once a test is configured as continuous, it cannot be started or stopped with the oam saa test-name {start | stop} command.
This option is not applicable to all SAA test types. Support is included for the following types:
- cpe-ping
- dns
- eth-cfm-loopback
- eth-cfm-two-way-delay
- eth-cfm-two-way-slm
- icmp-ping (not applicable to rapid type)
- lsp-ping
- mac-ping
- sdp-ping
- vccv-ping
- vrpn-ping
The no form of this command disables the continuous execution of the test.
description
Syntax
Context
Description
This command creates a text description stored in the configuration file for a configuration context.
The description command associates a text string with a configuration context to help identify the content in the configuration file.
The no form of this command removes the string from the configuration.
Parameters
jitter-event
Syntax
Context
Description
This command specifies that at the termination of an SAA test probe, the calculated jitter value is evaluated against the configured rising and falling jitter thresholds. SAA threshold events are generated as required.
Once the threshold (rising/falling) is crossed, it is disabled from generating additional events until the opposite threshold is crossed. If a falling-threshold is not supplied, the rising- threshold is re-enabled when it falls below the threshold after the initial crossing that generated the event.
The configuration of jitter event thresholds is optional.
The no form of the command disables the jitter event.
Parameters
latency-event
Syntax
Context
Description
Specifies that at the termination of an SAA test probe, the calculated latency event value is evaluated against the configured rising and falling latency event thresholds. SAA threshold events are generated as required.
Once the threshold (rising/falling) is crossed, it is disabled from generating additional events until the opposite threshold is crossed. If a falling-threshold is not supplied, the rising- threshold is re-enabled when it falls below the threshold after the initial crossing that generated the event.
The configuration of latency event thresholds is optional.
The no form of this command disables the latency event.
Parameters
loss-event
Syntax
Context
Description
Specifies that at the termination of an SAA test run, the calculated loss event value is evaluated against the configured rising and falling loss event thresholds. SAA threshold events are generated as required.
The configuration of loss event thresholds is optional.
The no form of this command disables the loss-event test run.
Parameters
probe-history
Syntax
Context
Description
Defines history probe behavior. Defaults are associated with various configured parameters within the SAA test. Auto (keep) is used for test with probe counts of 100 or less, and intervals of 1 second and above. Auto (drop) only maintains summary information for tests marked as continuous with file functions, probe counts more than 100 and intervals of less than 1 second. SAA tests that are not continuous with a write to file defaults to Auto (keep). The operator is free to change the default behaviors for each type. Each test that maintains per probe history consumes more system memory. When per probe entries are required, the probe history is available at the completion of the test.
Default
probe-history auto
Parameters
trap-gen
Syntax
Context
Description
This command enables the context to configure trap generation for the SAA test.
probe-fail-enable
Syntax
Context
Description
This command enables the generation of an SNMP trap when the consecutive probe failure threshold (configured using the probe-fail-threshold command) is reached during the execution of the SAA ping test. This command is not applicable to SAA trace route tests.
The no form of this command disables the generation of an SNMP trap.
probe-fail-threshold
Syntax
Context
Description
This command configures the threshold for trap generation after ping probe failure.
This command has no effect when probe-fail-enable is disabled. This command is not applicable to SAA trace route tests.
The no form of this command returns the threshold value to the default.
Default
probe-fail-threshold 1
Parameters
test-completion-enable
Syntax
Context
Description
This command enables the generation of a trap when an SAA test completes.
The no form of this command disables the trap generation.
test-fail-enable
Syntax
Context
Description
This command enables the generation of a trap when a test fails. In the case of a ping test, the test is considered failed (for trap generation) if the number of failed probes is at least the value of the test-fail-threshold parameter.
The no form of this command disables the trap generation.
test-fail-threshold
Syntax
Context
Description
This command configures the threshold for trap generation on test failure.
This command has no effect when test-fail-enable is disabled. This command is not applicable to SAA trace route tests.
The no form of this command returns the threshold value to the default.
Default
test-fail-threshold 1
Parameters
type
Syntax
Context
Description
This command creates the context to provide the test type for the named test. Only a single test type can be configured.
A test can only be modified while the test is in shut down mode.
Once a test type has been configured, the command can be modified by re-entering the command. However, the test type must be the same as the previously entered test type.
To change the test type, the old command must be removed using the config>saa>test>no type command.
The no form of this command removes the test type parameters from the configuration.
cpe-ping
Syntax
Context
Description
This command determines the IP connectivity to a CPE within a specified VPLS service.
Parameters
This variant of the command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic).
id: | 1 to 2147483647 |
svc-name: | up to 64 characters (svc-name is an alias for input only. The svc-name gets replaced with an id automatically by SR OS in the configuration). |
If the interval is set to 1 second where the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
eth-cfm-linktrace
Syntax
Context
Description
This command configures a CFM linktrace test in SAA.
Parameters
eth-cfm-loopback
Syntax
Context
Description
This command configures an Ethernet CFM loopback test in SAA.
Parameters
eth-cfm-two-way-delay
Syntax
Context
Description
This command configures an Ethernet CFM two-way delay test in SAA.
Parameters
eth-cfm-two-way-slm
Syntax
Context
Description
This command configures an Ethernet CFM two-way SLM test in SAA.
Parameters
icmp-ping
Syntax
Context
Description
This command configures an ICMP traceroute test.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
interface | up to 32 characters. This is mandatory for link local addresses. | |
dns-name | up to 128 characters | |
ipv4-address: | a.b.c.d (host bits must be 0) | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
router-name: | Base, management, cmp-vr-name, vpls-management |
vprn-svc-id: | 1 to 2147483647 |
cpm-vr-name: | Up to 32 characters |
The router-instance parameter is preferred for specifying the router or service.
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
icmp-trace
Syntax
Context
Description
This command configures an ICMP traceroute test.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
dns-name | up to 63 characters | |
router-name: | Base, management, vpls-management |
vprn-svc-id: | 1 to 2147483647 |
The parameter router-instance is preferred for specifying the router or service.
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
lsp-ping
Syntax
Context
Description
This command performs in-band LSP connectivity tests.
This command performs an LSP ping using the protocol and data structures defined in the RFC 8029, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.
The LSP ping operation is modeled after the IP ping utility which uses ICMP echo request and reply packets to determine IP connectivity.
In an LSP ping, the originating device creates an MPLS echo request packet for the LSP and path to be tested. The MPLS echo request packet is sent through the data plane and awaits an MPLS echo reply packet from the device terminating the LSP. The status of the LSP is displayed when the MPLS echo reply packet is received.
This command, when used with the static option, performs in-band on-demand LSP connectivity verification tests for static MPLS-TP LSPs. For other LSP types, the static option should be excluded and these are described elsewhere in this user guide.
The lsp-ping static command performs an LSP ping using the protocol and data structures defined in the RFC 8029, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures, as extended by RFC 6426, MPLS On-Demand Connectivity Verification and Route Tracing.
In MPLS-TP, the echo request and echo reply messages are always sent in-band over the LSP, either in a G-ACh channel or encapsulated as an IP packet below the LSP label.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Default
The active LSP path
Values: Any path name associated with the LSP
Parameters
| Note: The rsvp-te explicit target FEC type is not supported under the SAA context. |
ipv4-address: | a.b.c.d | |
ipv4-prefix-length | 0 to 32 | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | a.b.c.d | ||
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x: | [0 to FFFF]H | ||
d: | [0 to 255]D | ||
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | a.b.c.d | ||
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x: | [0 to FFFF]H | ||
d: | [0 to 255]D | ||
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | a.b.c.d | ||
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x: | [0 to FFFF]H | ||
d: | [0 to 255]D | ||
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | - a.b.c.d | ||
ipv6-prefix | - x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x - | [0 to FFFF]H | ||
d - | [0 to 255]D | ||
ipv6-prefix | - x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x - | [0 to FFFF]H | ||
d - | [0 to 255]D | ||
| Note: The sr-policy target FEC type is supported under the OAM context and under type-multi-line node in the SAA context. |
color color-id — Specifies the color ID.
Values 0 to 4294967295
endpoint ip-address — Specifies the endpoint address.
Values
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
segment-list segment-list-id — Specifies the segment list ID.
Values 1 to 32
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified fc and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, The FC and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the FC and profile parameter values determined by the classification of the echo request packet, which is being replied to, at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 32 summarizes this behavior.
Table 32: lsp-ping Request Packet and Behavior
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
The LSP-EXP mappings on the receive network interface controls the mapping of the message reply at the originating router.
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
Output
This sample output is for a LDP IPv4 and IPv6 prefix FECs.
lsp-trace
Syntax
Context
Description
This command performs an LSP traceroute using the protocol and data structures defined in IETF RFC 8029.
The LSP trace operation is modeled after the IP traceroute utility which uses ICMP echo request and reply packets with increasing TTL values to determine the hop-by-hop route to a destination IP.
In an LSP trace, the originating device creates an MPLS echo request packet for the LSP to be tested with increasing values of the TTL in the outermost label. The MPLS echo request packet is sent through the data plane and awaits a TTL exceeded response or the MPLS echo reply packet from the device terminating the LSP. The devices that reply to the MPLS echo request packets with the TTL exceeded and the MPLS echo reply are displayed.
The downstream mapping TLV is used in 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 the LDP FEC an RSVP LSP, or a BGP IPv4 label route.
Two downstream mapping TLVs are supported. The original Downstream Mapping (DSMAP) TLV defined in RFC 4379 (obsoleted by RFC 8029) and the new Downstream Detailed Mapping (DDMAP) TLV defined in RFC 6424 AND RFC 8029. More details are provided in the DDMAP TLV sub-section below.
In addition, when the responder node has multiple equal cost next hops for an LDP FEC, a BGP label IPv4 prefix, an SR-ISIS node SID, an SR-OSPF node SID, or an SR-TE LSP, it replies in the Downstream Mapping TLV with the downstream information for each outgoing interface which is part of the ECMP next-hop set for the prefix. The downstream mapping TLV can further be used to exercise a specific path of the ECMP set using the path-destination option.
This command, when used with the static option, performs in-band on-demand LSP traceroute tests for static MPLS-TP LSPs. For other LSP types, the static option should be excluded and these are described elsewhere in this user guide.
The lsp-trace static command performs an LSP trace using the protocol and data structures defined in the RFC 8029, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures, as extended by RFC 6426, MPLS On-Demand Connectivity Verification and Route Tracing.
In MPLS-TP, the echo request and echo reply messages are always sent in-band over the LSP, either in a G-ACh channel or encapsulated as an IP packet below the LSP label.
The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
| Note: The rsvp-te explicit target FEC type is not supported under the SAA context. |
ipv4-address: a.b.c.d | |
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | |
x: [0 to FFFF]H | |
d: [0 to 255]D | |
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | - a.b.c.d | ||
ipv6-prefix | - x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x - | [0 to FFFF]H | ||
d - | [0 to 255]D | ||
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | a.b.c.d | ||
ipv6-prefix | x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x: | [0 to FFFF]H | ||
d: | [0 to 255]D | ||
<ipv4-prefix>/32 | <ipv6-prefix>/128 | |||
ipv4-prefix | - a.b.c.d | ||
ipv6-prefix | - x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x - | [0 to FFFF]H | ||
d - | [0 to 255]D | ||
ipv6-prefix | - x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | |||
x - | [0 to FFFF]H | ||
d - | [0 to 255]D | ||
| Note: The sr-policy target FEC type is supported under the OAM context and under type-multi-line node in the SAA context. |
color color-id — Specifies the color ID.
Values 0 to 4294967295
endpoint ip-address — Specifies the endpoint address.
Values
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
segment-list segment-list-id — Specifies the segment list ID.
Values 1 to 32
When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the packet EXP is dictated by the LSP-EXP mappings on the outgoing interface.
When the MPLS echo request packet is received on the responding node, The FC and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the fc and profile parameter values determined by the classification of the echo request packet, which is being replied to, at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 33 summarizes this behavior.
Table 33: lsp-trace Request Packet and Behavior
CPM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CPM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
If the interval is set to 1 second, and the timeout value is set to 10 seconds, then the maximum time between message requests is 10 seconds and the minimum is 1 second. This depends upon the receipt of a message reply corresponding to the outstanding message request.
ipv4-address: a.b.c.d | ||
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | ||
x - [0 to FFFF]H | ||
d - [0 to 255]D | ||
Output
mac-ping
Syntax
Context
Description
This command determines the existence of an egress SAP binding of a given MAC within a VPLS service.
A mac-ping is forwarded along the flooding domain if no MAC address bindings exist. If MAC address bindings exist, then the packet is forwarded along those paths, provided they are active. A response is generated only when there is an egress SAP binding for that MAC address or if the MAC address is a “local” OAM MAC address associated with the device’s control plan.
A mac-ping reply can be sent using the data plane or the control plane. The return-control option specifies the reply be sent using the control plane. If return-control is not specified, the request is sent using the data plane.
A mac-ping with data plane reply can only be initiated on nodes that can have an egress MAC address binding. A node without a FDB and without any SAPs cannot have an egress MAC address binding, so it is not a node where replies in the data plane are trapped and sent up to the control plane.
A control plane request is responded to via a control plane reply only.
By default, MAC OAM requests are sent with the system or chassis MAC address as the source MAC. The source option allows overriding of the default source MAC for the request with a specific MAC address.
When a source ieee-address value is specified and the source MAC address is locally registered within a split horizon group (SHG), then this SHG membership is used as if the packet originated from this SHG. In all other cases, SHG 0 (zero) is used. If the mac-trace is originated from a non-zero SHG, such packets do not go out to the same SHG.
Parameters
This variant of the command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic).
id: | 1 to 2147483647 |
svc-name: | up to 64 characters (svc-name is an alias for input only. The svc-name gets replaced with an id automatically by SR OS in the configuration). |
type-multi-line
Syntax
Context
Description
This command creates the context to configure the OAM probe type and its parameters in a flexible multi-line format.
The no form of this command removes the context.
lsp-ping
Syntax
Context
Description
This command creates the context to configure the lsp-ping OAM probe type.
sr-policy
Syntax
Context
Description
This command configures the SR policy target FEC.
| Note: The sr-policy target FEC type is supported under the OAM context and under type-multi-line node in the SAA context. |
Parameters
ipv4-address: a.b.c.d | ||
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | ||
x - [0 to FFFF]H | ||
d - [0 to 255]D | ||
fc
Syntax
Context
Description
This command specifies the FC and profile parameters that are used to indicate the forwarding class and profile of the MPLS echo request packet.
The no form of this command reverts to the default value.
Default
fc be
Parameters
interval
Syntax
Context
Description
This command configures the number of seconds to override the default request message send interval and defines the minimum amount of time that must expire before the next message request is sent.
The no form of this command reverts to the default value.
Default
interval 1
Parameters
path-destination
Syntax
Context
Description
This command configures the IP address of the path destination from the range 127/8. When the LDP FEC prefix is IPv6, the user must enter a 127/8 IPv4 mapped IPv6 address, that is, in the range ::ffff:127/104.
The no form of this command removes the configuration.
Parameters
ipv4-address: a.b.c.d | ||
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | ||
x - [0 to FFFF]H | ||
d - [0 to 255]D | ||
profile
Syntax
Context
Description
This command configures the profile state of the MPLS echo request packet.
The no form of this command reverts to the default value.
Default
profile out
Parameters
segment-list
Syntax
Context
Description
This command configures the segment list ID.
The no form of this command removes the configuration.
Parameters
send-count
Syntax
Context
Description
This command configures the number of messages to send. The send-count value is used to override the default number of message requests sent. Each message request must either time out or receive a reply before the next message request is sent. The message interval value must be expired before the next message request is sent.
The no form of this command reverts to the default value.
Default
send-count 1
Parameters
size
Syntax
Context
Description
This command configures the MPLS echo request packet size.
The no form of this command reverts to the default value.
Default
size 1
Parameters
src-ip-address
Syntax
Context
Description
This command configures the source IP address. This option is used when an OAM packet must be generated from a different address than the node’s system interface address. For example, when the OAM packet is sent over an LDP LSP and the LDP LSR-ID of the corresponding LDP session to the next hop is set to an address other than the system interface address.
The no form of this command removes the configuration.
Parameters
ipv4-address: a.b.c.d | ||
ipv6-address: x:x:x:x:x:x:x:x (eight 16-bit pieces) | ||
x:x:x:x:x:x:d.d.d.d | ||
x - [0 to FFFF]H | ||
d - [0 to 255]D | ||
timeout
Syntax
Context
Description
This command configures the number, in seconds, used to override the default timeout value and is the amount of time that the router waits for a message reply after sending the last probe for a specific test. Upon the expiration of the time out, the test is marked complete and no more packets are processed for any of the request probes.
The no form of this command reverts to the default value.
Default
timeout 5
Parameters
ttl
Syntax
Context
Description
This command configures a time-to-live value for the MPLS label.
The no form of this command reverts to the default value.
Default
ttl 255
Parameters
lsp-trace
Syntax
Context
Description
This command creates the context to perform an LSP traceroute using the protocol and data structures defined in IETF RFC 4379.
downstream-map-tlv
Syntax
Context
Description
This command configures the downstream mapping TLV that provides 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 the LDP FEC an RSVP LSP, or a BGP IPv4 label route.
The following downstream mapping TLVs are supported: the original Downstream Mapping (DSMAP) TLV defined in RFC 4379 and the Downstream Detailed Mapping (DDMAP) TLV defined in RFC 6424.
The no form of this command removes the configuration.
Parameters
max-fail
Syntax
Context
Description
This command configures the maximum number of consecutive MPLS echo requests that do not receive a reply before the trace operation fails for a TTL.
The no form of this command reverts to the default value.
Default
max-fail 5
Parameters
probe-count
Syntax
Context
Description
This command configures the number of probes per hop.
The no form of this command reverts to the default value.
Default
probe-count 1
Parameters
timeout
Syntax
Context
Description
This command configures the time, in seconds, used to override the default timeout value and is the amount of time that the router waits for a message reply after sending the message request. Upon the expiration of the message time out, the requesting router assumes that the message response is not received. A request timeout message is displayed by the CLI for each message request sent that expires. Any response received after the request times out is silently discarded.
The no form of this command reverts to the default value.
Default
timeout 3
Parameters
ttl
Syntax
Context
Description
This command configures minimum and maximum time-to-live values.
The no form of this command removes the configuration.
Parameters
3.14.2.15. OAM Performance Monitoring, Bin Group, and Session Commands
3.14.2.15.1. Bin Group Commands
oam-pm
Syntax
Context
Description
This is the top level context that contains the configuration parameters that defines storage parameters (including binning structures), availability/resiliency and the individual proactive, and on-demand tests used to gather the performance/statistical information.
bin-group
Syntax
Context
Description
This command allows the operator to configure the parameters for a specific bin group. Bin-group 1 is a default bin-group and cannot be modified. If no bin group is assigned to an oam-pm session, this is assigned by default. The default values for bin-group 1 are (fd-bin-count 3 bin 1 lower-bound 5000us, bin 2 lower-bound 10000us fdr-bin-count 2 bin 1lower-bound 5000us and ifdv-bin-count 2 bin 1lower-bound 5000us)
The no form of this command disables the OAM Performance Monitoring bin group.
Parameters
bin-type
Syntax
Context
Description
This command is the start of the hierarchy where the specific delay metric bin structure isis defined.
Parameters
bin
Syntax
Context
Description
This command enables the context to configure the thresholds for the specified bin.
Parameters
lower-bound
Syntax
Context
Description
This command allows the operator specify the individual floors thresholds for the bins. The operator does not have to specific a lower threshold for every bin that was previously defined by the bin-count for the specific type. By default, each bin is the bin-number times 5000 microseconds. Lower thresholds in the previous adjacent bin must be lower than the threshold of the next higher bin threshold. A separate line per bin is required to configure an operator-specific threshold. An error prevents the bin from entering the active state if this is not maintained, at the time the no shutdown is issued. Bin 0 is the result of the difference between 0 and the configured lower-threshold of bin 1. The highest bin in the bin-count captures every result above the threshold. Any negative delay metric result is treated as zero and placed in bin 0.
The no form of this command removes the user configured threshold value and applies the default for the bin.
Parameters
delay-event
Syntax
Context
Description
This command sets the bin number, the threshold and the direction that is monitored to determine if a delay metric threshold crossing event has occurred or has cleared. It requires a bin number, a rising threshold value and a direction. If the clear-threshold value is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and without regard to any previous window. When a raise threshold is reached, the log event is generated. Each unique threshold can only be raised once for the threshold within measurement interval. If the optional clear threshold is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is not raised until a measurement interval completes, and the clear threshold has not been exceeded. A clear event is raised under that condition. In general, alarms are generated when there is a state change. The thresholds configured are applied to the count in specified bin and all higher number bins.
The no form of this command removes thresholding for this delay metric. The complete command must be configured in order to remove the specific threshold.
Parameters
delay-event-exclusion
Syntax
Context
Description
This optional command allows results from probes that map to the specified bin and higher bins to be excluded from the TCA count. The TCA count is used to determine if a threshold has been reached by the event monitoring function. Individual counters are incremented in the bin, but the counts in the specified bin and higher bins are not included in the TCA threshold computation. A delay-event must be configured in the same direction, and the lowest-bin configured as part of the delay-event-exclusion command must be higher than the lowest bin specified by the corresponding delay-event command.
The bin group allows this optional command to be added, modified, or deleted while tests are actively referencing the bin group. The bin group does not need to be shut down during delay-event-exclusion configuration. If the values are modified while the active tests are executing, all configured TCAs for the specified direction within the bin group enters a pending (p) state until the start of the next measurement interval. Any existing stateful TCAs that were raised are cleared without creating a log event, and no further processing for the affected TCAs occur in the active window. Depending on timing, the pending state may continue past the adjacent measurement interval until the start of the following measurement interval.
The no form of this command does not exclude any values from the configured TCA threshold.
Default
no delay-event-exclusion forward
no delay-event-exclusion backward
no delay-event-exclusion round-trip
Parameters
exclude-from-avg
Syntax
Context
Description
This optional command allows the results from probes that map to the specified bins within the bin type to be excluded from the average calculation. Individual counters are incremented in the bin, but the average is not affected by the value of the excluded delay metric for the individual probes in this bin. The bin group does not allow this command to be added, modified, or deleted when a test is actively referencing the bin group. Sessions that reference the bin group must have the bin group and tests shut down before changes can be made.
The no form of this command removes the exclusion, and all bins are included in the average calculation.
Default
no exclude-from-avg forward
no exclude-from-avg backward
no exclude-from-avg round-trip
Parameters
A hyphen can be entered between bin numbers to include a continuous sequence of bins; for example, entering 7-9 would specify bins 7, 8, and 9. Commas can be entered between bin numbers to include separate or non-continuous bins; for example, entering 0,8,9 would specify bins 0, 8, and 9. Both hyphens and commas can be used in this manner in the same configuration; for example, entering 0,7-9 would include bins 0, 7, 8, and 9. All bin numbers specified as part of this command must be configured. If a specified bin does not exist, the command fails.
session
Syntax
Context
Description
This command creates the individual session containers that houses the test specific configuration parameters. Since this session context provides only a container abstract to house the individual test functions, it cannot be shut down. Individual tests sessions within the container may be shut down. No values, parameters, or configuration within this context may be changed if any individual test is active. Changes may only be made when all tests within the context are shut down. The only exception to this is the description value.
The no form of this command deletes the session.
Parameters
bin-group
Syntax
Context
Description
This command links the individual test to the group of bins that map the probe responses.
The no form of this command installs the default bin-group 1 as the bin-group for the session.
Parameters
meas-interval
Syntax
Context
Description
This command establishes the parameters of the individual measurement intervals utilized by the session. Multiple measurement intervals may be specified within the session. A maximum of three different measurement intervals may be configured under each session.
The no form of this command deletes the specified measurement interval.
Parameters
accounting-policy
Syntax
Context
Description
This optional command allows the operator to assign an accounting policy and the policy-id (configured under the config>log>accounting-policy) with a record-type of complete-pm. This runs the data collection process for completed measurement intervals in memory, file storage, and maintenance functions moving data from memory to flash. A single accounting policy can be applied to a measurement interval.
The no form of this command removes the accounting policy.
Parameters
boundary-type
Syntax
Context
Description
This command establishes the alignment of the start of the measurement interval with either the time of day clock or the start of the test. Alignment with the time of day clock always defaults to the representative top of the hour. Clock-aligned 15-minute measurement intervals divide the hour into four equal sections 00, 15, 30, 45. Clock-aligned 1-hour measurement intervals start at 00. Clock-aligned 1-day measurement intervals start at midnight. Test relative start times launches the measurement interval when the individual test enters the active (no shutdown) state. It is typical for the first measurement interval of a clock-aligned test to have the suspect flag set to yes because it is unlikely the no shutdown exactly corresponds to the clock based measurement interval start time. Clock-aligned measurement intervals can include an additional offset.
The no form of this command sets the boundary to the default clock-aligned.
Default
boundary-type clock-aligned
Parameters
clock-offset
Syntax
Context
Description
This command allows measurement intervals with a boundary-type of clock aligned to be offset from the default time of day clock. The configured offset must be smaller than the size of the measurement interval. As an example, an offset of 120 (seconds) shifts the start times of the measurement intervals by two minutes from their default alignments with respect to the time of day clock.
The no form of this command sets the offset to 0.
Default
clock-offset 0
Parameters
event-mon
Syntax
Context
Description
This command enables the different threshold events on a specific measurement interval. Only one measurement interval with a configured OAM PM session can have events enabled using the no shutdown command.
delay-events
Syntax
Context
Description
This enables the monitoring of all configured delay events. Adding this functionality starts the monitoring of the configured delay events at the start of the next measurement interval. If the function is removed using the no command, all monitoring of configured delay events, logging, and recording of new events for that session are suspended. Any existing events at the time of the shut down are maintained until the active measurement window in which the removal was performed has completed. The state of this monitoring function can be changed without having to shutdown all the tests in the session.
The no form of this command disables the monitoring of all configured delay events.
loss-events
Syntax
Context
Description
This enables the monitoring of all configured loss events. Adding this functionality starts the monitoring of the configured loss events at the start of the next measurement interval. If the function is removed using the no command, all monitoring of configured loss events, logging, and recording of new events for that session are suspended. Any existing events at the time of the shut down are maintained until the active measurement window in which the removal was performed has completed. The state of this monitoring function can be changed without having to shut down all the tests in the session.
The no form of this command diables the monitoring of all configured loss events.
intervals-stored
Syntax
Context
Description
This command defines the number of completed measurement intervals per session to be stored in volatile system memory. The entire block of memory is allocated for the measurement interval when the test is active (no shutdown) to ensure memory is available. The numbers are increasing from 1 to the configured value + 1. The active pm data is stored in the interval number 1 and older runs are stored, in order, to the upper most number with the oldest rolling off when the number of completed measurement intervals exceeds the configured value+1. As new test measurement intervals complete for the session, the stored intervals are renumbered to maintain the described order. Use caution when setting this value. There must be a balance between completed runs stored in volatile memory and the use of the write-to-flash function of the accounting policy.
The 5-mins and 15-mins measurement intervals share the same (1 to 96) retention pool. In the event that both intervals are required, the sum total of both intervals cannot exceed 96. The 1-hour and 1-day measurement intervals utilize their own ranges.
If this command is omitted when configuring the measurement interval, the default value is used.
The no form of the command reverts to the default.
Default
intervals-stored 1
Parameters
3.14.2.15.2. Session Ethernet Commands
ethernet
Syntax
Context
Description
This command enables the context to configure the Ethernet specific source and destination information, the priority, and the Ethernet tests tools on the launch point.
dest-mac
Syntax
Context
Description
This command defines the destination MAC address of the peer MEP and sets the destination MAC address in the layer two header to match. This must be a unicast address.
The no form of this command removes session parameter.
Parameters
dmm
Syntax
Context
Description
This command defines the test ID to be assigned to the delay test and creates the container to allow the individual test parameters to be configured.
The no form of this command removes the DMM test function from the PM Session.
Parameters
data-tlv-size
Syntax
Context
Description
This command allows the operator to add an optional Data TLV to PDU and increase the frame on the wire by the specified amount. Note that this command only configures the size of the padding added to the PDU, and does not configure the total size of the frame on the wire.
The no form of this command removes the optional TLV.
Parameters
delay-template
Syntax
Context
Description
This command specifies a reference to a config>oam-pm>streaming>delay-template for the Ethernet DMM test. It is possible to include a delay template reference that is not configured under config>oam-pm>streaming. In this case, streaming of results are not in effect. Refer to delay-template command for session to template interaction behaviors.
The no form of this command deletes the delay template from the test.
Default
no delay-template
Parameters
interval
Syntax
Context
Description
This command defines the message period or probe spacing for the transmission of the DMM or LMM frame.
The no form of this command sets the interval to the default. If an LMM test is in no shutdown state, it always has timing parameters, whether default or operator configured.
Parameters
test-duration
Syntax
Context
Description
This optional command defines the length of time the test runs before stopping automatically. This command is only a valid option when a session has been configured with a session-type of on-demand. This is not an option when the session-type is configured as proactive. On-demand tests do not start until the config>oam-pm>session>start command has been issued and they stop when the config>oam-pm>session>stop command is issued.
The no form of this command removes a previously configured test-duration and allow the test to run until manually stopped.
Parameters
lmm
Syntax
Context
Description
This command defines the test ID to be assigned to the Tx and Rx counter-based loss test and creates the individual test. LMM does not carry this test-id in the PDU; the value is of local significance.
The no form of this command removes the LMM test function from the PM Session.
Parameters
availability
Syntax
Context
Description
This command enables the context to activate, collect, and record availability statistics for LMM tests. These computations are not enabled by default. In order to modify parameters within a session, including these availability parameters, the LMM test must be shut down.
flr-threshold
Syntax
Context
Description
This command defines the frame loss threshold used to determine whether the delta-t is available or unavailable. An individual delta-t with a frame loss threshold equal to the configured threshold is marked unavailable. An individual delta-t with a frame loss threshold lower than the configured threshold is marked as available.
The no form of this command restores the default value of 50%.
Parameters
hli-force-count
Syntax
Context
Description
This command allows High Loss Interval (HLI) and Consecutive High Loss Interval (CHLI) counters to increment regardless of availability. Without this command, HLI and CHLI counters can only increment during times of availability, which includes undetermined availability. During times of complete packet loss, the forward direction HLI is marked as high loss. The backward direction is not marked as high loss during times of complete packet loss.
The no form of this command configures HLI and CHLI counters to increment during times of availability only.
timing
Syntax
Context
Description
This command defines various availability parameters for LMM availability testing. This command does not define the probe interval. Validation occurs when the LMM test is activated using the no shutdown command. The maximum size of the availability window cannot exceed 100 seconds (100 000 milliseconds). LMM test activation fails if the availability window exceeds the maximum value.
The no form of this command restores the default values for all timing parameters, and uses those values to compute availability and set the loss frequency.
Parameters
enable-fc-collection
Syntax
Context
Description
This command enables the ETH-LMM test within the OAM-PM session to collect per-FC counters. This command must be used in combination with the collect-lmm-fc-stats command for the entity over which the source MEP is defined. The config>oam-pm>session>ethernet>priority value must match the numerical value that represents the FC name (7 = NC, 6 = H1, 5 = EF, 4 = H2, 3 = L1, 2 = AF, 1 = L2, 0 = BE).
The OAM-PM infrastructure does not validate that the proper counting mode has been configured on the entity that is linked to the source MEP, and does not validate that the FC and priority have been configured. The show>eth-cfm>collect-lmm-fc-stats command may be used to display the entities and the FCs on those entities that have established individual FC counters.
Sessions that launch from the same source MEP must use the same counting model; either collect-lmm-fc-stats for individual counters for the defined FCs, or collect-lmm-stats for a single all-encompassing counter.
Individual OAM-PM sessions must be configured if multiple Ethernet LMM tests are required for different FCs. Cross-session validation occurs to ensure that a source MEP does not include multiple tests that are using the same priority.
The no form of this command removes all previously defined FCs and stops counting for those FCs.
loss-events
Syntax
Context
Description
This context allows the operator to define the loss events and thresholds that are to be tracked.
avg-flr-event
Syntax
Context
Description
This command sets the frame loss ratio threshold configuration to be applied and checked at the end of the measurement interval for the specified direction. This is a percentage based on average frame loss ratio over the entire measurement interval. If the clear-threshold-percent value is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and without regard to any previous window. Each unique event can only be raised once within measurement interval. If the optional clear-threshold-percent value is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is not raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.
The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no avg-flr-event forward
no avg-flr-event backward
Parameters
chli-event
Syntax
Context
Description
This command sets the consecutive high loss interval (CHLI) threshold to be monitored and the associated thresholds using the counter of the specified direction. The aggregate is a function of summing forward and backward. This value is only used as a threshold mechanism and is not part of the stored statistics. If the optional clear clear-threshold parameter is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and regardless of any previous window. Each unique event can only be raised once within measurement interval. If the optional clear clear-threshold parameter is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.
The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no chli-event forward
no chli-event backward
no chli-event aggregate
Parameters
hli-event
Syntax
Context
Description
This command sets the high loss interval (HLI) threshold to be monitored and the associated thresholds using the counter of the specified direction. The aggregate is a function of summing forward and backward. This value is only used as a threshold mechanism and is not part of the stored statistics. If the optional clear clear-threshold parameter is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and regardless of any previous window. Each unique event can only be raised once within measurement interval. If the optional clear clear-threshold parameter is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.
The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no hli-event forward
no hli-event backward
no hli-event aggregate
Parameters
unavailability-event
Syntax
Context
Description
This command sets the threshold to be applied to the overall count of the unavailability indicators, not transitions, per configured direction. This value is compared to the 32 bit unavailability counter specific to the direction which tracks the number of individual delta-ts that have been recorded as unavailable. The aggregate is a function of summing forward and backward. This value is only used as a threshold mechanism and is not part of the stored statistics. If the optional clear clear-threshold parameter is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and regardless of any previous window. Each unique event can only be raised once within measurement interval. If the optional clear clear-threshold parameter is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.
The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no unavailability-event forward
no unavailability-event backward
no unavailability-event aggregate
Parameters
undet-availability-event
Syntax
Context
Description
This command sets the threshold to be applied to the overall count of the undetermined availability indicators, not transitions, per configured direction. This value is compared to the 32 bit unavailability counter specific to the direction which tracks the number of individual delta-ts that have been recorded as undetermined available. The aggregate is a function of summing forward and backward. This value is only used as a threshold mechanism and is not part of the stored statistics. If the optional clear clear-threshold parameter is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and regardless of any previous window. Each unique event can only be raised once within measurement interval. If the optional clear clear-threshold parameter is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.
The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no undet-availability-event forward
no undet-availability-event backward
no undet-availability-event aggregate
Parameters
undet-unavailability-event
Syntax
Context
Description
This command sets the threshold to be applied to the overall count of the undetermined unavailability indicators, not transitions, per configured direction. This value is compared to the 32 bit unavailability counter specific to the direction which tracks the number of individual delta-ts that have been recorded as undetermined unavailable. The aggregate is a function of summing forward and backward. This value is only used as a threshold mechanism and is not part of the stored statistics. If the clear clear-threshold parameter is not specified the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and without regard to any previous window. Each unique event can only be raised once within measurement interval. If the optional clear threshold is specified the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is not raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.
The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no undet-unavailable-event forward
no undet-unavailable-event backward
no undet-unavailable-event aggregate
Parameters
priority
Syntax
Context
Description
This command defines the CoS priority across all tests configured under this session. This CoS value is exposed to the various QoS policies the frame passes through and does not necessarily map directly to the CoS value on the wire.
The no form of this command removes changes the priority to the default value.
Default
priority 0
Parameters
remote-mepid
Syntax
Context
Description
This command specifies the remote MEP ID as an alternative to the static dest-mac ieee-address. When the remote-mepid option is configured as an alternative to the dest-mac, the domain and association information of the source mep within the session is used to check for a locally-stored unicast MAC address for the peer. The local MEP must be administratively enabled. Peer MEP MAC addresses are learned and maintained by the ETH-CC protocol.
The no form of this command removes this session parameter.
Parameters
slm
Syntax
Context
Description
This command defines the test ID to be assigned to the synthetic loss test and creates the container to allow the individual test parameters to be configured.
The no form of this command removes the SLM test function from the PM Session.
Parameters
timing
Syntax
Context
Description
This command defines various availability parameters and the probe spacing (interval) for the SLM frames. The maximum size of the availability window cannot exceed 10 s (10 000 ms).
The no form of this command installs the default values for all timing parameters and use those values to compute availability and set the SLM frequency. If an SLM test is in the no shutdown state, it always has timing parameters, default or operator configured.
Parameters
source
Syntax
Context
Description
This command defines the source launch point identification Y.1731 parameters that are used by the individual tests within the session. If an MEP matching the configuration does not exist, the session is allowed to become active, however the frames sent frames and received as seen under the show >oam-pm>statistics>session session-name command is zero. The preferred reference to the MEP launch point is by admin-name. Therefore, the syntax source mep mep-id domain-name admin-name association-name admin-name should be used.
The no form of this command removes this session parameter.
Parameters
3.14.2.15.3. Session IP Commands
ip
Syntax
Context
Description
This command enables the context to configure the IP-specific source and destination information, the priority, and the IP test tools on the launch point.
allow-egress-remark-dscp
Syntax
Context
Description
This command instructs the egress QoS process to modify the DSCP based on the egress QoS configuration. This command exposes the DSCP to egress DSCP processing rules.
The no form of this command instructs the egress QoS process to ignore the DSCP and allow it to bypass egress QoS. If the config>qos>network>egress>remark force command is configured for the network egress QoS profile, the egress QoS process is applied and the DSCP can be overwritten regardless of the allow-egress-remark-dscp configuration.
dest-udp-port
Syntax
Context
Description
This command defines the destination UDP port on outbound TWAMP Light packets sent from the session controller. The destination UDP port must match the UDP port value configured on the TWAMP Light reflector that is responding to this specific TWAMP Light test.
The no form of this command removes the destination UDP port setting.
Parameters
destination
Syntax
Context
Description
This command defines the destination IP address that is assigned to the TWAMP Light packets. The destination address must be included in the prefix list on the session reflector within the configured context in order to allow the reflector to process the inbound TWAMP Light packets.
The no form of this command removes the destination parameters.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
do-not-fragment
Syntax
Context
Description
This command configures the Do Not Fragment (DF) bit in the IPv4 header of the TWAMP Light test packet in order to prevent packet fragmentation. This is only applicable to IPv4. IPv6 does not include the bit as part of the specification. This parameter is ignored but not blocked when the address is IPv6.
The no form of this command allows packet fragmentation.
dscp
Syntax
Context
Description
This command can be used to explicitly configure the DSCP value to the specified dscp-name, or to use the configured fc and profile values to derive the DSCP value from the egress network QoS policy 1.
Default
dscp resolve
Parameters
fc
Syntax
Context
Description
This command sets the forwarding class designation for TWAMP Light packets that are sent through the node and exposed to the various QoS functions on the network element.
The no form of this command restores the default value.
Default
fc be
Parameters
forwarding
Syntax
Context
Description
This command influences the forwarding decision of the TWAMP Light packet. When this command is used, only one of the forwarding options can be enabled at any time.
The no form of this command removes the options and enables the default forwarding logic.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
pattern
Syntax
Context
Description
This command configures the pattern value to be repeated in the padding portion of the TWAMP Light packet.
The no form of this command uses an incrementing byte pattern beginning with 00 and ending with FF, wrapping back to 00.
Default
pattern 0
Parameters
profile
Syntax
Context
Description
This command defines whether the TWAMP Light PDU packet should be treated as in-profile or out-of-profile. The default has been selected because the forwarding class defaults to best effort.
The no form of this command restores the default value.
Default
profile out
Parameters
router
Syntax
Context
Description
This command numerically references the source context from which the TWAMP Light packet is launched. The router-instance router-instance configuration, under the same context as the router command, is the preferred method for referencing. This method references the launch context by name, and not number, or alias that converts service-name to a number.
The no form of this command restores the default value.
Parameters
router-name: | Base |
vprn-svc-id: | 1 to 2147483647 |
router-instance
Syntax
Context
Description
This command references the source context from which the TWAMP Light packet is launched by name. The router-instance router-instance configuration is the preferred method for referencing and references the launch context by name, not number or alias that converts service-name to a number.
The no form of this command restores the default value.
Parameters
source
Syntax
Context
Description
This command defines the source IP address that the session controller (launch point) uses for the test. The source address must be a local resident IP address in the context; otherwise, the response packets are processed by the TWAMP Light application. Only source addresses configured as part of TWAMP tests can process the reflected TWAMP packets from the session reflector.
The no form of this command removes the source address parameters.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
source-udp-port
Syntax
Context
Description
This command should only be used if a TWAMP Client is used to establish a TCP connection and communicate the test parameters to a TWAMP Server over TWAMP TCP Control and the test is launched from OAM-PM (Session-Sender). This command should not be used when the reflection point is a TWAMP Light reflector that does not require TCP TWAMP Control. When this command is included, the source UDP range is restricted. When this command is omitted, the source UDP port is dynamically allocated by the system.
The no form of this command removes the source UDP port setting when the default allocation is used.
Parameters
ttl
Syntax
Context
Description
This command defines the value of the TTL field of the packet header.
The no form of this command restores the default value.
Default
ttl 225
Parameters
twamp-light
Syntax
Context
Description
This command assigns an identifier to the TWAMP Light test and creates the individual test.
The no form of this command removes the TWAMP Light test function from the OAM-PM session.
Parameters
delay-template
Syntax
Context
Description
This command specifies a reference to a config>oam-pm>streaming>delay-template for the IP TWAMP LIGHT test. It is possible to include a delay template reference that is not configured under config>oam-pm>streaming. In this case, streaming of results are not in effect. Refer to delay-template command for session to template interaction behaviors.
The no form of this command deletes the delay template from the test.
Default
no delay-template
Parameters
interval
Syntax
Context
Description
This command defines the message period, or probe spacing, for transmitting a TWAMP Light frame.
The no form of this command sets the interval to the default value.
Default
interval 1000
Parameters
loss
Syntax
Context
Description
This command enables the context to configure loss parameters for the TWAMP-Light test.
flr-threshold
Syntax
Context
Description
This command defines the frame loss threshold used to determine whether the delta-t is available or unavailable. An individual delta-t with a frame loss threshold equal to or higher than the configured threshold is marked unavailable. An individual delta-t with a frame loss threshold lower than the configured threshold is marked as available.
The no form of this command restores the default value of 50%.
Default
flr-threshold 50
Parameters
hli-force-count
Syntax
Context
Description
This command allows High Loss Interval (HLI) and Consecutive High Loss Interval (CHLI) counters to increment regardless of availability. Without this command, HLI and CHLI counters can only increment during times of availability, which includes undetermined availability. During times of complete packet loss, the forward direction HLI is marked as high loss. The backward direction is not marked as high loss during times of complete packet loss.
The no form of this command configures HLI and CHLI counters to increment during times of availability only.
timing
Syntax
Context
Description
This command defines various availability parameters but not the probe interval. A single TWAMP-Light frame is used to collect both delay and loss metrics; the interval is common to both and as such not unique per metric type. Any TWAMP light test that is attempting to become active validates the configuration of the timing parameter regardless of which statistics are being recorded.
The no form of this command restores the default values for all timing parameters and use those values to compute availability and set the loss frequency.
Default
timing frames-per-delta-t 1 consec-delta-t 10 chli-threshold 5
Parameters
pad-size
Syntax
Context
Description
This command defines the amount by which the TWAMP Light packet is padded. TWAMP session controller packets are 27 bytes smaller than TWAMP session reflector packets. If symmetrical packet sizes in the forward and backward direction are required, the pad size must be configured to a minimum of 27 bytes.
The no form of this command removes all padding.
Default
pad-size 0
Parameters
record-stats
Syntax
Context
Description
This option provides the ability to determine which statistics are recorded. The TWAMP-Light PDU can report on both delay and loss using a single packet. The operator may choose which statistics they would like to report. Only delay recording is on by default. All other metrics are ignored. In order to change what is being recorded and reported, the TWAMP-Light session must be shutdown. This is required because the single packet approach means the base statistics are shared between the various datasets. Issuing a no shutdown command clears previous all non-volatile memory for the session and allocate new memory blocks. All the parameters under this context are mutually exclusive.
The no version of the command restores the default “delay” only.
Default
record-stats delay
Parameters
test-duration
Syntax
Context
Description
This command defines the length of time the test runs before stopping automatically. This optional command is only valid when a session has been configured with a session-type of on-demand. This is not an option when the session-type is configured as proactive. On-demand tests do not start until the config>oam-pm>session>start command has been issued and they stop when the config>oam-pm>session>stop command is issued.
The no form of this command removes a previously configured test-duration value and allows the TWAMP Light test to execute until it is stopped manually.
Parameters
3.14.2.15.4. Session MPLS Commands
mpls
Syntax
Context
Description
This command enables the context to configure MPLS-specific source and destination, LSP type and tunnel information, the priority, and the MPLS DM test configuration on the launch point.
dm
Syntax
Context
Description
This command assigns an identifier to the DM test and creates the individual test.
The no form of this command removes the DM test function from the OAM-PM session.
Parameters
delay-template
Syntax
Context
Description
This command specifies a reference to a config>oam-pm>streaming>delay-template for the MPLS DM test. It is possible to include a delay template reference that is not configured under config>oam-pm>streaming. In this case, streaming of results are not in effect. Refer to delay-template command for session to template interaction behaviors.
The no form of this command deletes the delay template from the test.
Default
no delay-template
Parameters
interval
Syntax
Context
Description
This command defines the message period, or probe spacing, to transmit a DM frame.
The no form of this command sets the interval to the default value.
Parameters
pad-tlv-size
Syntax
Context
Description
This command allows the operator to add an optional Pad TLV to PDU and increase the frame on the wire by the specified amount. Note that this command only configures the size of the padding added to the PDU, and does not configure the total size of the frame on the wire. Since the bit count for the length is a maximum of 255 (8bits) the maximum pad per pad-tlv is between 0, 2 and 257 (type 1B, Length 1B, Length 255). Only a single pad-tlv can be added.
The no form of this command removes the optional TLV.
Parameters
reflect-pad
Syntax
Context
Description
This command enables copying the padding in each MPLS-DM query to the response.
When padding is included in the DM frame the option exists to reflect the padding back in the direction of the source or remove the padding. The removal of the pad-tlv is good practice when using unidirectional tunnels such as RSVP.
This command uses the mandatory TLV type 0, instructing the responder to include the pad TLV from the response. The no form of this command uses the optional TVL type 128, instructing the responder to remove the pad TLV from the response.
The no form of this command disables copying the padding in each MPLS-DM query to the response.
test-duration
Syntax
Context
Description
This command defines the length of time the test runs before stopping automatically. This command is only valid when a session has been configured with a session-type of on-demand. This is not an option when the session-type is configured as proactive.
On-demand tests do not start until the oam-pm>session>start command has been issued and they stops when scheduled or the oam-pm>session>stop command is issued.
The no form of this command removes a previously configured test-duration and allow the test to run until manually stopped.
Parameters
dscp
Syntax
Context
Description
This command can be used to explicitly configure the DSCP value that is carried in the DM PDU. This value is not used on the launch point or the reflector to influence the QoS behavior on the network elements. The frame itself has no IP information because it uses the General Associated Channel Header (G-Ach). The fc and profile values are used to influence QoS behavior on the launch point and the responder.
The no form of this command reverts the dscp carried in the DM PDU to default.
Default
dscp be
Parameters
fc
Syntax
Context
Description
This command sets the forwarding class designation for DM packets sent through the node and exposed to the various QoS functions on the network element.
The no form of this command reverts the default value.
Default
fc be
Parameters
mpls-tp-static
Syntax
Context
Description
This command enables the context to configure an MPLS TP LSP and its attributes to be tested.
lsp
Syntax
Context
Description
This command enables the context to define the type of label switched path and the identification of the LSP for which packets traverse. Only a single LSP can be configured per session. Once an LSP has been configured, other LSP types under this context is blocked.
The no form of this command deletes the configured LSP under the context, when there are no active tests are executing under this session.
lsp
Syntax
Context
Description
This command specifies the MPLS LSP to be tested.
Parameters
rsvp
Syntax
Context
Description
This command enables the context to configure an RSVP LSP and its attributes to be tested.
udp-return-object
Syntax
Context
Description
This command configures the destination IP address used by the far end of the test to send a test response. The UDP port in the UDP-Return Object is set to 64353 for MPLS DM PDUs.RSVP tunnels are unidirectional and must include a configured local address for the responder can route the response back by the IP control plane. If the configuration is absent, the DN test fails to activate. If the configured IP address is not a local address, the command fails.
The no form of this command removes the udp-return-object IP address.
Parameters
ipv4-address -a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x: [0..FFFF]H | |
d: [0..255]D | |
rsvp-auto
Syntax
Context
Description
This command enables the context to configure the RSVP auto LSP and its attributes for testing.
from
Syntax
Context
Description
One of three mandatory configuration statements that are required to identify automatically create RSVP LSPs, created using config>router>mpls>lsp-template. The config>router>mpls>auto-lsp lsp-template links three distinct functions. The config>router>policy-options>prefix-list, config>router>policy-options>policy-statement>entry>from and config>router>mpls> lsp-template. The from address under the test context is the same as the config>router>mpls>lsp-template>from address.
The three required identifiers are from, lsp-template and to, all under this container.
The no form of this command deletes the IP address from the configuration.
Parameters
lsp-template
Syntax
Context
Description
This command specifies the LSP template used to identify the LSP for testing.
One of three mandatory configuration statements that are required to identify automatically created RSVP LSPs, created using config>router>mpls>lsp-template. The config>router>mpls>auto-lsp>lsp-template links three distinct functions.The lsp-template template-name must match the name of config>router>mpls>lsp-template used to dynamically create the RSVP LSP. This is a lose reference and does not impede the manipulation of the config>router>mpls>lsp-template. The required identifiers are from, lsp-template and to, all under this node.
The no form of this command deletes the template-name reference from the configuration.
Parameters
to
Syntax
Context
Description
This command specifies an IPv4 address used (with the LSP template) to identify the LSP to be tested.
One of three mandatory configuration statements that are required to identify automatically created RSVP LSPs, using config>router>mpls>lsp-template. The config>router>mpls>auto-lsp>lsp-template links three distinct functions, the config>router>policy-options>prefix-list, config>router>policy-options>policy-statement>entry>from and the config>router>mpls> lsp-template. The to address is the same address configured as the from address for the config>router>policy-options>policy-statement>entry>from. The required identifiers are from, lsp-template and to, all under this node.
Parameters
pattern
Syntax
Context
Description
This command configures the pattern value to be repeated in the padding portion of pad-tlv length field of the dm PDU.
The no form of this command uses an incrementing byte pattern beginning with 00 and ending with FF, wrapping back to 00.
Parameters
profile
Syntax
Context
Description
This command defines whether the DM PDU packet should be treated as in profile or out-of-profile.
The no form of this command reverts the default value.
Default
profile out
Parameters
ttl
Syntax
Context
Description
This command defines the value of the MPLS TTL for DM packets.
The no form of this command reverts the default value.
Default
ttl 255
Parameters
3.14.2.15.5. Streaming Commands
streaming
Syntax
Context
Description
This command specifies the context to configure the OAM-PM streaming template and its associated parameters.
delay-template
Syntax
Context
Description
This command specifies a template for streaming delay metrics that can be referenced under the oam-pm>session technology delay style test.
The delay-template must be configured under the technology delay test oam-pm>session to allow the delay specific test to stream results using the configured template attributes.
The no form of this command deletes the specified delay template.
Parameters
fd-avg
Syntax
Context
Description
This command specifies the sending of average frame delay for a specified direction.
The no form of this command deletes the specified average direction.
| Note: All directions can be specified if all directions are important for reporting. However, only enable those directions that are required. |
Parameters
ifdv-avg
Syntax
Context
Description
This command specifies the sending of average inter-frame delay variation for a specified direction.
The no form of this command deletes the specified average direction.
| Note: All directions can be specified if all directions are important for reporting. However, only enable those directions that are required. |
Parameters
sample-window
Syntax
Context
Description
This command specifies the sample window duration in seconds for the template. This configuration option represents time over which the average will be calculated and subsequently streamed.
The no form of this command reverts to the default.
Default
sample-window 60
Parameters
shutdown
Syntax
Context
Description
This command administratively enables the template. Enabling the template allows those tests referencing that template to start collecting, computing and streaming. Disabling a template causes any test referencing the template to stop collecting, computing and streaming. The state of the delay-template has not impact on the transmission and reception of the test PDUs configured under the oam-pm>session context. It only affects the collection, computing and streaming of for those tests. Many objects must be shut down before they may be deleted.
The no form of this command administratively enables the entity.
Default
shutdown
window-integrity
Syntax
Context
Description
This command specifies the integrity of the sample window. A percentage value that suggests the measurement has enough samples (integrity) to be considered representative for that sample window. The configured percentage considers the interval of the test PDUs, and the length of the sample window to determine the number of packets required in the sample.
(((window-integrity %) x (sample-window length (s) x pps per test (interval)).
Ensure that the percentage and the combination of sample window and packet per second per test interval produces the desired results.
If the number of samples in the sample window are equal to or greater than the computed number of required samples, then the value has integrity and the suspect flag is set to false for that streamed result.
If the count is less than the computed number of required samples, then the suspect flag is set to true for that streamed result.
Regardless of the integrity, the average values are streamed. It is up to the higher level systems to interrogate the suspect flag and determine if the value that is set should be used, discarded, or reported separately.
The no form of this command reverts to the default.
Default
window-integrity 50
Parameters
3.14.2.16. Performance Monitoring and Reflector Commands
3.14.2.16.1. TWAMP Server Commands
test-oam
Syntax
Context
Description
This command enables the context to configure OAM test parameters.
twamp
Syntax
Context
Description
This command enables TWAMP functionality.
server
Syntax
Context
Description
This command configures the node for TWAMP server functionality.
inactivity-timeout
Syntax
Context
Description
This command configures the inactivity time out for all TWAMP-control connections. If no TWAMP control message is exchanged over the TCP connection for this duration of time the connection is closed and all in-progress tests are terminated.
The no form of this command returns the value to the default.
Default
inactivity-timeout 900
Parameters
max-conn-server
Syntax
Context
Description
This command configures the maximum number of TWAMP control connections from all TWAMP clients. A new control connection is rejected if accepting it would cause either this limit or a prefix limit (max-conn-prefix) to be exceeded.
The no form of this command returns the value to the default.
Default
max-conn-server 32
Parameters
max-sess-server
Syntax
Context
Description
This command configures the maximum number of concurrent TWAMP-Test sessions across all allowed clients. A new test session (described by a Request-TW-Session message) is rejected if accepting it would cause either the limit defined by this command or a prefix limit (max-sess-prefix) to be exceeded.
The no form of this command returns the value to the default.
Default
max-sess-server 32
Parameters
prefix
Syntax
Context
Description
This command configures an IP address prefix containing one or more TWAMP clients. For a TWAMP client to connect to the TWAMP server (and subsequently conduct tests) it must establish the control connection using an IP address that is part of a configured prefix.
Parameters
ipv4-prefix: | a.b.c.d (host bits must be 0) | |
ipv4-prefix-le: | 0 to 32 | |
ipv6-prefix: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
ipv6-prefix-le: | 0 to 128 | |
description
Syntax
Context
Description
This command configures a description for the TWAMP server prefix table.
The no form of this command removes the configuration.
Parameters
max-conn-prefix
Syntax
Context
Description
This command configures the maximum number of control connections by clients with an IP address in a specific prefix. A new control connection is rejected if accepting it would cause either the prefix limit defined by this command or the server limit (max-conn-server) to be exceeded.
The no form of this command returns the value to the default.
Default
max-conn-prefix 32
Parameters
max-sess-prefix
Syntax
Context
Description
This command configures the maximum number of concurrent TWAMP-Test sessions by clients with an IP address in a specific prefix. A new test session (described by a Request-TW-Session message) is rejected if accepting it would cause either the limit defined by this command or the server limit (max-sess-server) to be exceeded.
The no form of this command returns the value to the default.
Default
max-sess-prefix 32
Parameters
3.14.2.16.2. TWAMP Light Reflector Commands
twamp-light
Syntax
Context
Description
This command enables the context for configuring TWAMP Light parameters.
inactivity-timeout
Syntax
Context
Description
This command configures the length of time to maintain stale state on the session reflector. Stale state is test data that has not been refreshed or updated by newly arriving probes for that specific test in a predetermined length of time. Any single reflector can maintain up state for a maximum of 12000 tests. If the maximum value is exceeded, the session reflector lacks memory to allocate to new tests.
The no form of this command returns the value to the default.
Default
inactivity-timeout 100
Parameters
reflector
Syntax
Context
Description
This command configures a TWAMP Light session reflector parameters and to enable TWAMP Light functionality with the no shutdown command. The udp-port keyword and value must be specified with the create keyword. An error message is generated if the specific UDP port is unavailable.
Parameters
Note that in the Two-Way Active Measurement Protocol Light (TWAMP Light) section for a complete description. This parameter is required and specifies the destination udp-port that the session reflector uses to listen for TWAMP Light packets. The session controller launching the TWAMP Light packets must be configured with the same destination UDP port as part of the TWAMP Light test. The IES service uses the destination UDP port that is configured under the router context. Only one UDP port can be configured per unique context.
description
Syntax
Context
Description
This command configures a text description that gets stored in the configuration file for a configuration context. The description command associates a text string with a configuration context to help identify the content in the configuration file.
The no form of this command removes the string from the configuration.
Parameters
prefix
Syntax
Context
Description
This command defines which TWAMP Light packet prefixes the reflector processes.
The no form of this command with the specific prefix removes the accepted source.
Parameters
ipv4-prefix: | a.b.c.d (host bits must be 0) | |
ipv4-prefix-le: | 0 to 32 | |
ipv6-prefix: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
ipv6-prefix-le: | 0 to 128 | |
shutdown
Syntax
Context
Description
This command disables or enables TWAMP Light functionality within the context where the configuration exists, either the base router instance or the service. Enabling the base router context enables the IES prefix list since the IES service uses the configuration under the base router instance.
The no form of this command allows the router instance or the service to accept TWAMP Light packets for processing.
Default
shutdown
3.14.2.16.3. MPLS DM Reflector Commands
mpls-dm
Syntax
Context
Description
This command enables the context to configure global MPLS delay measurement parameters.
shutdown
Syntax
Context
Description
This command disables or enables MPLS delay measurement transmission and reflection processing.
The no form of this command allows the transmission and reflection of MPLS DM packets.
Default
shutdown
3.14.2.17. Seamless BFD Commands
bfd
Syntax
Context
Description
This command specifies the context for the configuration of BFD parameters global to a specific router.
The no form of this command removes the context.
seamless-bfd
Syntax
Context
Description
This command specifies the context for the configuration of a seamless BFD reflector.
reflector
Syntax
Context
Description
This command specifies the seamless BFD reflector.
The no form of this command removes the context.
Parameters
description
Syntax
Context
Description
This command specifies a description of a S-BFD reflector.
Parameters
discriminator
Syntax
Context
Description
This command specifies the S-BFD discriminator.
The no form of this command removes the discriminator.
Parameters
local-state
Syntax
Context
Description
This command specifies the setting of the local state field in reflected seamless BFD control packets.
The no form of this command means that the field is not explicitly set by the reflector.
Default
local-state up
Parameters
shutdown
Syntax
Context
Description
This command specifies the administrative state of the seamless BFD reflector.
The no form of this command administratively enables the reflector. A discriminator must be configured before the no shutdown command is invoked.
Default
shutdown
3.14.2.18. Show Commands
The command outputs in the following section are examples only; actual displays may differ depending on supported functionality and user configuration.
saa
Syntax
Context
Description
This command displays information about the SAA test.
If no specific test is specified a summary of all configured tests is displayed.
If a specific test is specified then detailed test results for that test are displayed for the last three occurrences that this test has been executed, or since the last time the counters have been reset via a system reboot or clear command.
Parameters
Output
The following sample output shows SAA test information. Table 34 describes the SAA test fields.
Table 34: SAA Field Descriptions
Label | Description |
Test Name | Specifies the name of the test. |
Owner Name | Specifies the owner of the test. |
Description | Specifies the description for the test type. |
Accounting policy | Specifies the associated accounting policy ID. |
Administrative status | Specifies whether the administrative status is enabled or disabled. |
Test type | Specifies the type of test configured. |
Trap generation | Specifies the trap generation for the SAA test. |
Test runs since last clear | Specifies the total number of tests performed since the last time the tests were cleared. |
Number of failed tests run | Specifies the total number of tests that failed. |
Last test run | Specifies the last time a test was run. |
Threshold type | Indicates the type of threshold event being tested, jitter-event, latency-event, or loss-event, and the direction of the test responses received for a test run: in — inbound out — outbound rt — roundtrip |
Direction | Indicates the direction of the event threshold, rising or falling. |
Threshold | Displays the configured threshold value. |
Value | Displays the measured crossing value that triggered the threshold crossing event. |
Last event | Indicates the time that the threshold crossing event occurred. |
Run # | Indicates what test run produced the specified values. |
test-oam
Syntax
Context
Description
This command enables the context to display test oam information.
twamp
Syntax
Context
Description
This command enables the context for displaying TWAMP information.
client
Syntax
Context
Description
This command displays TWAMP client information.
Parameters
ipv4-address: | a.b.c.d | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
Output
The following sample output shows TWAMP client information.
server
Syntax
Context
Description
This command displays TWAMP server information.
Parameters
ipv4-address: | a.b.c.d (host bits must be 0) | |
ipv4-prefix-length | 0 to 32 | |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) | |
x:x:x:x:x:x:d.d.d.d | ||
x: | [0 to FFFF]H | |
d: | [0 to 255]D | |
Output
The following sample output shows TWAMP server information.
ldp-treetrace
Syntax
Context
Description
This command displays OAM LDP treetrace information.
Parameters
Output
The following sample output shows OAM LDP treetrace information.
lsp-bfd
Syntax
Context
Description
This command displays information about Bidirectional Forwarding Detection (BFD) sessions on LSPs.
Parameters
oam-config-summary
Syntax
Context
Description
This command displays the OAM configuration in-use numbers, percentages, and system limits for the platform.
Output
The following output is an example of OAM configuration information.
Table 35 describes the Test OAM Configuration Limit fields.
Table 35: Test OAM Configuration Limit Fields
Label | Description |
InUse | Specifies the number of resources in use |
%InUse | Specifies the percentage of resources in use |
Limit | Specifies the total number of available resources |
oam-perf
Syntax
Context
Description
This command displays OAM performance information, including packet per second rates and the cumulative packets receive and transmitted. Statistics are cleared using the clear>test-oam>oam-perf command to properly interpret current data rate. The counts are displayed since the last clear and may be skewed because of irrelevant historical data.
Parameters
Output
The following output is an example of OAM performance information.
twamp-light
Syntax
Context
Description
This command enables the context to display TWAMP-Light information.
reflectors
Syntax
Context
Description
This command shows TWAMP-Light reflector information.
Output
The following sample output shows TWAMP Light reflector information.
twamp-light
Syntax
Context
Description
This command shows TWAMP-Light reflector information, either for the base router or for a specific service.
Output
The following is an example of TWAMP Light reflector information.
eth-cfm
Syntax
Context
Description
This command enables the context to display CFM information.
association
Syntax
Context
Description
This command displays eth-cfm association information.
Parameters
Output
The following is an example of association information.
cfm-stack-table
Syntax
Context
Description
This command displays stack-table information. This stack-table is used to display the various management points MEPs and MIPs that are configured on the system. These can be service-based or facility-based. The various options allow the operator to be specific. If no parameters are included then the entire stack-table is displayed.
Parameters
port-id | slot/mda/port[.channel] | ||
lag-id | lag-id | ||
lag | keyword | ||
id | 1 to 800 | ||
eth-sat-id | esat-<id>/<slot>/[u]<port> | ||
esat | keyword | ||
id | 1 to 20 | ||
u | keyword for up-link port | ||
tdm-sat-id | tsat-<id>/<slot>/[<u>]<port>.<channel> | ||
tsat | keyword | ||
id | 1 to 20 | ||
u | keyword for up-link port | ||
Output
The following is an example of stack table information.
collect-lmm-fc-stats
Syntax
Context
Description
This command displays the entities that are configured with per-FC LMM counters, and whether those counters are counting in-profile packets only or all countable packets.
Each entity may have up to eight individual FC-based counters. Each FC includes a positional index value (1 to 8) under the FC that is counting. A “P” indicates that the index is only counting in-profile traffic.
When no display filters are applied, this command displays all entities and the individual FC counters. Optional filters help to reduce the output that is visible to the operator.
Parameters
sap-id: | |||
null | port-id | bundle-id | bpgrp-id | lag-id | aps-id | ||
dot1q | port-id | bundle-id | bpgrp-id | lag-id | aps-id | pw-id:[qtag1|cp-conn-prof-id] | ||
qinq | port-id | bundle-id | bpgrp-id | lag-id | pw-id:[qtag1 cp-conn-prof-id].[qtag2 | cp-conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
atm | port-id | aps-id [:vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
frame | port-id | aps-id:dlci | ||
cisco-hdlc | slot/mda/port.channel | ||
cem | slot/mda/port.channel | ||
ima-grp | bundle-id [:vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id] | ||
cp | keyword | ||
conn-prof-id | 1 to 8000 | ||
port-id | slot/mda/port[.channel] esat-id/slot/port pxc-id.sub-port | ||
bundle-id | bundle-type-slot/mda.-bundle-num | ||
bundle | keyword | ||
type | ima | fr | ppp | ||
bundle-num | 1 to 336 | ||
bpgrp-id | bpgrp-type-bpgrp-num | ||
bgrp | keyword | ||
type | ima | ppp | ||
bgrp-num | 1 to 2000 | ||
aps-id | aps-group-id[.channel] | ||
aps | keyword | ||
group-id | 1 to 128 | ||
ccag-id | ccag-id.path-id[cc-type]:cc-id | ||
ccag | keyword | ||
id | 1 to 8 | ||
path-id | a | b | ||
cc-type | .sap-net | .net-sap | ||
cc-id | 1 to 4094 | ||
eth-tunnel | eth-tunnel-id[:eth-tun-sap-id] | ||
id | 1 to 1024 | ||
eth-tun-sap-id | 0 to 4094 | ||
lag-id | lag-id | ||
lag | keyword | ||
id | 1 to 800 | ||
pw-id | pw-id | ||
pw | keyword | ||
id | 1 to 10239 | ||
qtag1 | * | 0 to 4094 | ||
qtag2 | * | null | 0 to 4094 | ||
vpi | 0 to 4095 (NNI) | ||
0 to 255 (UNI) | |||
vci | 1 | 2 | 5 to 65535 | ||
dlci | 16 to 1022 | ||
tunnel-id | tunnel-id.private | public:tag | ||
tunnel | keyword | ||
id | 1 to 16 | ||
tag | 0 to 4094 | ||
Output
The following sample output shows information about entities that are configured with per-FC counters.
collect-lmm-stats
Syntax
Context
Description
This command displays the entities that are configured with a single LMM counter using the format of the ETH-CFM stack table.
Output
The following output is an example of LMM counter information.
default-domain
Syntax
Context
Description
This command displays default domain information.
Parameters
domain
Syntax
Context
Description
This command displays domain information.
Parameters
Output
The following is an example of domain information.
lbm-svc-act-responder
Syntax
Context
Description
This command shows MEPs enabled with the ability to process service activation streams which may be encapsulated in the ETH-CFM request Loopback Message (LBM).
Parameters
Output
The following is an example of LBM information.
learned-remote-mac
Syntax
Context
Description
This command displays the local MEP and remote MEP MAC address information relationship. The MAC address information in this table is populated and used in place of the remote mep-id in various ETH-CFM tests that opt to use the remote-mepid mep-id configuration instead of specifying the remote peer MAC address. This table is maintained by the ETH-CC process. If a CCM has not been received for a remote peer, there is no entry in the learned-remote-mac table. However, once a CCM is received for an expected peer, an entry in the learned-remote-mac table is populated and maintained. This entry remains until the remote peer statement is deleted from the association, the local MEP is deleted, or if a manual clear>eth-cfm>learned-remote-mac command has been executed for the specified local MEP.
The optional parameters are treated as independent filters that are combined to refine the output. Omitting all optional parameters produces output that includes the entire table.
Parameters
Output
The following is an example of learned remote MAC information. Table 36 describes the learned remote MAC fields.
Table 36: Learned Remote MAC Field Descriptions
Label | Description |
MdIndex | The local MEP domain index |
MaIndex | The local MEP association index |
L-MepId | The local MEP identifier |
R-MepId | The remote MEP identifier |
Learned Remote MAC | The learned MAC address of the remote peer |
Stale | Results of the comparison between the CCM database and the learned-remote-mac table False — match True — mismatch |
Updated | Whether the learned MAC in this table has been updated in the last CCM interval |
local-tx-pdu
Syntax
Context
Description
This command displays the transmission for ETH-CC, ETH-AIS, and ETH-CFM Grace (ETH-VSM or ETH-ED) using a character representation for each protocol per MEP. ETH-CC is expanded to include columns for RDI, Port Status TLV, and Interface Status TLV. The additional ETH-CC columns represent the actual transmitting value of the TLV, or “Absent” if not present in the ETH-CC PDU. These additional ETH-CC columns are represented with a series of dashes if the ETH-CC column under the TxPDU is a dash (“-”) or “c”.
The optional parameters are treated as independent and cumulative filters that are combined to refine the output. Rows in the output are populated for matches against all specified filters. Omitting all optional parameters produces output that includes all MEPs.
Parameters
Output
The following is an example of local PDU transmission information. Table 37 describes the local PDU transmission fields.
Table 37: Local PDU Transmission Field Descriptions
Label | Description |
MdIndex | The local MEP domain index |
MaIndex | The local MEP association index |
MepId | The local MEP identifier |
SrcMacAddress | The local MEP source MAC address |
TxRdi | The RDI value |
PortTLV | The Port Status TLV value |
IfTLV | The Interface Status TLV value |
TxPDU | The transmission, summarized in three single-character columns. The left column displays ETH-CC, the middle column displays ETH-AIS, and the right column displays ETH-CFM Grace (ETH-VSM or ETH-ED). For ETH-AIS, “A” is displayed when a facility MEP has determined that the AIS state is active, regardless of interaction, linkages, or active transmission of associated MEPs. |
mep
Syntax
Context
Description
This command displays Maintenance Endpoint (MEP) information.
Parameters
Output
The following is an example of MEP information.
mip
Syntax
Context
Description
This command displays provisioned SAPs and bindings that allow MIP creation.
Output
The following is an example of MIP information.
mip-instantiation
Syntax
Context
Description
This command displays the MIPs installed on SAPs or bindings, the various attributes, and the authority responsible for driving the MIP attribute. Authorities include def (default-domain), asn (association), and sys (system).
Parameters
Output
The following is an example of MIP instantiation information. Table 38 describes the MIP instantiation fields.
Table 38: MIP Instantiation Field Descriptions
Label | Description |
Lvl | Level |
LA | Level authority |
Creation | mhf-creation mode |
CA | Creation authority |
IdPerm | sender-id TLV (IdPermission) |
IdA | sender-id authority (IdPermission) |
Pri | ltm-priority response |
PA | Priority authority |
VLAN | Primary VLAN |
sap
Syntax
Context
Description
This command displays MIP creation information for SAPs.
Parameters
sdp
Syntax
Context
Description
This command displays MIP creation information for SDP bindings.
Parameters
statistics
Syntax
Context
Description
This command displays the ETH-CFM statistics counters.
Output
The following is an example of ETH-CFM statistics information. Table 39 describes the ETH-CFM statistics fields.
Table 39: ETH-CFM Statistics Field Descriptions
Label | Description |
Rx Count | The ETH-CFM CPU receive rate, in PPS |
Tx Count | The ETH-CFM CPU transmit rate, in PPS |
Dropped Congestion | The number of valid or supported ETH-CFM packets not processed by the CPU as a result of resource contention |
Discard Error | The number of ETH-CFM packets that did not pass validation |
system-config
Syntax
Context
Description
This command shows various ETH-CFM system-level configuration parameters under the config>eth-cfm [{redundancy | slm | system}] hierarchies and various system capabilities.
Output
The following is an example of ETH-CFM system-level configuration information.
system-info
Syntax
Context
Description
This command displays system-level ETH-CFM information states.
Output
The following is an example of system-level ETH-CFM information.
3.14.2.18.1. OAM Performance Monitoring and Binning Show Commands
oam-pm
Syntax
Context
Description
This command enables the context to show Operations, Administration, and Maintenance Performance Management information.
bin-group
Syntax
Context
Description
Show the configuration data for one or all OAM Performance Monitoring bin groups.
Parameters
Output
The following is an example of OAM-PM bin group information.
bin-group-using
Syntax
Context
Description
Show the list of sessions configured against one or all OAM Performance Monitoring bin groups.
Parameters
Output
The following is an example of OAM-PM bin group session information.
session
Syntax
Context
Description
Show the configuration and status information for an OAM Performance Monitoring session.
Parameters
Output
The following is an example of OAM-PM configuration information.
sessions
Syntax
Context
Description
This command shows a summary of the OAM Performance Monitoring sessions.
Parameters
Output
The following is an example of OAM-PM session summary information.
statistics
Syntax
Context
Description
This command shows the delay statistics for the specified test using the parameters specified.
Parameters
statistics
Syntax
Context
Description
This command shows the loss statistics for the specified test using the parameters specified.
Parameters
delay-template
Syntax
Context
Description
This command displays the configuration data for one or all OAM performance monitoring delay templates.
Parameters
Output
The following is an example of OAM-PM streaming delay-template summary information. Table 40 describes the delay template fields.
Table 40: Show delay-template Output Fields
Label | Description |
Name | Name of the delay template |
Admin | State of the delay template |
Tests | Number of tests referencing the delay template |
Tmpl Name | Name of the delay template |
Description | Description of the delay template (truncated beyond width) |
Admin State | Up — The delay template is administratively enabled Down — The delay template is administratively disabled |
FD Average | forward — The average frame delay metric for forward direction backward — The average frame delay metric for backward direction round-trip — The average frame delay metric for round-trip direction |
IFDV Average | forward — The average inter-frame delay variation metric for forward direction backward — The average inter-frame delay variation metric for backward direction round-trip — The average inter-frame delay variation metric for round-trip direction |
Sample Window | Length of the sample window |
Window Integrity | Percentage required to ensure integrity of the reporting |
Active Test Refs | Number of tests actively referencing the delay template |
Total Test Refs | Number of total tests referencing the delay template |
delay-template-using
Syntax
Context
Description
This command displays the list of sessions configured against one or all OAM performance monitoring delay templates.
Parameters
Output
The following is an example of OAM-PM streaming delay-template-using summary information.
tests
Syntax
Context
Description
This command displays a list of OAM-PM test types and associated test IDs. The output provides an ordered list by type and ID to help locate available test IDs that may be configured within a specific type. Filters are available to refine the output to the operational need. Multiple filters can be included to further refine the output. The combination of the filters is an AND function. All filters must be true to provide tests output.
Parameters
Output
The following is an example of OAM-PM test type and test ID information. Table 41 describes test fields.
Table 41: OAM-PM Test
Label | Description |
Test Type | The OAM-PM protocol specific test |
Test ID | The numerical value, between 0 to 2147483647, that is assigned to the protocol specific test |
Admin | The administrative state of the test Up – The test has been enabled by configuration Down – The test was not enabled by configuration |
Oper | The operational state of the test Up – The test is administrative Up and currently transmitting, attempting to transmit packets, or ready to transmit packets Down – The test is administratively down or an oam-pm session has been configured with session-type on-demand and has not been enabled using the global CLI oam oam-pm session start command |
TxE | no – There has been no error detected yes – The has been an error detected |
Sess Type | The session type, proactive and on-demand |
Session | The name of the session, up to 32 characters |
3.14.2.19. Clear Commands
oam-pm
Syntax
Context
Description
This command enables the context to clear Operations, Administration, and Maintenance Performance Management information.
eth-cfm
Syntax
Context
Description
This command enables the context to display CFM information.
auto-discovered-meps
Syntax
Context
Description
This command clears remote MEPs that were auto discovered. The function clears a specific auto-discovered MEP learned within an association or all auto-discovered MEPs in the association. When the mep-id representing the auto-discovered MEP is omitted and only the domain md-index and association ma-index are provided, all auto-discovered MEPs in the association are cleared. At a minimum the domain md-index and the association ma-index must be provided.
Only auto-discovered MEPs may be cleared. This command has no effect on manually configured MEPs.
Parameters
learned-remote-mac
Syntax
Context
Description
This command clears the stored MAC addresses in the CFM learned-remote-mac address table. A valid MAC address must exist in the learned-remote-mac table for a successful PDU generation when that test uses the remote-mepid mep-id option in place of a mac-address.
The local domain and association parameters must be included as part of the clear command. The mep and remote-mepid parameters are optional. The clear command clears all matching entries based on the configured parameters. The table is populated based on the reception and processing of ETH-CC PDUs.
Parameters
mep
Syntax
Context
Description
This command clears the MEP parameters.
Parameters
statistics
Syntax
Context
Description
This command clears the eth-cfm statistics counters maintained in clearEthCfmStatistics.
session
Syntax
Context
Description
This command clears OAM performance statistics recorded reported by the show>test-oam >oam-perf [detail].
Parameters
saa
Syntax
Context
Description
This command clears the SAA results for the latest and the history for this test. If the test name is omitted, all the results for all tests are cleared.
Parameters
test-oam
Syntax
Context
Description
This command enables the context to clear test oam information.
oam-perf
Syntax
Context
Description
This command clears OAM performance statistics.
twamp
Syntax
Context
Description
This command clears Two-Way Active Measurement Protocol statistics.
server
Syntax
Context
Description
This command clears TWAMP server statistics.
3.14.2.20. Monitor Commands
oam-pm
Syntax
Context
Description
This command enables the context to montiror Operations, Administration, and Maintenance Performance Management information.
session
Syntax
Context
Description
This command monitors the raw measurement interval for the specified session and test.
Output
The following sample output shows raw session measurement information.
dm
Syntax
Context
Description
This command monitors the MPLS Delay Measurement (DM) statistics for the specified test's raw measurement interval.
Parameters
dmm
Syntax
Context
Description
This command monitors the Ethernet Delay Measurement Message (DMM) statistics for the specified test's raw measurement interval.
Parameters
lmm
Syntax
Context
Description
This command monitors the Ethernet Loss Measurement Message (LMM) statistics for the specified test's raw measurement interval.
Parameters
slm
Syntax
Context
Description
This command monitors the Ethernet Synthetic Loss Measurement (SLM) statistics for the specified test's raw measurement interval.
Parameters
twamp-light
Syntax
Context
Description
This command monitors the IP Two Way Active Measurement Protocol Light (TWAMP Light) statistics for the specified test's raw measurement interval.
Parameters
test-oam
Syntax
Context
Description
This command enables the context to display test oam information.
oam-perf
Syntax
Context
Description
This command monitors the OAM performance statistics.
Parameters
3.14.2.21. Debug Commands
eth-cfm
Syntax
Context
Description
This command enables the context to configure ETH-CFM debugging functions.
mep
Syntax
Context
Description
This command specifies the MEP from which to debug the CFM PDUs.
The no form of this command removes the MEP parameters.
Parameters
packet
Syntax
Context
Description
This command defines the ETH-CFM opcodes of interest to be debugged.
The no form of this command stops packet debugging and the collection of PDUs.
Parameters
MEPs support all opcodes.
MIPs support 2 (LBR), 3 (LBM), 4 (LTR), and 5 (LTM).
Unknown or unsupported opcodes in TLA form are rejected. The applicable numerical opcode can be used instead. When numerical references are used, they are converted to a known TLA or left in numerical form if the TLA is unknown.
Re-entering the packet command overwrites the previous opcode entries for the MEP or MIP.
mip
Syntax
Context
Description
This command specifies the MIP from which to debug the CFM PDUs.
The no form of this command removes the MIP parameters.
Parameters
ldp-treetrace
Syntax
Context
Description
This command enables debugging for OAM LDP treetrace.
The no form of this command disables the debugging.
lsp-ping-trace
Syntax
Context
Description
This command enables debugging for lsp-ping.
Parameters
3.14.2.22. Tools Commands
eth-cfm
Syntax
Context
Description
This command enables the context to configure debugging for Ethernet Connectivity Fault Management.
debug-packet
Syntax
Context
Description
This command displays and optionally clears the counters representing the number of CFM PDUs that matched the debug criteria but were not passed to the debug logger. This situation is caused by a full message queue.
Parameters
Output
The following output is an example of CFM-PDU information.
top-active-meps
Syntax
Context
Description
This command displays and optionally clears the most active MEPs on the system.
Default
top-active-meps
Parameters
test-oam
Syntax
Context
Description
This command enables the context to dump test oam information.
lsp-bfd
Syntax
Context
Description
Thisd command enables the context to dump information about Bidirectional Forwarding Detection (BFD) sessions on LSPs.
tail
Syntax
Context
Description
This command dumps information for BFD sessions on LSPs.
Parameters
Output
The following output is an example of tail information.
twamp
Syntax
Context
Description
This command dumps TWAMP information.
server
Syntax
Context
Description
This command dumps TWAMP server information.
error-counters
Syntax
Context
Description
This command dumps various error counters related to TWAMP server and TWAMP test.
Output
The following output is an example of various error counters related to TWAMP server and TWAMP test.