Diagnostics Command Reference
Command Hierarchies
OAM Commands
Base Operational Commands
ATM Diagnostics
IGMP Snooping
LDP Diagnostics
LSP Diagnostics
SDP Diagnostics
Common Service Diagnostics
VLL Diagnostics
Ethernet in the First Mile (EFM) Commands
ETH-CFM OAM Commands
SAA Commands
OAM Performance Monitoring and Binning Commands
IP Performance Monitoring Commands
TWAMP
TWAMP Light
Show Commands
Clear Commands
Monitor Commands
Debug Commands
Tools Commands
Command Descriptions
OAM and SAA Commands
Generic Commands
shutdown
Syntax
Context
Description
In order to modify an existing test it must first be shut down. When a test is created it will be in shutdown mode until a no shutdown command is executed.
A shutdown can only be performed if a test is not executing at the time the command is entered.
Use the no form of the command to set the state of the test to operational.
shutdown
Syntax
Context
Description
This command suspends the background process running the LDP ECMP OAM tree discovery and path probing features. The configuration is not deleted.
Use the no form of the command to enable the background process.
OAM Commands
dns
Syntax
Context
Description
This command performs DNS name resolution. If ipv4-a-record is specified, dns-names 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
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 | |
 | Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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.
ping
Syntax
Context
Description
This command verifies the reachability of a remote host.
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: | 32 characters maximum, mandatory for link local addresses | |
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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 | |
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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] | |
traceroute
Syntax
Context
Description
The TCP/IP traceroute utility determines the route to a destination address. DNS lookups of the responding hosts is 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] | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
p2mp-lsp-ping
Syntax
Context
Description
This command performs 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 which are leaves of the P2MP LSP instance will reply 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 a particular LSP.
The user can reduce the scope of the echo reply messages by explicitly entering a list of addresses for the egress LER nodes that are required to reply. A maximum of 5 addresses can be specified in a single run of the p2mp-lsp-ping command. A LER node is able to parse the list of egress LER addresses and if its address is included, it will reply with an echo reply message.
The output of the command without the detail option provides a high-level summary of error codes and/or success codes received. 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 will be delayed until all responses are received or the timer configured in the timeout parameter expired. No other CLI commands can be entered while waiting for the display. A ^C will abort 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 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 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 10 summarizes this behavior.
Table 10: p2mp-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:
|
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 | [64 chars max] | |
sender-addr | ipv4-address | a.b.c.d| |
leaf-addr | ipv4-address | a.b.c.d| |
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 similar to that of the 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 will then also include the downstream mapping TLV to report the information about the downstream branches of the P2MP LSP. An egress LER must 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 giving up on receiving the echo reply message. 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 replied.
Similar to p2mp-lsp-ping, an LSP trace probe results on all egress LER nodes eventually receiving the echo request message but only the traced egress LER node will reply to the last probe.
Also 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 which has a downstream branch over which the traced egress LER is reachable will respond.
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 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 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 11 summarizes this behavior.
Table 11: 2mp-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 an echo reply message corresponding to the outstanding message request.
Output
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 [.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 | ||
aps-id | group-id | ||
aps | keyword | ||
group-id | 1 to 64 | ||
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.
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 will signal such support by the capability negotiations. If the operator attempts to send an OAM command to an access node that does not support such command the operation results in an error. This command only applies to the 7450 ESS and 7750 SR.
Parameters
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 will be 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 timeout, 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 will be 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
svc-ping
Syntax
Context
Description
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 will be sent per command; no count nor interval parameter is supported and round trip time is not calculated. A timeout 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 will be shown as N/A.
To terminate a svc-ping in progress, use the CLI break sequence <Ctrl-C>.
Upon request timeout, message response, request termination, or request error the following local and remote information will be displayed. Local and remote information will be dependent upon service existence and reception of reply.
Table 12: 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 | ||
N/A | ||
Local Service Admin State | The local administrative state of service-id. If the service does not exist locally, the administrative state will be 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 will be N/A. | Oper-Up |
Oper-Down | ||
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
Remote Service MTU | The remote service-mtu for service-id. If the service does not exist remotely, N/A is displayed. | remote-service-mtu |
N/A | ||
Local Customer ID | The local customer-id associated with service-id. If the service does not exist locally, N/A is displayed. | customer-id |
N/A | ||
Remote Customer ID | The remote customer-id associated with service-id. If the service does not exist remotely, N/A is displayed. | customer-id |
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 will not use an sdp-id as the return path, but the appropriate responding sdp-id will be 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 | ||
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 | ||
N/A |
Parameters
If local-sdp is not specified, the svc-ping request message is sent with GRE encapsulation with the OAM label.
Table 13 indicates whether a message is sent and how the message is encapsulated based on the state of the service ID.
Table 13: 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) |
Table 14 indicates how the message response is encapsulated based on the state of the remote service ID.
Table 14: 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
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
vprn-ping
Syntax
Context
Description
This command performs a VPRN ping and applies only to the 7750 SR and 7950 XRS.
Parameters
ipv4-address: | 0.0.0.0 to 255.255.255.255 |
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 |
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 and applies to the 7750 SR and 7950 XRS only.
Parameters
ipv4-address: | 0.0.0.0 to 255.255.255.255 |
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 |
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
VPLS MAC Diagnostics
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 FIB 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 FIB indicating the device is the egress node for a particular MAC address. The MAC address can be bound to a particular 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 FIB nor an egress SAP, then it is not allowed to initiate a mac-populate.
The MAC address that is populated in the FIBs 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 FIB 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 a particular 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.
mac-purge
Syntax
Context
Description
This command removes an OAM-type MAC entry from the FIB 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 FIB for forwarding, but it is retained in the FIB 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
The mac-ping utility is used to determine 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 FIB and without any SAPs cannot have an egress MAC address binding, so it is not a node where replies in the data plane will be 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 will be used as if the packet originated from this SHG. In all other cases, SHG 0 (zero) will be used. Note that if the mac-trace is originated from a non-zero SHG, such packets will not go out to the same SHG.
If EMG is enabled, mac-ping will return only the first SAP in each chain.
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 Alcatel-Lucent 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 will be used as if the packet originated from this SHG. In all other cases, SHG 0 (zero) will be used. Note that if the mac-ping is originated from a non-zero SHG, such packets will not go out to the same SHG.
If EMG is enabled, mac-trace will return only the first SAP in each chain.
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.
vxlan-ping
Syntax
Context
Description
Operational command used to validate the VXLAN Tunnel Endpoint (VxLAN) connectivity between peers.
Parameters
IGMP Snooping Diagnostics
mfib-ping
Syntax
Context
Description
The mfib-ping utility 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 specifies the reply 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.
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.
The message interval value must be expired before the next message request is sent.
Upon the expiration of message timeout, the requesting router assumes that the message response will not be 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 will be silently discarded.
Output
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 will be 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 | ||
local-loopback
Syntax
Context
Description
This command enables local loopback tests on the specified port.
remote-loopback
Syntax
Context
Description
This command enables remote Ethernet in the First Mile (EFM) OAM loopback tests on the specified port. The EFM OAM remote loopback OAMPDU will be sent to the peering device to trigger remote loopback.
In order for EFM OAM tunneling to function properly, EFM OAM tunneling should be configured for VLL services or a VPLS service with two SAPs only.
ETH-CFM OAM Commands
linktrace
Syntax
Context
Description
The command specifies to initiate a linktrace test.
Parameters
loopback
Syntax
Context
Description
The command specifies to initiate a loopback test.
Parameters
eth-test
Syntax
Context
Description
This command issues an ETH-CFM 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 allows the operator to configure 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 will not affect fault propagation mechanisms.
Parameters
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 will include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs will include this value in the LBR and LTR PDUs.
| Note:
LBR functions reflect back all TLVs received in the LBM unchanged, including the SenderID TLV. |
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 will include the sender-id tlv information in ETH-CFM PDUs. MEPs will include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs will include this value in the LBR and LTR PDUs.
| Note:
LBR functions reflect back 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
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 configuration for facility base MEPs. When this option is present under the maintenance association, the specific MPs in the association will include the sender-id tlv information in ETH-CFM PDUs. MEPs will include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs will include this value in the LBR and LTR PDUs.
| Note:
LBR functions reflect back all TLVs received in the LBM unchanged including the SenderID TLV. This command will produce 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
interface-support-enable
Syntax
Context
Description
This command enable the AIS function to consider the operational state of the entity on which it is configured. With this command, ETH-AIS on DOWN MEPs will be 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 will be based on either the non operational state of the entity or on ANY CCM defect condition. AIS generation will cease if BOTH operational state is UP and 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.
Default
[no] interface-support-enabled: AIS will not be generated or stopped based on the state of the entity on which the DOWN MEP is configured.
csf-enable
Syntax
Context
Description
This command enable Enabled the reception and local processing of ETH-CSF frames.
Parameters
Service Assurance Agent (SAA) Commands
saa
Syntax
Context
Description
This command creates the context to configure the Service Assurance Agent (SAA) tests.
test
Syntax
Context
Description
This command identifies a test and create/modify the context to provide the test parameters for the named test. Subsequent to 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. In order to remove a test it can not 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 else an error message is generated.
A notification (trap) when a test is completed is issued whenever a test terminates.
The no form of this command removes the accounting policy association.
Default
none
Parameters
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.
Default
No description associated with the configuration context
Parameters
continuous
Syntax
Context
Description
This command specifies whether the SAA test is continuous. Once you have configured a test as continuous, you cannot start or stop it by using the oam saa test-name {start | stop} command. This option is not applicable to all SAA test types.
The no form of the command disables the continuous execution of the test.
jitter-event
Syntax
Context
Description
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 will be re-enabled when it falls below the threshold after the initial crossing that generate the event.
The configuration of jitter event thresholds is optional.
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 will be re-enabled when it falls below the threshold after the initial crossing that generate the event.
The configuration of latency event thresholds is optional.
Parameters
loss-event
Syntax
Context
Description
Specifies that at the termination of an SAA testrun, 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.
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 probe-fail-threshold consecutive probes fail during the execution of the SAA ping test. This command is not applicable to SAA trace route tests.
The no form of the command disables the generation of an SNMP trap.
probe-fail-threshold
Syntax
Context
Description
This command has no effect when probe-fail-enable is disabled. This command is not applicable to SAA trace route tests.
The probe-fail-enable command enables the generation of an SNMP trap when the probe-fail-threshold consecutive probes fail during the execution of the SAA ping test. This command is not applicable to SAA trace route tests.
The no form of the command returns the threshold value to the default.
Default
1
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) will only maintain summary information for tests marked as continuous with file functions, probe counts in excess of 100 and intervals of less than 1 second. SAA tests that are not continuous with a write to file will default to Auto (keep). The operator is free to change the default behaviors for each type. Each test that maintains per probe history will consume more system memory. When per probe entries are required the probe history is available at the completion of the test.
Default
auto
Parameters
test-completion-enable
Syntax
Context
Description
This command enables the generation of a trap when an SAA test completes.
The no form of the 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 the purpose of trap generation) if the number of failed probes is at least the value of the test-fail-threshold parameter.
The no form of the 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 the command returns the threshold value to the default.
Default
1
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, 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.
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.
dns
Syntax
Context
Description
This command configures a DNS name resolution test.
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.
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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 (32 chars max, mandatory for link local addresses) |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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: | 128 characters max | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
router-name: | Base, management |
service-id: | 1 to 2147483647 |
service-id: | 1 to 2147483647 |
svc-name: | 64 characters maximum |
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
router-name: | Base, management |
service-id: | 1 to 2147483647 |
lsp-ping
Syntax
Context
Description
This command performs in-band LSP connectivity tests.
The lsp-ping command performs an LSP ping using the protocol and data structures defined in the RFC 4379, 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 4379, 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 is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
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 | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
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 15 summarizes this behavior.
Table 15: 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 back at the originating router.
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 | |
<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 | ||
Output
This sample output is for a LDP IPv4 and IPv6 prefix FECs.
lsp-trace
Syntax
Context
Description
The lsp-trace command performs an LSP traceroute using the protocol and data structures defined in IETF RFC 4379.
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 and the new Downstream Detailed Mapping (DDMAP) TLV defined in RFC 6424. 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 or a BGP label IPv4 prefix, 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 4379, 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 is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
<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-address: a.b.c.dipv4-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, 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.
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 16 summarizes this behavior.
Table 16: 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:
|
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 | |
Output
mac-ping
Syntax
Context
Description
The mac-ping utility is used to determine the existence of an egress SAP binding of a given MAC within a VPLS service.
A mac-ping packet can be sent via the control plane or the data plane. The send-control option specifies the request be sent using the control plane. If send-control is not specified, the request is sent using 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 FIB and without any SAPs cannot have an egress MAC address binding, so it is not a node where replies in the data plane will be 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 will be used as if the packet originated from this SHG. In all other cases, SHG 0 (zero) will be used. Note that if the mac-trace is originated from a non-zero SHG, such packets will not go out to the same SHG.
If EMG is enabled, mac-ping will return only the first SAP in each chain.
Parameters
service-id: | 1 to 2147483647 |
svc-name: | 64 characters maximum |
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 will be displayed. The following table displays Table 17 shows the response messages sorted by precedence.
Table 17: spd-ping Response Messages
Result of Request | Displayed Response Message | Precedence |
Request timeout 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 timeout | 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 timeout, message response, request termination, or request error the following local and remote information will be displayed. Local and remote information will be dependent upon SDP-ID existence and reception of reply.
Table 18: spd-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 shutdown, 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 will be displayed. | Oper-Up |
Oper-Down | ||
N/A | ||
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 |
N/A | ||
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 will not use an SDP-ID as the return path and N/A will be displayed. | resp-sdp-id |
N/A | ||
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 will be displayed. If the far-end does not use the responding sdp-id as the return path, No will be displayed. If resp-sdp is not specified, N/A will be displayed. | Yes |
No | ||
N/A | ||
Responding SDP-ID Administrative State | The administrative state of the responding sdp-id. When resp-sdp-id is administratively down, Admin-Down will be displayed. When resp-sdp-id is administratively up, Admin-Up will be 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 | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 | ||
N/A | ||
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 |
N/A | ||
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 |
N/A | ||
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 |
N/A |
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 back 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.
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 TPE or SPE. If initiated on the SPE, the reply-mode parameter must be used with the ip-routed value The ping from the TPE can have either values or can be omitted, in which case the default value is used.
If a VCCV ping is initiated from TPE to neighboring a SPE (one segment only) 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 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 spoke SDP it will not be signaled peer VCCV CC bits to the far end, consequently VCCV ping cannot be successfully initiated on that specific spoke SDP.
Note that 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 will be 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 will be 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 will reflect 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 is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.
Parameters
spoke-sdp-fec is mutually exclusive with the sdp-id:vc-id parameter.
global-id — The Global ID of the far end T-PE of the FEC129 pseudowire.
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 back at the originating SR.
Table 19: 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.
src-global-id — The Global ID of the SAII of the targeted static PW FEC element. | |
Values | 1 to 4294967295 |
src-node-id — The node-id on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d |
src-ac-id — An unsigned integer representing a locally unique SAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
dst-global-id — The Global ID of the TAII of the targeted static PW FEC element. | |
Values | 1 to 4294967295 |
dst-node-id – The node-id of the TAII on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d |
dst-ac-id — An unsigned integer representing a locally unique TAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
Output
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 similar to VCCV-Ping. The first message with TTL=1 will have 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 will include 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 will copy 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 timeout 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 will still probe all hops up to min-ttl in order 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 by the user of this command for a FEC129 pseudowire, then these values will be 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 will be 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 will reflect 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) 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
spoke-sdp-fec is mutually exclusive with the sdp-id:vc-id parameter.
The saii-type2 parameter is mutually exclusive with the sdp-id:vc-id parameter.
global-id — The global ID of this T-PE node. | |
Values | 1 to 4294967295 |
prefix — The prefix on this T-PE node that the spoke-SDP is associated with. | |
ac-id — An unsigned integer representing a locally unique identifier for the spoke-SDP. | |
Values | 1 to 4294967295 |
The taii-type2 parameter is mutually exclusive with sdp-id:vc-id parameter.
global-id – The global ID of the far end T-PE of the FEC129 pseudowire. | |
Values | 1 to 4294967295 |
prefix — The prefix on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d |
ac-id — An unsigned integer representing a locally unique identifier for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4294967295 |
Note that when a VCCV trace message is originated from an S-PE node, the user should used the IPv4 reply mode as the replying node does not know how to set the TTL to reach the sending SPE node. If the user attempts this, a warning is issued to use the ipv4 reply mode.
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 back 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.
Values | be, l2, af, l1, h2, ef, h1, nc |
Default | be |
The TOS byte is not modified. Table 20 summarizes this behavior.
Table 20: 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.
src-global-id — The Global ID of the SAII of the targeted static PW FEC element. | |
Values | 1 to 4,294,967,295 |
src-node-id — The node-id on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d |
src-ac-id — An unsigned integer representing a locally unique SAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4,294,967,295 |
dst-global-id – The Global ID of the TAII of the targeted static PW FEC element. | |
Values | 1 to 4,294,967,295 |
dst-node-id — The node-id of the TAII on far end T-PE that the pseudowire being tested is associated with. | |
Values | ipv4-formatted address: a.b.c.d |
dst-ac-id — An unsigned integer representing a locally unique TAII for the pseudowire being tested at the far end T-PE. | |
Values | 1 to 4,294,967,295 |
Output
Trace with detail:
OAM SAA Commands
saa
Syntax
Context
Description
Use this command to start or stop 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 will be generated to indicate a failed attempt to start an SAA test run. A test cannot be started if it is in a continuous state.
OAM Performance Monitoring and Binning Commands
oam-pm
Syntax
Context
Description
This command allows the operator to start and stop on-demand OAM-PM sessions.
Parameters
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 will be 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)
Parameters
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 the command removes the string from the configuration
Parameters
bin-type
Syntax
Context
Description
This command is the start of the hierarchy where the specific delay metric bin structure will be defined.
Parameters
bin
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 will be the bin-number * 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 configured an operator specific threshold. An error will prevent 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 will capture every result above the threshold. Any negative delay metric result will be treated as zero and placed in bin 0.
The no form of the lower-bound 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] is not specified, the traffic crossing alarm will be 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 will not be raised until a measurement interval completes, and the clear threshold has not been exceeded. A clear event will be raised under that condition. In general, alarms are generated when there is a state change. The thresholds configured will be applied to the count in specified bin and all higher number bins.
The no version of this command removes thresholding for this delay metric. The complete command must be configured in order to remove the specific threshold.
Default
[no] delay-events
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 will enter 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 will 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, typing “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, typing “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, typing “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 will fail.
shutdown
Syntax
Context
Description
This command activates and deactivates the bin group. Only the description of the bin group can be modified when the bin group is in a “no shutdown” state. No other changes can be made while the bin group is active. The bin group can only be shutdown and modified when all references in the various PM Sessions or individual tests have been shutdown. If an active PM session is referencing the bin-group, it will generate an error indicating there are x number of active tests referencing the bin-group, and it cannot be shutdown.
The no form of the command activates the bin group as available for PM Sessions and tests to utilize.
Default
shutdown
session
Syntax
Context
Description
This command creates the individual session containers that will house the test specific configuration parameters. Since this session context provides only a container abstract to house the individual test functions, it cannot be shutdown. Individual tests sessions within the container may be shutdown. 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 shutdown. The only exception to this is the description value.
The no form of the command deletes the session.
Parameters
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 the command removes the string from the configuration.
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 the 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 the 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 will divide the hour into four equal sections 00, 15, 30, 45. Clock aligned 1-hour measurement intervals will start at 00. Clock aligned 1-day measurement intervals will start at midnight. Test relative start times will launch 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 will exactly correspond to the clock based measurement interval start time. Clock aligned measurement intervals can include an additional offset. See clock-offset command option under this context.
The no form of the command sets the boundary to the default 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 300 (seconds) will shift the start times of the measurement intervals by five minutes from their default alignments with respect to the time of day clock.
The no form of the command sets the offset to 0.
Parameters
event-mon
Syntax
Context
Description
This hierarchy allows for enabling of 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 and disables the monitoring of all configured delay events. Adding this functionality will start 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 will be suspended. Any existing events at the time of the shutdown will be 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.
Default
[no] delay-events
loss-events
Syntax
Context
Description
This enables and disables the monitoring of all configured loss events. Adding this functionality will start 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 will be suspended. Any existing events at the time of the shutdown will be 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.
Default
[no] loss-events
shutdown
Syntax
Context
Description
Issuing a no shutdown command will start the monitoring of the configured events at the start of the next measurement interval. If a shutdown is issued, all monitoring of configured events, logging, and recording of new events for that session will be suspended. Any existing events at the time of the shutdown will be maintained until the active measurement window in which the event-mon shutdown was issued has completed. The state of this monitoring function can be changed without having to shutdown all the tests in the session.
Default
shutdown
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 will be 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 will get renumbered to maintain the described order. Care must be taken 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 unlikely event both intervals are required the sum total of both cannot exceed 96. The 1-hour and 1-day measurement intervals utilizes their own ranges.
If this command is omitted when configuring the measurement interval, the default values will be used.
Parameters
ethernet
Syntax
Context
Description
This command allows the operator to enter the hierarchy 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 the command removes session parameter.
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 will pass through and does not necessarily map directly to the CoS value on the wire.
The no form of the command removes changes the priority to the default value.
Parameters
source
Syntax
Context
Description
This command defines the source launch point identification Y.1731 parameters that will be used by the individual tests within the session. If an MEP matching the configuration does not exist, the session will be allowed to become active, however the frames sent frames and received as seen under the “show oam-pm statistics session session-name …” will be zero.
The no form of the 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 the command removes the SLM test function from the PM Session.
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 the command removes the DMM test function from the PM Session.
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 the 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.
shutdown
Syntax
Context
Description
This command deactivates computation and reporting of availability metrics for LMM tests.
The no form of the command activates computation and reporting of availability metrics for LMM tests.
Default
shutdown
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 s (100 000 ms). LMM test activation fails if the availability window exceeds the maximum value.
The no form of the command restores the default values for all timing parameters, and uses those values to compute availability and set the loss frequency.
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. This value is not the size of the frame on the wire. It is the size of the addition padding added to the PDU.
The no form of the command removes the optional TVL.
Parameters
shutdown
Syntax
Context
Description
This command activates and deactivates the individual test. When the test is shutdown, no active measurements are being made and any outstanding requests are ignored. If the test is started or stopped during a measurement interval, the suspect flag will be set to yes to indicate that the data for the specific data set is in questionable.
The no form of the command activates the individual test.
Default
shutdown
test-duration
Syntax
Context
Description
This optional command defines the length of time the test will run 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 will stop when the config>oam-pm>session>stop command is issued.
The no form of the command will remove a previously configured test-duration and allow the test to execute until manually stopped.
Default
no test-duration
Parameters
flr-threshold
Syntax
Context
Description
This command defines the frame loss threshold used to determine if the delta-t is available or unavailable. An individual delta-t with a frame loss threshold equal to the configured threshold will be marked unavailable. An individual delta-t with a frame loss threshold lower than the configured threshold will be marked as available.
The no form of the command restores the default value of 50%.
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 10s (10,000ms).
The no form of the command will install 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 “no shutdown” it will always have timing parameters, default or operator configured.
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 the command sets the interval to the default. If an LMM test is in no shutdown it will always have timing parameters, whether default or operator configured.
Parameters
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 that will 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 clear-threshold-percent] is not specified the traffic crossing alarm will be 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 will not be raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event will be raised under that condition.
The no version 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 [clear clear-threshold] is not specified the traffic crossing alarm will be 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 will not be raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event will be raised under that condition.
The no version 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 [clear clear-threshold] is not specified the traffic crossing alarm will be 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 will not be raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event will be raised under that condition.
The no version of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
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 [clear clear-threshold] is not specified, the traffic crossing alarm will be 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 will not be raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event will be raised under that condition.
The no version of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no unavailable-event forward
no unavailable-event backward
no unavailable-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 [clear clear-threshold] is not specified the traffic crossing alarm will be 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 will not be raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event will be raised under that condition.
The no version of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.
Default
no undetermined-available-event forward
no undetermined-available-event backward
no undetermined-available-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] is not specified the traffic crossing alarm will be 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 will not be raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event will be raised under that condition.
The no version 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
LDP Treetrace Commands
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 21 summarizes this behavior.
Table 21: 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
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 option deletes the configuration for the LDP ECMP OAM tree discovery and path probing under this context.
Output
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 22 summarizes this behavior.
Table 22: 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
be
Parameters
path-discovery
Syntax
Context
Description
This command creates the context to configure the LDP ECMP OAM path discovery.
The ingress LER builds the ECM 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 will be 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 he/she wishes 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 will send LSP trace messages to attempt to discover the entire ECMP path tree for a given destination FEC.
The no option resets the interval to its default value.
Default
60
Parameters
max-path
Syntax
Context
Description
This command configures the maximum number of ECMP paths the path discovery will attempt to discover for each run every interval minutes.
The no option resets the timeout to its default value.
Default
128
Parameters
max-ttl
Syntax
Context
Description
This command configures the maximum number of hops the path discovery will trace in the path of each FEC to be discovered.
The no option resets the timeout to its default value.
Default
255
Parameters
policy-statement
Syntax
Context
Description
This command configures the FEC policy to determine which routes are imported from the LDP FEC database for the purpose of discovering 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 will be 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 he/she wishes 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 the 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 option resets the retry count to its default value
Default
3
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 option resets the timeout to its default value.
Default
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 command config>test-oam>ldp-treetrace> path-probing> interval. 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 will not be sent but the ingress LER node will not raise alarms.
The LSP Ping routine should update 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 option resets the interval to its default value.
Default
1
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 option resets the timeout to its default value.
Default
1
Parameters
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 will start to use the new timestamp when they are restarted. When an SR OS node receives an echo request, it will reply with the locally configured timestamp format, and will not try to match the timestamp format of the incoming echo request message.
Default
unix
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 and is the default value. The new Downstream Detailed Mapping (DDMAP) TLV is the new enhanced format specified in RFC 6424.
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 will include 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 will include in this case the DDMAP TLV with the Downstream IP address field set to the all-routers multicast address as per Section 3.3 of RFC 4379. 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.
In order 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
dsmap
Output
TWAMP Commands
twamp
Syntax
Context
Description
This command enables TWAMP functionality.
Default
TWAMP is disabled.
server
Syntax
Context
Description
This command configures the node for TWAMP server functionality.
Default
TWAMP is disabled.
prefix
Syntax
Context
Description
This command configures an IP address prefix containing one or more TWAMP clients. In order 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.
Default
no prefix
Parameters
description
Syntax
Context
Description
Use this command to configure a description for the TWAMP server prefix table.
The no form of the command removes the configuration.
Default
no description
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 the command sets the default value (32).
Default
no max-conn-prefix
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 the command sets the default value (32).
Default
no max-conn-server
Parameters
inactivity-timeout
Syntax
Context
Description
This command configures the inactivity timeout 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 the command sets the default value (1800 s.)
Default
no inactivity-timeout
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 the command sets the default value (32).
Default
no max-sess-prefix
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 the command means to go with a default value of 32.
Default
no max-sessions
Parameters
TWAMP Light 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 12,000 tests. If the maximum value is exceeded, the session reflector will not have memory to allocate to new tests.
The no form of the command sets the default value of 100.
Parameters
reflector
Syntax
Context
Description
Use this command to configure 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 will use 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 will use the destination UDP port that is configured under the router context. Only one udp-port may be configured per unique context.
prefix
Syntax
Context
Description
Use this command to define which TWAMP Light packet prefixes the reflector will process.
The no form of the 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 | |
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 | |
description
Syntax
Context
Description
Use this command to configure 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 the command removes the string from the configuration.
Parameters
shutdown
Syntax
Context
Description
Use this command to disable or enable 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 the command allows the router instance or the service to accept TWAMP Light packets for processing.
Default
shutdown
ip
Syntax
Context
Description
Use this command to enter the context to configure the IP-specific source and destination information, the priority, and the IP test tools on the launch point.
twamp-light
Syntax
Context
Description
This command assigns an identifier to the TWAMP Light test and creates the individual test.
The no form of the command removes the TWAMP Light test function from the OAM-PM session.
Default
no twamp-light
Parameters
source
Syntax
Context
Description
Use this command to define the source IP address that the session controller (launch point) will use for the test. The source address must be a local resident IP address in the context; otherwise, the response packets will not be processed by the TWAMP Light application. Only source addresses configured as part of TWAMP tests will be able to process the reflected TWAMP packets from the session reflector.
The no form of the command removes the source address parameters.
Parameters
x:x:x:x:x:x:d.d.d.d | |
x: | [0 to FFFF]H |
d: | [0 to 255]D |
(no multicast addresses) | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
destination
Syntax
Context
Description
Use this command to define the destination IP address that will be 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 the command removes the destination parameters.
Default
no destination
Parameters
x:x:x:x:x:x:d.d.d.d | |
x: | [0 to FFFF]H |
d: | [0 to 255]D |
(no multicast addresses) | |
dest-udp-port
Syntax
Context
Description
Use this command to define 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 will be responding to this specific TWAMP Light test.
The no form of the command removes the destination UDP port setting.
Default
no dest-udp port
Parameters
source-udp-port
Syntax
Context
Description
Optional command that 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 the command removes the source UDP port setting when the default allocation is used.
Default
dynamic source udp port allocation
Parameters
forwarding
Syntax
Context
Description
Use this optional command to influence 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 the command removes the options and enables the default forwarding logic.
Default
no forwarding
Parameters
x:x:x:x:x:x:d.d.d.d | |
x: | [0 to FFFF]H |
d: | [0 to 255]D |
(no multicast addresses) | |
| Note:
ipv6-address applies to the 7750 SR and 7950 XRS only. |
fc
Syntax
Context
Description
Use this command to set the forwarding class designation for TWAMP Light packets that will be sent through the node and exposed to the various QoS functions on the network element.
The no form of the command restores the default value.
Default
be
Parameters
profile
Syntax
Context
Description
Use this command to define 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 the command restores the default value.
Default
out
Parameters
ttl
Syntax
Context
Description
Use this command to define the value of the TTL field of the packet header.
The no form of the command restores the default value.
Default
225
Parameters
router
Syntax
Context
Description
Use this command to define the source context from which the TWAMP Light packet will be launched. The routing instance and service name must be a VPRN instance.
The no form of the command restores the default value.
Default
base
Parameters
pad-size
Syntax
Context
Description
Use this command to define the amount by which the TWAMP Light packet will be 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 the command removes all padding.
Default
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” will clear 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
delay
Parameters
loss
Syntax
Context
Description
This command configures loss parameters for the TWAMP-Light test.
flr-threshold
Syntax
Context
Description
This command defines the frame loss threshold used to determine if the delta-t is available or unavailable. An individual delta-t with a frame loss threshold equal to or higher than the configured threshold will be marked unavailable. An individual delta-t with a frame loss threshold lower than the configured threshold will be marked as available.
The no form of the command restores the default value of 50%.
Parameters
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 will validate the configuration of the timing parameter regardless of which statistics are being recorded.
The no form of the command will restore the default values for all timing parameters and use those values to compute availability and set the loss frequency.
Parameters
interval
Syntax
Context
Description
Use this command to define the message period, or probe spacing, for transmitting a TWAMP Light frame.
The no form of the command sets the interval to the default value.
Default
1000
Parameters
test-duration
Syntax
Context
Description
This optional command defines the length of time the test will run 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 will stop when the config>oam-pm>session>stop command is issued.
The no form of the command removes a previously configured test-duration value and allows the TWAMP Light test to execute until it is stopped manually.
Default
0
Parameters
shutdown
Syntax
Context
Description
Use this command to stop a TWAMP Light test.
The no form of the command starts a TWAMP Light test.
Default
shutdown
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
Use this command to display 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
Table 23 provides SAA field descriptions.
Table 23: 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. |
twamp
Syntax
Context
Description
This command enables the context for displaying TWAMP information.
client
Syntax
Context
Description
This command displays client TWAMP information.
Parameters
Output
server
Syntax
Context
Description
This command displays server TWAMP information.
Parameters
Output
ldp-treetrace
Syntax
Context
Description
This command displays OAM LDP treetrace information.
Parameters
Output
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
twamp-light
Syntax
Context
Description
This command shows TWAMP-Light reflector information, either for the base router or for a specific service.
Output
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
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 option allow the operator to be specific. If no parameters are include then the entire stack-table will be displayed.
Parameters
Output
domain
Syntax
Context
Description
This command displays domain information.
Parameters
Output
mep
Syntax
Context
Description
This command displays Maintenance Endpoint (MEP) information.
Parameters
Output
mip
Syntax
Context
Description
This command displays SAPs/bindings provisioned for allowing the default MIP creation.
Output
statistics
Syntax
Context
Description
This command displays the ETH-CFM statistics counters.
Output
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
system-info
Syntax
Context
Description
This command displays system-level ETH-CFM information states.
Output
OAM Performance Monitoring and Binning Show Commands
bin-group
Syntax
Context
Description
Show the configuration data for one or all OAM Performance Monitoring bin groups.
Parameters
Output
bin-group-using
Syntax
Context
Description
Show the list of sessions configured against one or all OAM Performance Monitoring bin groups.
Parameters
Output
session
Syntax
Context
Description
Show the configuration and status information for an OAM Performance Monitoring session.
Parameters
Output
sessions
Syntax
Context
Description
This command shows a summary of the OAM Performance Monitoring sessions.
Parameters
Output
statistics
Syntax
Context
Description
Show OAM Performance Monitoring delay or loss statistics. The twamp-light test type only shows statistics that are being recorded. If both delay and loss statistics are being recorded for a test and the test is shut down, and the record-stats command parameter is then modified, only statistics for the current record-stats parameter configuration can be displayed.
When a no shutdown command is entered for any test, the memory is allocated to that test and all stored results for the previous iteration of that test are deleted.
Output
Clear Commands
saa
Syntax
Context
Description
Clear 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
session
Syntax
Context
Description
This command clears the raw measurement interval for the specified session and test.
auto-mep-discovered
Syntax
Context
Description
This clear command provides the necessary mechanism to clear a remote MEP that was auto discovered. The function will clear 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 will be 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 affect on manually configured MEPs.
Default
Clear all auto discovered MEPids
Parameters
statistics
Syntax
Context
Description
This command clears the eth-cfm statistics counters maintained in clearEthCfmStatistics.
Monitor Commands
session
Syntax
Context
Description
This command monitors the raw measurement interval for the specified session and test.
Output
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 the command removes the MEP parameters.
Parameters
mip
Syntax
Context
Description
This command specifies the MIP from which to debug the CFM PDUs.
The no form of the command removes the MIP parameters.
Parameters
packet
Syntax
Context
Description
This command defines the ETH-CFM opcodes of interest to be debugged.
The no form of the 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 will overwrite the previous opcode entries for the MEP or MIP.
lsp-ping-trace
Syntax
Context
Description
This command enables debugging for lsp-ping.
Parameters
Tools Commands
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
top-active-mep
Syntax
Context
Description
This command displays and optionally clears the most active MEPs on the system.
Default
Sorts total in both directions