For descriptions of Router TWAMP Light commands, refer to the Router Configuration Guide.
For descriptions of VPRN TWAMP Light commands, refer to the Services Guide.
This command verifies the reachability of a remote host.
This parameter is used to override the default request message send interval. If the interval is set to 1 s, and the timeout value is set to 10 s, the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This value is used to override the default timeout value.
The shutdown command administratively disables a test. A shutdown can only be performed if a test is not executing at the time the command is entered.
When a test is created, it remains in shutdown mode until a no shutdown command is executed.
In order to modify an existing test, it must first be shut down.
When used with the ethernet>efm-oam command, shutdown enables tunneling on the port (see tunneling), and no shutdown enables Ethernet EFM OAM 802.3ah.
The no form of this command sets the state of the test to operational.
shutdown
This command determines the route to a destination address.
The following output is an example of traceroute information.
This command is used to display relevant multicast information from the target multicast router. Information displayed includes adjacency information, protocol, metrics, thresholds, and flags from the target multicast router. This information can be used by network operators to determine whether bidirectional adjacencies exist.
The following output is an example of mrinfo information, and Table 11 describes the fields. In the example, the target router has IP address 200.200.200.1.
Label | Description |
General flags | |
version | The software version on the queried router |
prune | Indicates that the router understands pruning |
genid | Indicates that the router sends generation IDs |
mtrace | Indicates that the router handles mtrace requests |
Neighbors flags | |
? | Indicates that the IPAddr to Name conversion in DNS is not found |
1 | The metric |
0 | The threshold (multicast time-to-live) |
pim | Indicates that PIM is enabled on the interface |
down | The operational status of the interface |
disabled | The administrative status of the interface |
leaf | Indicates that there are no downstream neighbors on the interface |
querier | Indicates that the interface is an IGMP querier |
tunnel | The neighbor reached via the tunnel |
This command traces a multicast path from a source to a receiver and displays multicast packet rate and loss information. The mstat command adds the capability to show the multicast path in a limited graphic display and provides information about drops, duplicates, TTLs, and delays at each node. This information is useful to network operators because it identifies nodes with high drop and duplicate counts. Duplicate counts are shown as negative drops.
The following output is an example of mstat information, and Table 12 describes the fields.
For each interface between two nodes, a line is displayed. Note the following:
To follow the packet, start at Source and read down to Receiver. To count the number of hops, read back up fromQuery Source to Response Dest. The example below shows two hops between Query Source and Response Dest.
Label | Description |
Source | The start (“Source”) of the trace |
Response Dest | The name of the router for this hop or “?” when there is no reverse DNS translation |
rtt | The round-trip time |
Overall Mcast Pkt Rate | The overall multicast packet rate (that is, the average multicast packet rate across the router), expressed in pps (packets per second) |
Packet Statistics For Traffic From (source) To (group) | The packet statistics from the specified source to the specified multicast group |
Lost/Sent = Pct Rate | The number of packets lost and sent, expressed as a percentage and as a rate |
Receiver | The end (“Receiver”) of the trace |
Query Source | The query source address. On the 7705 SAR, the query source is the receiver-end router, which generates queries to determine if there is a path to the source once a receiver is available. The query source and the response destination are the same. |
This command traces the multicast path from a source to a receiver by passing a trace query hop-by-hop along the reverse path from the receiver to the source. At each hop, information such as the hop address, routing error conditions, and packet statistics are gathered and returned to the requester. A network administrator can determine where multicast flows stop and verify the flow of the multicast stream.
The following output is an example of mtrace information, where each line consists of fields separated by a space. If the output was formatted as a table, it would look like the following:
Table 13 describes the fields.
Field | Description |
Hop | The number of hops from the source to the listed router. The “-” sign indicates that the TTL value is decremented by 1 after each hop. |
Router Name | The name of the router for this hop. If a DNS name query is not successful, a “?” displays. |
(Address) | The address of the router for this hop |
Protocol | The protocol used |
TTL | The forward TTL threshold, which is the TTL that a packet is required to have before it will be forwarded over the outgoing interface The TTL default value of 1 s cannot be changed for multicast control messages because the packets are not forwarded beyond the next-hop router |
Forwarding Code | The forwarding information/error code for this hop |
This command tests ATM path connectivity on an ATM VCC.
This command is not supported on ATM VCC SAPs that are members of a SAP aggregation group.
This value is used to override the default timeout value.
If the interval is set to 1 s, and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This parameter is used to override the default request message send interval.
This command 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 encapsulation from the far-end 7705 SAR. OAM request messages sent within an IP SDP must have the “DF” IP header bit set to 1 to prevent message fragmentation.
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 a response timeout occurs, the maximum size message replied to indicates the largest size OAM request message that received a valid reply.
To terminate an sdp-mtu in progress, use the CLI break sequence <Ctrl-C>.
![]() | Note: The sdp-mtu command probes the far-end port using the configured MTU of the near-end port, not the configured MTU of the far-end port. For example, a far-end port that is physically capable of receiving jumbo frames would respond to sdp-mtu probes up to the jumbo frame size, regardless of the configured MTU of the far-end port. This assumes that the intermediate transport network can switch frames of this size. |
If the incremented size exceeds the end-octets value, no more messages will be sent.
This value is used to override the default timeout value.
If the interval is set to 1 s, and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This parameter is used to override the default request message send interval.
The following output is an example of SDP MTU path test information.
This command tests a service ID for correct and consistent provisioning between two service endpoints. The 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:
Unlike sdp-ping, only a single message will be sent per command; no count or interval parameter is supported and round-trip time is not calculated. A timeout value of 10 s 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 an svc-ping in progress, use the CLI break sequence <Ctrl-C>.
Upon request timeout, message response, request termination, or request error, the local and remote information described in Table 14 will be displayed. Local and remote information is dependent upon service existence and reception of reply.
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 Service-ID being tested | Service-ID |
Local Service Type | The type of service being tested. If service-id does not exist locally, N/A is displayed. | Apipe, Epipe, Fpipe, Hpipe |
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. | Apipe, Epipe, Fpipe, Hpipe |
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 a 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. The sdp-ping command 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 7705 SAR 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 | Indicates whether the originating 7705 SAR used the originating SDP-ID to send the svc-ping request. If a valid originating SDP-ID is found, is operational and has a valid egress service label, the originating 7705 SAR should use the SDP-ID as the requesting path if sdp-path has been defined. If the originating 7705 SAR uses the originating SDP-ID as the request path, Yes is displayed. If the originating 7705 SAR 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 shut down, 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-Down | ||
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-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 | ||
Originating SDP-ID Binding Oper State | The local operational state of the originating 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 | ||
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 7705 SAR 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 7705 SAR that is bound to the service-id, Non-Existent is displayed. | resp-sdp-id |
Non-Existent | ||
Responding SDP-ID Path Used | Indicates whether the responding 7705 SAR 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, is operational and has a valid egress service label, the far-end 7705 SAR 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-Down | ||
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 7705 SAR considers the displayed egress service label operational, Up is displayed. If the originating 7705 SAR 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 7705 SAR for this service-id to the originating 7705 SAR. If service-id does not exist in the remote 7705 SAR, 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 considers its egress service label operational, Up is displayed. If the responding 7705 SAR 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 7705 SAR. 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 originator’s 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 7705 SAR considers its ingress service label operational, Up is displayed. If the originating 7705 SAR 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 7705 SAR. This is the service label that the far end is expecting to receive for service-id when sending to the originating 7705 SAR. If service-id does not exist in the remote 7705 SAR, N/A is displayed. If service-id exists, but an ingress service label has not been assigned in the remote 7705 SAR, 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 7705 SAR. If the ingress service label is manually defined on the remote 7705 SAR, Manual is displayed. If the ingress service label is dynamically signaled on the remote 7705 SAR, Signaled is displayed. If the service-id does not exist on the remote 7705 SAR, N/A is displayed. | Manual |
Signaled | ||
N/A | ||
Responders Ingress Service Label State | The assigned ingress service label state on the remote 7705 SAR. If the remote 7705 SAR considers its ingress service label operational, Up is displayed. If the remote 7705 SAR considers its ingress service label inoperative, Down is displayed. If the service-id does not exist on the remote 7705 SAR or the ingress service label has not been assigned on the remote 7705 SAR, N/A is displayed. | Up |
Down | ||
N/A |
This is a mandatory parameter.
If local-sdp is specified, the command attempts to use an egress SDP-ID bound to the service with the specified far-end IP address with the VC-Label for the service. The far-end address of the specified SDP-ID is the expected responder-id within the reply received. The SDP-ID defines the SDP tunnel encapsulation used to reach the far end — GRE, IP, or MPLS. On originator egress, the service-ID must have an associated VC-Label to reach the far-end address of the SDP-ID and the SDP-ID must be operational for the message to be sent.
If local-sdp is not specified, the svc-ping request message is sent with GRE encapsulation with the OAM label.
Table 15 indicates whether a message is sent and how the message is encapsulated based on the state of the service ID.
Local Service State | local-sdp Not Specified | local-sdp Specified | ||
Message Sent | Message Encapsulation | Message Sent | Message Encapsulation | |
Invalid Local Service | Yes | Generic IP/GRE OAM (PLP) | No | None |
No Valid SDP-ID Bound | Yes | Generic IP/GRE OAM (PLP) | No | None |
SDP-ID Valid But Down | Yes | Generic IP/GRE OAM (PLP) | No | None |
SDP-ID Valid and Up, But No Service Label | Yes | Generic IP/GRE OAM (PLP) | No | None |
SDP-ID Valid, Up and Egress Service Label | Yes | Generic IP/GRE OAM (PLP) | Yes | SDP Encapsulation with Egress Service Label (SLP) |
If remote-sdp is specified, the far-end responder attempts to use an egress SDP-ID bound to the service with the message originator as the destination IP address with the VC-Label for the service. The SDP-ID defines the SDP tunnel encapsulation used to reply to the originator — GRE, IP, or MPLS. On responder egress, the service-ID must have an associated VC-Label to reach the originator address of the SDP-ID and the SDP-ID must be operational for the message to be sent. If remote-sdp is not specified, the svc-ping request message is sent with GRE encapsulation with the OAM label.
Table 16 indicates how the message response is encapsulated based on the state of the remote Service ID.
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) |
The following output is an example of SVC ping information.
This command enables Ethernet in the First Mile (EFM) OAM loopbacks on the specified port. The EFM OAM remote loopback OAMPDU will be sent to the peering device to trigger a remote loopback.
This command enables local loopback tests on the specified port.
This command enables remote EFM OAM loopback tests on the specified port. The EFM OAM remote loopback OAMPDU will be sent to the peering device to trigger a remote loopback.
This command enables access to the context to configure Ethernet port attributes.
This command configures EFM OAM attributes.
This command enables reactions to loopback control OAMPDUs from peers.
The no form of this command disables reactions to loopback control OAMPDUs.
This command sets the amount of time that EFM-OAM will wait before going from a non-operational state to an operational state.
If EFM-OAM goes from an operational state to a non-operational state (other than link-fault), it enters the hold-time period. During this time, EFM-OAM continues to negotiate with the peer if possible, but will not transition to the “up” state until the hold time has expired.
If EFM-OAM goes down due to a lower-level fault (for example, the port goes down and EFM-OAM enters the link-fault state), the hold timer is not triggered. When the lower-level fault is cleared, EFM-OAM immediately starts running on the port and transitions to the operational state as soon as possible.
If EFM-OAM goes down because the user administratively disables the protocol, EFM-OAM immediately transitions to the disabled state. When the user re-enables EFM-OAM, the protocol enters the hold time period and EFM-OAM is not operational until the hold time expires. A hold-time value of 0 indicates that EFM-OAM returns to the operational state without delay.
The hold time affects only the transition from a non-operational state to an operational state; it does not apply to a transition from an operational state to a non-operational state.
This command configures the mode of OAM operation for this Ethernet port.
Active mode causes the port to initiate the negotiation process and continually send out EFM OAM information PDUs. Passive mode waits for the peer to initiate the negotiation process. A passive mode port cannot initiate monitoring activities (such as loopback) with the peer.
active
This command configures the transmit interval of OAMPDUs.
This command enables EFM OAMPDU tunneling. OAMPDU tunneling is required when a loopback is initiated from a router end and must be transported over the existing network infrastructure to the other end. Enabling tunneling will allow the PDUs to be mapped to Epipes so that the OAM frames can be tunneled over MPLS to the far end. To enable Ethernet EFM OAM 802.3ah on the port, use the efm-oam>no shutdown command. The no form of the command disables tunneling.
This command specifies to initiate an Ethernet (signal) test.
This command specifies to initiate a linktrace test.
This command specifies to initiate a loopback test.
This command specifies to initiate an ETH-CFM one-way delay test.
This command specifies to initiate an ETH-CFM two-way delay test.
This command specifies to initiate an Ethernet CFM two-way SLM test.
This command specifies to initiate a loss measurement test between the specified mac-address router and the specified mep-id MEP.
Single-ended and dual-ended loss tests are mutually exclusive tests. Single-ended loss tests can be run when dual-ended loss tests are disabled (under the config>service>epipe>spoke-sdp>eth-cfm>mep or config>router>if>eth-cfm>mep context).
This command enables the context to configure 802.1ag Connectivity Fault Management (CFM) parameters.
This command configures CFM domain parameters.
The dns, mac, and string keywords apply to dot1ag. The none keyword applies to Y.1731. If the none keyword is used, the association command must use the icc-based or string format. A MEP associated with domain format none and association format icc-based is a Y.1731 MEP. A MEP associated with domain format none and association format string is a Y.1731 MEP that can interoperate with a dot1ag MEP. All other configurations are associated with dot1ag MEPs.
The no form of the command removes the MD index parameters from the configuration.
This command configures the Maintenance Association (MA) for the domain.
The integer, string, vid, and vpn-id keywords apply to dot1ag MAs. The icc-based keyword applies to Y.1731 MEGs, and is only available when the domain format is none. A MEP associated with domain format none and association format icc-based is a Y.1731 MEP. A MEP associated with domain format none and association format string is a Y.1731 MEP that can interoperate with a dot1ag MEP. All other configurations are associated with dot1ag MEPs.
This command configures the service ID for the domain association. The bridge-id should be configured to match the service-id of the service where MEPs for this association will be created. For example, for Epipe service-id 2, set the bridge-id to 2. There is no verification that the service with a matching service-id exists.
This command does not apply to facility MEPs on network interfaces, as these MEPs are not bound to a service.
This command configures the bridge-identifier primary VLAN ID. This command is informational only; no verification is done to ensure that MEPs on this association are on the configured VLAN.
This command configures the CCM transmission interval for all MEPs in the association, in milliseconds and seconds.
The no form of the command reverts to the default value.
10 s
This command configures the remote maintenance association endpoint MEP identifier.
This command enables the context to configure ITU-T Synthetic Loss Measurement (ETH-SL).
This command configures the time that the responder keeps a test active. If the time between packets exceeds this value within a test, the responder marks the previous test as complete. It treats any new packets from a peer with the same test-id, source MAC address, and MEP-ID as a new test, and indicates this by responding with the sequence number 1.
100 s
This command enables the port to respond to LBM messages and sets the queuing and scheduling conditions for handling CFM LBM frames. The user selects the desired QoS treatment by enabling the CFM loopback and including the high or low priority with the high or low keyword. The queue parameters and scheduler mappings associated with the high and low keywords are preconfigured and cannot be altered by the user.
The priority dot1p and match-vlan keywords apply only to physical ring ports on the 2-port 10GigE (Ethernet) Adapter card/module.
The parameters and mappings have the following settings:
CFM loopback support on a physical ring port on the 2-port 10GigE (Ethernet) Adapter card/module differs from other Ethernet ports. For these ports, cfm-loopback is configured using dot1p and an optional list of up to 16 VLANs. The null VLAN is always applied. The CFM Loopback Message will be processed if it does not contain a VLAN header, or if it contains a VLAN header with a VLAN ID that matches one in the configured match-vlan list.
The no form of the command disables the handling of CFM loopback frames.
no cfm-loopback
This command keeps an 802.1ag or Y.1731 maintenance association endpoint (MEP) in operation regardless of the operational state of the SAP. The MEP remains in operation when the SAP is down or non-operational.
The no form of the command disables the MEP from remaining in operation when the SAP is down or non-operational.
enabled
This command provisions an 802.1ag or a Y.1731 maintenance association endpoint (MEP).
The 7705 SAR supports Up and Down MEPs on Ethernet SAPs (802.1ag and Y.1731), Down MEPs on Ethernet spoke SDPs (802.1ag only), and facility MEPs on network interfaces (802.1ag and Y.1731).
The no form of the command reverts to the default values.
This command enables the generation and the reception of AIS messages and applies to Y.1731 SAP MEPs only.
disabled
This command configures the client Maintenance Entity Group (MEG) levels to use for AIS message generation. Up to seven levels can be provisioned, with the restriction that the client (remote) MEG level must be higher than the local MEG level.
This command specifies the transmission interval of AIS messages in seconds.
This command specifies the priority of AIS messages originated by the MEP, which is used for priority-mapping OAM frames.
This command enables the generation of CCM messages.
The no form of the command disables the generation of CCM messages.
This command specifies the priority value for Continuity Check messages (CCMs) and linktrace messages (LTMs) transmitted by the MEP.
The default priority is 7, which means that CCM frames map to the NC forwarding class by default.
The no form of the command removes the priority value from the configuration.
7
This command allows the receiving MEP to ignore the specified TLVs in the ETH CCM PDU. Ignored TLVs will be reported as absent and will have no effect on the MEP.
The no form of the command causes the receiving MEP to process all recognized TLVs in the ETH CCM PDU.
n/a
This command creates a text description of a MEP. The description can be changed at any time, even while the server is running.
The no form of the command removes the description.
no description
This command enables dual-ended loss measurement testing on a MEP. When enabled, the test runs in the background.
CCM must be enabled before the dual-ended loss measurement test can be enabled.
The dual-ended and single-ended loss measurement tests are mutually exclusive tests. When the dual-ended loss measurement test is enabled, the single-ended test is not available.
The no form of the command disables the dual-ended loss measurement test.
This command applies only to Y.1731 MEPs.
enabled
This command specifies the alarm threshold ratio for frame loss measurement, where percentage is defined as (the total number of Tx frames) divided by (the total number of frames dropped) expressed as a percentage. When the alarm threshold is reached, an alarm is raised.
The no form of the command removes the priority value from the configuration. Setting the percentage to 0.00 is equivalent to using the no form of the command.
This command configures a clearing alarm threshold for frame loss measurement, where percentage is defined as (the total number of Tx frames) divided by (the total number of frames dropped) expressed as a percentage.
If a dual-ended-loss alarm is outstanding and the alarm-clear-threshold is configured to a non-zero value, the dual-ended-loss clear alarm will not be raised until the dual-ended-loss ratio drops below the alarm-clear-threshold. If the alarm-clear-threshold is configured to 0, the dual-ended-loss clear alarm is raised immediately when the dual-ended-loss ratio drops below the alarm threshold.
This functionality prevents too many alarms from being generated if the loss ratio is toggling above and below the alarm threshold.
The alarm-clear-threshold cannot be greater than the alarm-threshold.
Setting the percentage to 0 means that no alarm-clear-threshold is configured; clear alarm traps will continue to be sent when the loss ratio is no longer above the alarm threshold. This is equivalent to using the no form of the command.
This command enables an Ethernet (signal) test (ETH-Test) on a MEP. When enabled, the test runs in the background. This command applies to Y.1731 MEPs only.
For this test, operators must configure ETH-Test parameters on both sender and receiver nodes. The ETH-Test can then be run using the following OAM command:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
A check is done on the provisioning and the test commands to ensure that the MEP is a Y.1731 MEP. If the MEP is not a Y.1731 MEP, the operation fails and an error message in the CLI and SNMP will indicate the problem. A Y.1731 MEP has domain format none and association format icc-based or string (the string keyword enables the Y.1731 MEP to interoperate with a dot1ag MEP).
The no form of the command disables the ETH-Test on a MEP.
enabled
This command configures a threshold for raising SNMP traps for one-way CFM tests.
For bit-error-threshold tests, test results are available only at the destination node. In order for the network management system to collect the results, SNMP traps need to be raised. This threshold is used to control when to raise a trap. When the number of bit errors reaches the threshold, an SNMP trap is raised.
Configuring a threshold value of 0 will cause the node to raise an SNMP trap for every one-way test it receives.
This command configures the test pattern for ETH-Test frames.
The no form of the command removes the values from the configuration.
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
remErrXcon
This command configures a threshold for raising SNMP traps for one-way CFM tests.
For one-way-delay-threshold tests, test results are available only at the destination node. In order for the network management system to collect the results, SNMP traps need to be raised. This threshold is used to control when to raise a trap. When the delay time reaches the threshold, an SNMP trap is raised.
Configuring a threshold value of 0 will cause the node to raise an SNMP trap for every one-way test it receives.
This command enables the CPE-initiated F5 OAM loopback testing for an ATM bonding group on a DSL port.
After completing a loopback, you can run a show port command to see the results of the test.
This command enables the context to configure the SAA tests.
This command identifies a test and creates or modifies 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 must be shut down before it can be modified or removed from the configuration.
The no form of this command removes the test from the configuration.
This command associates an accounting policy to the SAA test. The accounting policy must already be defined before it can be associated or else an error message is generated.
A notification (trap) is issued when a test is completed.
The no form of this command removes the accounting policy association.
This command creates a text description stored in the configuration file for a configuration context.
The no form of this command removes the string from the configuration.
no 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.
This command specifies that at the termination of an SAA test probe, the calculated jitter value is evaluated against the configured rising and falling jitter thresholds. SAA threshold events are generated as required.
Once the threshold (rising/falling) is crossed, it is disabled from generating additional events until the opposite threshold is crossed. If a falling threshold is not supplied, the rising threshold will be re-enabled when it falls below the threshold after the initial crossing that generated the event.
The configuration of jitter event thresholds is optional.
This command 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.
The configuration of latency event thresholds is optional.
This command specifies that at the termination of an SAA test run, the calculated loss event value is evaluated against the configured rising and falling loss event thresholds. SAA threshold events are generated as required.
The configuration of loss event thresholds is optional.
This command enables the context to configure SNMP trap generation for the SAA test.
This command works in conjunction with the probe-fail-threshold command. The command enables the generation of an SNMP trap after threshold consecutive probe failures 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.
This command works in conjunction with the probe-fail-enable command. When the probe-fail-enable command is enabled, the generation of an SNMP trap occurs after threshold consecutive probe failures during the execution of the SAA ping test. This command is not applicable to SAA trace route tests.
This command has no effect when the probe-fail-enable command is disabled.
The no form of the command returns the threshold value to the default.
1
This command enables the generation of an SNMP trap when an SAA test completes.
The no form of the command disables the trap generation.
This command enables the generation of an SNMP 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 threshold parameter.
The no form of the command disables the trap generation.
This command configures the threshold for SNMP trap generation on test failure. This command is not applicable to SAA trace route tests.
This command has no effect when the test-fail-enable command is disabled.
The no form of the command returns the threshold value to the default.
1
This command enables 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 shutdown 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.
This ping utility determines the IP connectivity to a CPE within a specified VPLS service.
If the interval is set to 1 s and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This command configures an Ethernet CFM linktrace test in SAA.
This command configures an Ethernet CFM loopback test in SAA.
This command configures an Ethernet CFM two-way delay test in SAA.
This command specifies an Ethernet CFM two-way SLM test in SAA.
This command configures an ICMP ping test.
This parameter is used to override the default request message send interval. If the interval is set to 1 s, and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This value is used to override the default timeout value.
This command configures an ICMP traceroute test.
This command performs in-band LSP connectivity tests using the protocol and data structures defined in 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.
The detail parameter is available only from the oam context.
ipv4-address: | a.b.c.d |
mask: | value must be 32 |
The LSP-EXP mappings on the receive network interface control the mapping back to the internal forwarding class used by the far-end 7705 SAR that receives the message request. The egress mappings of the egress network interface on the far-end 7705 SAR control the forwarding class markings on the return reply message.
The LSP-EXP mappings on the receive network interface control the mapping of the message reply back at the originating 7705 SAR.
This value is used to override the default timeout value.
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.
This parameter is used to override the default request message send interval.
This command displays the hop-by-hop path for an LSP traceroute using the protocol and data structures defined in RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.
The LSP 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.
In an LSP traceroute, 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 allows the sender and responder nodes to exchange and validate interface and label stack information for each downstream hop in an LDP FEC path, RSVP LSP, or a BGP- labeled IPv4 route. If the responder node has multiple, equal-cost, next hops for an LDP FEC or a BGP- labeled IPv4 prefix, it replies in the downstream mapping TLV with the downstream information of each outgoing interface that 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.
The detail parameter is available only from the oam context.
ipv4-address: | a.b.c.d |
mask: | value must be 32 |
The LSP-EXP mappings on the receive network interface control the mapping back to the internal forwarding class used by the far-end 7705 SAR that receives the message request. The egress mappings of the egress network interface on the far-end 7705 SAR control the forwarding class markings on the return reply message.
The LSP-EXP mappings on the receive network interface control the mapping of the message reply back at the originating 7705 SAR.
This value is used to override the default timeout value.
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.
This parameter is used to override the default request message send interval.
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 plane.
A MAC ping reply can be sent using the control plane or the data 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 an FDB 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. If the MAC trace originated from a non-zero SHG, the packets will not go out to the same SHG.
If the interval is set to 1 s and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This command populates the FDB with an OAM-type MAC entry indicating the node is the egress node for the MAC address, and it optionally floods the OAM MAC association throughout the service. 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 for the MAC address is forwarded to the control plane (CSM). As a result, if the service on the node has neither an FDB nor an egress SAP, then it is not allowed to initiate a mac-populate command.
The MAC address that is populated in the FDB in the provider network is given a type OAM, so that it can be treated distinctly from regular dynamically learned or statically configured MACs. 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 the mac-populate command forces the MAC in the table to be type OAM in case it already exists as a dynamic, static, or an OAM-induced learned MAC with some other type of binding. An OAM-type MAC cannot be overwritten by dynamic learning and allows customer packets with the MAC to either ingress or egress the network while still using the OAM MAC entry.
The flood option causes each upstream node to learn the MAC (that is, populate the local FDB with an OAM MAC entry) and to flood the request along the data plane using the flooding domain. The flooded mac-populate request can be sent via the data plane or the control 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.
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 command or with an FDB clear operation.
When a 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.
When the target-sap sap-id value is not specified, the MAC is bound to the CSM. 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.
This command removes an OAM-type MAC entry from the FDB and optionally floods the OAM MAC removal throughout the service. A mac-purge command 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. When sending the MAC purge using the control plane, the packet is sent directly to the system IP address of the next hop.
A MAC address is purged only if it is marked as OAM. A mac-purge request is a packet with the following fields: the Reply Flags is set to 0 (since no reply is expected), and the Reply Mode and Reserved fields are set to 0. The Ethernet header has the source set to the (system) MAC address and 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 can be sent via the data plane or the control plane. The send-control option specifies that the request be sent using the control plane. If send-control is not specified, the request is sent using the data plane.
The register option reserves the MAC for OAM testing where it is no longer an active MAC in the FDB for forwarding, but it is retained in the FDB as a registered OAM MAC. Registering an OAM MAC prevents relearns for the MAC based on customer packets. Relearning a registered MAC can only be done through a mac-populate request. The originating SHG is always 0 (zero).
The force option causes the specified OAM-type MAC entry to be purged from the FDB even if the entry was created by another node.
This command displays the hop-by-hop path for a destination MAC address within a VPLS. The MAC 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 address. The MAC trace command uses Nokia OAM packets with increasing TTL values to determine the hop-by-hop route to a destination MAC.
In a MAC trace, 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 through the control plane or data plane and waits for 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. If the MAC ping originated from a non-zero SHG, the packets will not go out to the same SHG.
If the interval is set to 1 s, and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
This command performs an in-band connectivity test for an LDP point-to-multipoint LSP. An echo request message is sent on the active point-to-multipoint instance and is replicated in the data path over all branches of the point-to-multipoint LSP instance. By default, all egress LER nodes that are leaves of the point-to-multipoint LSP instance will reply to the echo request message.
An LDP point-to-multipoint generic identifier that includes the source IP address of the root node can be used to uniquely identify an LDP point-to-multipoint LSP in a network. The LDP p2mp-identifier is a mandatory parameter needed for the LSP ping test. The LDP P2MP ID specified when configuring a tunnel interface on the root node must be used as the 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 five addresses can be specified in a single run of the p2mp-lsp-ping command. An LER node parses the list of egress LER addresses, and if its address is included in the list, it will send back an echo reply message.
Without the detail option, the output of the command provides a high-level summary of error codes and success codes received. With the detail option, the output of the command shows a line for each replying node (similar to the output of the LSP ping for a point-to-point LSP).
The output display is delayed until all responses are received or the timer configured for the timeout parameter has expired. No other CLI commands can be entered while waiting for the display. The CLI break sequence <Ctrl-C> aborts the ping operation.
When an MPLS echo request packet is generated in the CSM 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 bits is dictated by the LSP-to-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-to-EXP mappings of the incoming interface.
When an MPLS echo reply packet is generated in the CSM 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 EXP bits is dictated by the LSP-to-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 17 summarizes this behavior.
CSM (sender node) | Echo request packet:
|
Outgoing interface (sender node) | Echo request packet:
|
Incoming interface (responder node) | Echo request packet:
|
CSM (responder node) | Echo reply packet:
|
Outgoing interface (responder node) | Echo reply packet:
|
Incoming interface (sender node) | Echo reply packet:
|
This command tests SDPs for unidirectional 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 unidirectional 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. Table 18 displays the response messages sorted by precedence.
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 |
Field | Description | Values |
Request Result | The result of the sdp-ping request message | Sent - Request Timeout |
Sent - Request Terminated | ||
Sent - Reply Received | ||
Not Sent - Non-Existent Local SDP-ID | ||
Not Sent - Local SDP-ID Down | ||
Originating SDP-ID | The originating SDP-ID specified by orig-sdp | orig-sdp-id |
Originating SDP-ID Administrative State | The local administrative state of the originating SDP-ID. If the SDP-ID has been shut down, Admin-Down is displayed. If the originating SDP-ID is in the no shutdown state, Admin-Up is displayed. If the orig-sdp-id does not exist, Non-Existent is displayed. | Admin-Up |
Admin-Down | ||
Non-Existent | ||
Originating SDP-ID Operating State | The local operational state of the originating SDP-ID. If orig-sdp-id does not exist, N/A 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 7705 SAR 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 7705 SAR 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 7705 SAR but is not valid for the originating 7705 SAR, Invalid is displayed. When resp-sdp-id does not exist on the far-end 7705 SAR, 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 originator’s SDP-ID from the perspective of the remote 7705 SAR 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 |
The request number is a sequential number starting with 1 and ending with the last request sent, incrementing by 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 toward the average round-trip time.
This is an optional parameter.
The DSCP or LSP-EXP mappings on the receive network interface control the mapping back to the internal forwarding class used by the far-end 7705 SAR that receives the message request. The egress mappings of the egress network interface on the far-end 7705 SAR control the forwarding class markings on the return reply message.
The DSCP or LSP-EXP mappings on the receive network interface control the mapping of the message reply back at the originating 7705 SAR. This is displayed in the response message output upon receipt of the message reply.
When the OAM message request is encapsulated in an 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.
This value is used to override the default timeout value.
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.
This parameter is used to override the default request message send interval.
The following outputs are examples of SDP ping information.
This command configures a virtual circuit connectivity verification (VCCV) ping test. A VCCV ping test checks connectivity of a VLL in-band. 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 data plane and the control plane. The test is in-band, 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. VCCV ping reuses an LSP ping message format and can be used to test a VLL configured over an MPLS, GRE, or IP SDP.
VCCV ping can be initiated on the terminating provider edge (T-PE) router or the switching provider edge (S-PE) router. The 7705 SAR can function as an S-PE or T-PE. If initiated on the S-PE, the reply-mode parameter must be used with the ip-routed value. The ping from the T-PE can have values or the values can be omitted.
VCCV ping can be initiated on a node with MC-LAG or MC-APS configured on it. If the node is in standby mode, and ICB is configured on the service, the reply-mode parameter must be used with the ip-routed value.
If a VCCV ping is initiated from a T-PE to a neighboring S-PE (one segment only), only the sdp-id:vc-id parameter must be used. However, if the ping is across two or more segments, the sdp-id:vc-id, src-ip-address ip-addr, dst-ip-address ip-addr, ttl vc-label-ttl and pw-id pw-id parameters must be used, where:
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.
This is a mandatory parameter.
This is a mandatory parameter.
The LSP-EXP mappings on the receive network interface control the mapping back to the internal forwarding class used by the far-end 7705 SAR that receives the message request. The egress mappings of the egress network interface on the far-end router control the forwarding class markings on the return reply message.
The LSP-EXP mappings on the receive network interface control the mapping of the message reply back at the originating SAR.
This value is used to override the default timeout value.
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.
This parameter is used to override the default request message send interval.
The following outputs are examples of VCCV ping information.
Ping from T-PE to T-PE:
Ping from T-PE to S-PE:
Ping from S-PE (on single or multi-segment):
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 terminating PE (T-PE) or at a switching PE (S-PE). VCCV trace 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 TTL values, 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) includes the next-hop S-PE targeted LDP session source address in the Remote PE Address field of the PW FEC TLV. Each S-PE that terminates and processes the message will include the FEC 128 TLV corresponding to the PW segment to its downstream node in the MPLS echo reply message.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.
VCCV trace can be initiated on a node with MC-LAG or MC-APS configured on it. If the node is in standby mode, and ICB is configured on the service, the reply-mode parameter must be used with the ip-routed value.
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 should be configured accordingly. However, the T-PE or 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.
If the interval is set to 1 s and the timeout value is set to 10 s, then the maximum time between message requests is 10 s and the minimum is 1 s. This depends upon the receipt of a message reply corresponding to the outstanding message request.
The LSP-EXP mappings on the receive network interface control 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 control the forwarding class markings on the return reply message. The LSP-EXP mappings on the receive network interface control the mapping of the message reply back at the originating router.
The following outputs are examples of VCCV trace information.
Trace with detail:
This command performs a VPRN ping.
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 following output is an example of VPRN ping information.
This command performs a VPRN trace.
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 following output is an example of VPRN trace information.
This command is a global command that enables and disables one-way timestamping of outbound SAA ICMP ping packets. Enabling one-way timestamping on a 7705 SAR node requires enable-icmp-vse to be set on both the near-end and far-end nodes. The current status can be seen on the show>system>information CLI display.
The -vse part of the command means vendor-specific extension.
The no form of this command disables one-way timestamping.
no enable-icmp-vse
This command initiates an ITU-T Y.1564 test for throughput and bandwidth testing of Ethernet point-to-point virtual circuits. The test is run using sets of threshold and payload values that are configured under testhead-profile and frame-payload. You can run tests with up to four parallel flows by specifying up to four frame payload IDs in order to create IMIX-type traffic patterns.After a test is complete, the system raises an SNMP trap.
Before initiating a test, you must also enable an Ethernet loopback with the loopback command, in order to send the test packets back to the source for measuring and analyzing. No checks are performed to verify that a remote SAP loopback is enabled
This command configures the source MAC address for Y.1564 test head marker packets.
The default value is all zeros. It is recommended that users provision this values to a unique value for the tested network, since the packet will not traverse Layer 2 networks.
This command creates an ITU-T Y.1564 test head profile. The test head acts like a template that can be configured with groupings of threshold and frame payload values in order to create a variety of IYU-T Y.1564 tests.
On adapter cards, one test head is supported per card. On the 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-M, 7705 SAR-W, and 7705 SAR-Wx, one test head is supported per node. On the 7705 SAR-X, one test head is supported on MDA 2 and one on MDA 3.
This command configures a group of acceptance criteria thresholds, such as packet loss and jitter, to be associated with an ITU-T Y.1564 test head.
The no form of this command deletes the acceptance criteria group and all threshold values configured under it.
This command configures the CIR threshold associated with the ITU-T Y.1564 test head.
no cir-threshold
This command configures the jitter rising threshold value. The threshold value is compared to the jitter rising value reported by a Y.1564 test and a failure is reported if the jitter rising value is greater than or equal to the configured threshold.
If an in-profile or out-of-profile jitter rising threshold is configured, that threshold value is used instead for comparison when an ITU-T Y.1564 test head color-aware test is run.
The no form of the command disables jitter rising threshold comparison after a Y.1564 test.
no jitter-rising-threshold
This command configures the in-profile jitter rising threshold value. If an in-profile or out-of-profile jitter rising threshold is configured, that threshold value is used for comparison when a Y.1564 test head color-aware test is run, instead of the jitter-rising-threshold value. When a non-color-aware test is performed, these values are ignored.
The no form of this command disables jitter rising threshold comparison after a Y.1564 test.
no jitter-rising-threshold-in
This command configures the out-of-profile jitter rising threshold value. If an in-profile or out-of-profile jitter rising threshold is configured, that threshold value is used for comparison when a Y.1564 test head color-aware test is run, instead of the jitter-rising-threshold value. When a non-color-aware test is performed, these values are ignored.
The no form of this command disables jitter rising threshold comparison after a Y.1564 test.
no jitter-rising-threshold-out
This command configures the latency rising threshold value. The threshold value is compared to the latency rising value reported by a Y.1564 test, and a failure is reported if the latency rising value is greater than or equal to the configured threshold.
If an inbound or outbound latency rising threshold is configured, that threshold value is used instead for comparison when a Y.1564 test head color-aware test is run.
The no form of this command disables latency rising threshold comparison after a Y.1564 test.
no latency-rising-threshold
This command configures the in-profile latency rising threshold value. If an in-profile or out-of-profile latency rising threshold is configured, that threshold value is used for comparison when a Y.1564 test head color-aware test is run, instead of the latency-rising-threshold value. When a non-color-aware test is performed, these values are ignored.
The no form of this command disables latency rising threshold comparison after a Y.1564 test.
no latency-rising-threshold-in
This command configures the out-of-profile latency rising threshold value. If an in-profile or out-of-profile latency rising threshold is configured, their threshold value is used for comparison when a Y.1564 test head color-aware test is run, instead of the latency-rising-threshold value. When a non-color-aware test is performed, these values are ignored.
The no form of this command disables latency rising threshold comparison after a Y.1564 test.
no latency-rising-threshold-out
This command configures the loss rising threshold value. The threshold value is compared to the loss rising value reported by a Y.1564 test, and a failure is reported if the loss rising value is greater than or equal to the configured threshold.
If an in-profile or out-of-profile loss rising threshold is configured, that threshold value is used instead for comparison when a Y.1564 test head color-aware test is run.
The no form of this command disables loss rising threshold comparison after a Y.1564 test.
no loss-rising-threshold
This command configures the in-profile loss rising threshold value. If an in-profile or out-of-profile loss rising threshold is configured, that threshold value is used for comparison when a Y.1564 test head color-aware test is run, instead of the loss-rising-threshold value. When a non-color-aware test is performed, these values are ignored.
The no form of this command disables loss rising threshold comparison after a Y.1564 test.
no loss-rising-threshold-in
This command configures the out-of-profile loss rising threshold value. If an in-profile or out-of-profile loss rising threshold is configured, that threshold value is used for comparison when a Y.1564 test head color-aware test is run. When a non-color-aware test is performed, these values are ignored.
The no form of this command disables loss rising threshold comparison after a Y.1564 test.
no loss-rising-threshold-out
This command configures the PIR threshold associated with the ITU-T Y.1564 test head.
no pir-threshold
This command creates a text description of a Y.1564 test head.
The no form of this command removes the text description.
n/a
This command configures a frame payload profile for an ITU-T Y.1564 test head and assigns it a payload ID and payload type.
The no form of this command removes a payload from the test head.
n/a
This command configures the data pattern for an ITU-T Y.1564 frame payload profile.
The data-pattern defines the packet PDU, and is used to fill the packet PDU with repeating numbers of patterns up to the max PDU supported by the packet type as defined by the frame-size.
The no form of this command removes the data pattern specification from the frame payload profile.
no data-pattern
This command creates a text description for a Y.1564 frame payload profile.
The no form of this command removes the text description.
n/a
This command configures the ITU-T Y.1564 frame payload profile DSCP name.
The no form of this command removes the DSCP name.
n/a
This command configures a destination IPv4 address for the ITU-T Y.1564 frame payload profile.
The no form of this command removes the IPv4 address.
no dst-ip
This command configures a destination MAC address for the ITU-T Y.1564 frame payload profile.
The no form of this command removes the MAC address.
no dst-mac
This command configures a destination port number for the ITU-T Y.1564 frame payload profile.
The no form of this command removes the port number.
no dst-port
This command configures the expected Ethertype for the ITU-T Y.1564 frame payload profile.
The no form of this command removes the configured Ethertype.
no ethertype
This command configures the frame size to be used for the ITU-T Y.1564 frame payload profile.
The no form of this command removes the frame size restriction.
no frame-size
This command adds an IP protocol to an ITU-T Y.1564 frame payload profile.
When a payload type is specified as IPv4, this command allows you to specify the upper layer protocol that the frame carries.
The no form of this command removes the IP protocol from the ITU-T Y.1564 test head frame payload.
no ip-proto
This command specifies an IP service type for an ITU-T Y.1564 frame payload profile.
The no form of this command removes the configured service type.
no ip-tos
This command configures a time-to-live value for an ITU-T Y.1564 frame payload profile.
The no form of this command removes the time-to-live value.
no ip-ttl
This command configures the frame rate for an ITU-T Y.1564 frame payload profile.
When configure the rate values, you must take into account the fabric overhead as per the SAP ingress | egress-queue provisioning rules.
The no form of this command removes the configured rate value.
no rate
This command configures the source IP address for an ITU-T Y.1564 frame payload profile.
The no form of this command removes the source IP address.
no src-ip
This command configures the source MAC address for an ITU-T Y.1564 frame payload profile.
The no form of this command removes the source MAC address.
no src-mac
This command configures the source port number for an ITU-T Y.1564 frame payload profile.
The no form of this command removes the port number.
no src-port
This command configures the first VLAN associated with the ITU-T Y.1564 frame payload profile.
The no form of this command removes the VLAN.
no vlan-tag-1
This command configures the second VLAN associated with the ITU-T Y.1564 frame payload profile.
The no form of this command removes the VLAN.
no vlan-tag-2
This command enables the CIR and PIR rates for an ITU-T Y.1564 test head profile.
When no acceptance criteria are configured, the CIR and PIR values are used to determine if the test passes or fails. In order for the test to pass, the measured throughput must be within 1% of the configured PIR value (for color-aware tests) or CIR value (for non-color-aware tests).
The no form of this command removes the configured rate values.
no rate
This command enables a trap that is sent to the operator when the ITU-T Y.1564 test is complete. By default, the system raises an SNMP trap after an ITU-T Y.1564 test.
The no form of this command disables the trap.
test-completion-trap-enable
This command configures the duration of the ITU-T Y.1564 test.
The no form of this command removes the duration limitation from the test head.
no test-duration
This command configures a timed loopback on an Ethernet pseudowire SAP and is required to complete an ITU-T Y.1564 test.
The no form of this command disables the loopback.
no loopback
This command enables TWAMP functions. See the clear>test-oam>twamp>server command description for information about how to disable TWAMP functions.
TWAMP is disabled
This command configures the TWAMP server.
TWAMP server is disabled
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 to conduct tests), the client must establish the control connection using an IP address that is part of a configured prefix.
no prefix
This command creates a text description of an IP prefix used by a TWAMP server. The prefix description can be changed at any time, even while the server is running.
The no form of the command removes the description.
no 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.
no max-conn-prefix
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).
no max-sess-prefix
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.
no inactivity-timeout
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-connprefix) to be exceeded.
The no form of the command sets the default value.
no max-conn-server
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 sets the default value.
no max-sess-server
This command configures the reflector inactivity timeout for all TWAMP test connections. If no TWAMP test frame is received for the timer duration, then the existing TWAMP test connections are closed.
The no form of the command sets the timer value to its default value of 900 seconds.
no ref-inactivity-timeout
This command enables the context for configuring TWAMP Light functionality.
disabled
This command configures the length of time that a stale state is maintained on the session reflector. A stale state is test data that has not been refreshed or updated by newly arriving queries for a specific test for a configured length of time. Any single reflector can maintain an Up state for a maximum of 12 000 tests. If the maximum value is exceeded, the session reflector does not have memory to allocate to new tests; therefore, stale test data should be deleted to ensure that there is room for new tests.
The no form of the command sets the default value.
no inactivity-timeout
This command specifies the downstream mapping TLV format to use in all LSP trace packets and LDP treetrace packets originated on the node. The configured global value becomes the default downstream mapping TLV for all newly created LSP trace and LDP treetrace tests. It has no effect on existing tests and can be overridden on a specific test by setting the downstream-map-tlv parameter in the lsp-trace or ldp-treetrace commands.
The downstream mapping TLV allows the sender and responder nodes to exchange and validate interface and label stack information for each downstream hop in an LDP FEC path, RSVP LSP, or a BGP- labeled IPv4 route. If the responder node has multiple, equal-cost next hops for an LDP FEC or a BGP- labeled IPv4 prefix, it replies in the downstream mapping TLV with the downstream information of each outgoing interface that 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 in the lsp-ping or lsp-trace commands.
By default, the system uses the DSMAP TLV.
dsmap
![]() | Note: LDP treetrace works best with label-IP (lbl-ip) hashing enabled, rather than label-only (lbl-only) hashing. These options are set with the lsr-load-balancing command. For information on the lsr-load-balancing command, refer to the 7705 SAR Basic System Configuration Guide, “System Command Reference” and the 7705 SAR Router Configuration Guide, “IP Router Command Reference”. |
This command configures LDP treetrace parameters in order to perform OAM manual treetrace tests on demand. Treetrace tests are used to discover all possible ECMP paths of an LSP.
The LSP-EXP mappings on the receive network interface control the mapping back to the internal forwarding class used by the far-end 7705 SAR that receives the message request. The egress mappings of the egress network interface on the far-end 7705 SAR control the forwarding class markings on the return reply message.
The LSP-EXP mappings on the receive network interface control the mapping of the message reply at the originating 7705 SAR.
This command enables the context to configure LDP treetrace parameters in order to perform OAM manual treetrace tests. Treetrace commands at this level configure periodic proactive treetrace and set path discovery and path probing parameters.
This command configures forwarding class name and profile parameters. The parameters indicate the forwarding class of the MPLS echo request packets. The actual forwarding class encoding is controlled by the network egress LSP-EXP mappings.The LSP-EXP mappings on the receive network interface control the mapping back to the internal forwarding class used by the far-end 7705 SAR that receives the message request. The egress mappings of the egress network interface on the far-end 7705 SAR control the forwarding class markings on the return reply message.
The LSP-EXP mappings on the receive network interface control the mapping of the message reply at the originating 7705 SAR.
This command enables the context to configure path discovery parameters for ECMP paths of an LSP.
This command configures the time to wait before repeating the LDP tree auto-discovery process.
60
This command configures the maximum number of paths that can be discovered for a selected IP address FEC.
128
This command configures the maximum time-to-live value in the MPLS label for an LSP trace request during the tree discovery.
30
This command specifies policies to filter LDP imported address FECs.
no policy-statement
This command configures the maximum number of consecutive timeouts before the path probe fails.
3
This command configures the maximum amount of time, in seconds, that the router will wait for a message reply after sending the message request. The timeout command overrides the default timeout value. If the timeout expires, the requesting router assumes that the message response will not be received. Any response received after the request times out will be silently discarded.
30
This command enables the context to configure path probing parameters for ECMP paths of an LSP.
This command configures the time to wait before repeating a probe (ping) on an ECMP-discovered path of an LSP.
1
This command configures the maximum number of consecutive timeouts before the path probe fails.
3
This command configures the maximum amount of time, in seconds, that the router will wait for a message reply after sending the message request. The timeout command overrides the default timeout value. If the timeout expires, the requesting router assumes that the message response will not be received. Any response received after the request times out will be silently discarded.
1
This command starts or stops an SAA test.
![]() | Note: The following command outputs are examples only; actual displays may differ depending on supported functionality and user configuration. |
This command enables the context to display CFM information.
This command displays dot1ag and Y.1731 association information.
The following output is an example of eth-cfm association information, and Table 20 describes the fields.
Label | Description |
Md-index | Displays the MD index |
Ma-index | Displays the MA index |
Name | Displays the name of the MA |
CCM-interval | Displays the CCM interval (in seconds) |
Bridge-id | Displays the bridge ID for the MA. The bridge ID is the same value as the service ID of the service to which the MEP belongs. |
Name Format | Displays the format for the MA name |
MHF Creation | Not applicable |
PrimaryVlan | Displays the VLAN ID |
Num Vids | Displays the number of VLAN IDs |
Remote Mep Id | Displays the MEP identifier for the remote MEP |
This command displays stack-table information.
The following output is an example of eth-cfm stack table information, and Table 21 describes the fields.
Label | Description |
Sap | Displays the SAP identifier |
Sdp | Displays the spoke SDP identifier |
Service | Displays the service identifier |
Level | Displays the MD level of the domain |
Dir (direction) | Displays the direction of OAMPDU transmission |
Md-index | Displays the MD index of the domain |
Mep-id | Displays the MEP identifier |
Mac-address | Displays the MAC address of the MEP |
This command displays domain information.
The following output is an example of eth-cfm domain information, and Table 22 describes the fields.
Label | Description |
Domain | |
Md-index | Displays the MD index of the domain |
Level | Displays the MD level of the domain |
Permission | Not applicable |
MHF Creation | Not applicable |
Name Format | Displays the format for the MD name |
Next Ma Index | Displays the value of the next MA index |
Name | Displays the name of the MD |
Domain Associations | |
Md-index | Displays the MD index of the domain |
Ma-index | Displays the MA index of the association |
Name Format | Displays the format for the MA name |
CCM-interval | Displays the CCM interval (in seconds) |
Name | Displays the name of the MA |
Bridge-id | Displays the bridge ID for the MA. The bridge ID is the same value as the service ID of the service to which the MEP belongs. |
MHF Creation | Not applicable |
PrimaryVlan | Displays the VLAN ID configured under the config>eth-cfm>domain>association>bridge-identifier>vlan command |
Num Vids | Displays the number of VLAN IDs and is always 0 |
Remote Mep Id | Displays the MEP identifier for the remote MEP |
This command displays information for various Ethernet OAM tests and entities related to MEPs, including:
The following outputs are examples of Ethernet OAM tests for MEPs:
Label | Description |
Mep Information | |
Md-index | Displays the MD index of the domain |
Direction | Displays the direction of OAMPDU transmission |
Ma-index | Displays the MA index of the association |
Admin | Displays the administrative status of the MEP |
MepId | Displays the MEP identifier |
CCM-Enable | Displays the status of the CCM (enabled or disabled) |
IfIndex | Displays the index of the interface |
PrimaryVid | Displays the identifier of the primary VLAN |
FngState | Indicates the different states of the Fault Notification Generator |
LowestDefectPri | Displays the lowest priority defect (a configured value) that is allowed to generate a fault alarm |
HighestDefect | Identifies the highest defect that is present (for example, if defRDICCM and defXconCCM are present, the highest defect is defXconCCM) |
Defect Flags | Displays the number of defect flags |
Mac Address | Displays the MAC address of the MEP |
CcmLtmPriority | Displays the priority value transmitted in the linktrace messages (LTM)s and CCMs for this MEP. The MEP must be configured on a VLAN. |
CcmTx | Displays the number of Continuity Check Messages (CCM) sent. The count is taken from the last polling interval (every 10 s). |
CcmSequenceErr | Displays the number of CCM errors |
Eth-1DM Threshold | Displays the one-way-delay threshold value |
DmrRepliesTx | Displays the number of delay measurement replies transmitted |
LmrRepliesTx | Displays the number of loss measurement replies transmitted |
Dual-Loss-Test | Displays the state of the dual-ended loss test (enabled or disabled) |
Dual-Loss Threshold | Displays the alarm threshold for frame loss measurement |
Dual-Loss AlarmClr | Displays the clearing alarm threshold for frame loss measurement |
Eth-Ais | Displays the state of the ETH-AIS test (enabled or disabled) |
Eth-Test | Displays the state of the ETH-Test (enabled or disabled) |
Eth-Test dataLength | Displays the data length of the MEP |
Eth-Test Threshold | Displays the bit-error threshold setting |
Eth-Test Pattern | Displays the test pattern configured for the MEP |
Eth-Test Priority | Displays the priority of frames with ETH-Test information |
CcmLastFailure Frame | Displays the frame that caused the last CCM failure |
XconCcmFailure Frame | Displays the frame that caused the XconCCMFailure |
Mep Loopback Information | |
LbRxReply | Displays the number of received loopback (LB) replies |
LbRxBadOrder | Displays the number of received loopback messages that are in a bad order |
LbRxBadMsdu | Displays the number of loopback replies that have been received with the wrong destination MAC address (MSDU = MAC Service Data Unit) |
LbTxReply | Displays the number of loopback replies transmitted out this MEP |
LbTxReply (Total) | Displays the total number of LBRs (loopback replies) transmitted from this MEP |
LbTxReplyNoTLV | Displays the number of LBRs (loopback replies) transmitted from this MEP with no TLV. Because only LBMs with no TLVs are used for throughput testing, the LbTxReply (Total), LbTxReplyNoTLV, and LbTxReplyWithTLV counters can help debug problems if throughput testing is not working |
LbTxReplyWithTLV | Displays the number of LBRs (loopback replies) transmitted from this MEP with TLV |
LbSequence | Displays the sequence number in the loopback message |
LbNextSequence | Displays the next loopback sequence |
LbStatus | Displays the loopback status as True or False: True — loopback is in progress False — no loopback is in progress |
LbResultOk | Displays the result of the loopback test |
DestIsMepId | Identifies whether the destination interface has a MEP-ID (true or false) |
DestMepId | Displays the MEP-ID of the destination interface |
DestMac | Displays the MAC address of the destination interface |
SendCount | Indicates the number of loopback messages sent |
VlanDropEnable | Identifies whether the VLAN drop is enabled (true or false) |
VlanPriority | Displays the VLAN priority |
Data TLV | Displays the data TLV information |
Mep Linktrace Message Information | |
LtRxUnexplained | Displays the number of unexplained linktrace messages (LTM) that have been received |
LtNextSequence | Displays the sequence number of the next linktrace message |
LtStatus | Displays the status of the linktrace |
LtResult | Displays the result of the linktrace |
TargIsMepId | Identifies whether the target interface has a MEP-ID (true or false) |
TargMepId | Displays the MEP-ID of the target interface |
TargMac | Displays the MAC address of the target interface |
TTL | Displays the TTL value |
EgressId | Displays the egress ID of the linktrace message |
SequenceNum | Displays the sequence number of the linktrace message |
LtFlags | Displays the linktrace flags |
Mep Linktrace Replies | |
SequenceNum | Displays the sequence number returned by a previous transmit linktrace message, indicating which linktrace message response will be returned |
ReceiveOrder | Displays the order in which the linktrace initiator received the linktrace replies |
Ttl | Displays the TTL field value for a returned linktrace reply |
Forwarded | Indicates whether the linktrace message was forwarded by the responding MEP |
LastEgressId | Displays the last egress identifier returned in the linktrace reply egress identifier TLV of the linktrace reply The last egress identifier identifies the MEP linktrace initiator that initiated, or the linktrace responder that forwarded, the linktrace message for which this linktrace reply is the response. This is the same value as the egress identifier TLV of that linktrace message. |
TerminalMep | Indicates whether the forwarded linktrace message reached a MEP enclosing its MA |
NextEgressId | Displays the next egress identifier returned in the linktrace reply egress identifier TLV of the linktrace reply. The next egress identifier identifies the linktrace responder that transmitted this linktrace reply and can forward the linktrace message to the next hop. This is the same value as the egress identifier TLV of the forwarded linktrace message, if any. |
Relay | Displays the value returned in the Relay Action field |
ChassisIdSubType | Displays the format of the chassis ID returned in the Sender ID TLV of the linktrace reply, if any. This value is meaningless if the chassis ID has a length of 0 |
ChassisId | Displays the chassis ID returned in the Sender ID TLV of the linktrace reply, if any. The format is determined by the value of the ChassisIdSubType. |
ManAddressDomain | Displays the TDomain that identifies the type and format of the related ManAddress, used to access the SNMP agent of the system transmitting the linktrace reply Received in the linktrace reply Sender ID TLV from that system |
ManAddress | Displays the TAddress that can be used to access the SNMP agent of the system transmitting the CCM Received in the CCM Sender ID TLV from that system |
IngressMac | Displays the MAC address returned in the ingress MAC address field |
Ingress Action | Displays the value returned in the Ingress Action field of the linktrace message |
IngressPortIdSubType | Displays the format of the ingress port ID |
IngressPortId | Displays the ingress port ID; the format is determined by the value of the IngressPortIdSubType |
EgressMac | Displays the MAC address returned in the egress MAC address field |
Egress Action | Displays the value returned in the Egress Action field of the linktrace message |
EgressPortIdSubType | Displays the format of the egress port ID |
EgressPortId | Displays the egress port ID; the format is determined by the value of the EgressPortIDSubType |
Org Specific TLV | Displays all organization-specific TLVs returned in the linktrace reply, if any Includes all octets including and following the TLV length field of each TLV, concatenated |
Label | Description |
R-mepId | Displays the remote MEP identifier |
Rx CC | Displays the state of received CCMs (True or False): True—CCMs are received False—CCMs are not received |
Rx Rdi | Displays the state of received RDIs (True or False): True—RDIs are received False—RDIs are not received |
Port-Tlv | Displays the contents of the port status TLV in the CCM (Up, Blocked, or Absent), as defined in the 802.1ag specification |
If-Tlv | Displays the contents of the interface status TLV in the CCM (Up, Blocked, or Absent), as defined in the 802.1ag specification |
Peer Mac Addr | Displays the MAC address of the peer (remote) entity |
CCM status since | Displays the date and time when continuity check messages began to be sent |
Label | Description |
Peer Mac Addr | Displays the MAC address of the peer (remote) entity |
FrameCount | Displays the number of test frames sent between the MEP and the peer entity |
ByteCount | Displays the number of bytes sent between the MEP and the peer entity |
Current ErrBits | Displays the number of bit errors in the current test |
Current CrcErrs | Displays the number of CRC errors in the current test |
Accumulate ErrBits | Displays the accumulated number of bit errors in the current test |
Accumulate CrcErrs | Displays the accumulated number of CRC errors in the current test |
Label | Description |
Peer Mac Addr | Displays the MAC address of the peer (remote) entity |
Delay (us) | Displays the measured delay (in microseconds) for the DM test |
Delay Variation (us) | Displays the measured delay variation (in microseconds) for the DV test |
Label | Description |
Far-End Mac Addr | Displays the MAC address of the far-end (remote) router |
Duration (sec) | Displays the duration that the current test has been running Reset via the clear>eth-cfm>dual-ended-loss-test command |
CCMRxCount | Displays the total number of received CCMs |
Latest Frame Counters | Indicates that the number of frames counted are the latest values:
|
TxLocal | Displays the latest number of frames transmitted from the local router |
RxFarEnd | Displays the latest number of frames received at the remote router |
TxFarEnd | Displays the latest number of frames transmitted from the remote router |
RxLocal | Displays the latest number of frames received by the local router |
Accumulated Frames | Indicates that the frame counter values under this heading are the accumulated values for the near-end (local) and far-end (remote) routers |
Total Tx | Displays the total number of frames transmitted during the test |
Total Rx | Displays the total number of frames received during the test |
Total Loss | Displays the total number of frames lost during the test |
Loss Ratio (%) | Displays the loss ratio, defined as follows:
Example (single-ended):
Example (dual-ended):
|
This command displays information about the SAA test.
If no specific test is specified, a summary of all configured tests is displayed.
If a 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.
The following output is an example of SAA test result information, and Table 28 describes the fields.
Label | Description |
Test name | Displays the name of the test |
Owner name | Displays the test owner’s name |
Administrative status | Indicates the administrative state of the test – enabled or disabled |
Test type | Identifies the type of test configured |
Test runs since last clear | Indicates 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 result | Indicates the result of the last test 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:
|
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 |
This command displays OAM LDP treetrace information.
The following output is an example of LDP treetrace information.
This command displays TWAMP server information.
The following output is an example of TWAMP server information, and Table 29 describes the fields.
Label | Description |
TWAMP Server | |
Admin State | Displays one of the following: Up—the server (or prefix) is administratively enabled (no shutdown) in configuration Down—the server (or prefix) is administratively disabled (shutdown) in configuration |
Operational State | Displays one of the following: Up—the server (or prefix) is operationally enabled Down—the server (or prefix) is operationally disabled |
Up Time | The time since the server process was started, measured in days (d), hours, minutes, and seconds |
Current Connections | The total number of currently connected clients |
Max Connections | The maximum number of connected clients |
Connections Rejected | The total number of client connections that have been rejected for one of the following reasons:
|
Inactivity Time Out | The configured inactivity timeout for the server |
Current Sessions | The total number of currently in-progress test sessions (for which Start-Sessions have been received) |
Max Sessions | The maximum number of concurrent test sessions from clients |
Sessions Rejected | The total number of test sessions that have been rejected |
Sessions Aborted | The total number of test sessions that have been aborted |
Sessions Completed | The total number of test sessions that have been completed |
Ref Inact Time Out | The maximum inactivity time for the test session. The test session is cleared and released upon expiry of this timer. |
Test Packets Rx | The total number of test packets received from session senders |
Test Packets Tx | The total number of test packets sent to session senders |
TWAMP Server Prefix Summary | |
Prefix | The IP address prefix of a TWAMP client |
Current Connections | The number of current connections for the specified TWAMP client |
Current Sessions | The number of current sessions for the specified TWAMP client |
Description | Optional description of the specified TWAMP client |
No. of TWAMP Server Prefixes | The total number of TWAMP server prefixes |
The following output example shows the information for the TWAMP server prefix and the TWAMP clients associated with the prefix that can connect to the TWAMP server. Table 30 describes the TWAMP server prefix fields.
Label | Description |
TWAMP Server Prefix | |
Description | Optional text that describes the server prefix |
Current Connections | See Table 29. |
Max Connections | |
Connections Rejected | |
Current Sessions | |
Max Sessions | |
Sessions Rejected | |
Sessions Aborted | |
Sessions Completed | |
Ref Inact Time Out | |
Test Packets Rx | |
Test Packets Tx | |
Connection information for TWAMP server prefix | |
Client | The IP address of the client |
State | The operational state of the client |
Curr Sessions | The number of current sessions for the specified TWAMP server prefix client |
Sessions Rejected | The total number of test sessions that have been rejected by the client |
Sessions Completed | The total number of test sessions that have been completed for the client |
Idle Time (s) | The idle time in seconds for each client |
Test Packets Rx | The total number of test packets received by the client from the session senders |
Test Packets Tx | The total number of test packets sent to session senders from the client |
No. of TWAMP Server Connections for Prefix | The total number of current TWAMP server connections for the prefix |
This command shows TWAMP-Light reflector information.
The following output is an example of TWAMP Light information, and Table 31 describes the fields.
Label | Description |
TWAMP Light Reflector | |
Router/VPRN | The TWAMP Light clients |
Admin | Displays one of the following: Up—the server or prefix is administratively enabled (no shutdown) in configuration Down—the server or prefix is administratively disabled (shutdown) in configuration |
UDP Port | The UDP port number used |
Prefixes | The time since the server process was started, measured in days (d), hours, minutes, and seconds |
Frames Rx | The total number of frames received from session senders |
Frames Tx | The total number of frames sent to session senders |
This command displays ITU-T Y.1564 test head profile information.
The following output example shows the information for the ITU-T Y.1564 test head profile. Table 32 describes the fields.
Label | Description |
Description | The test head profile or Frame payload description |
Profile Id | The test head profile ID number |
CIR Configured | The CIR threshold, if configured |
PIR Configured | The PIR threshold, if configured |
Duration Hrs | The specified test duration in hours |
Duration Mins | The specified test duration in minutes |
Duration Secs | The specified test duration in seconds |
Acceptance Criteria Id | The ID number of the acceptance criteria used for the test, taken from the list of configured acceptance-criteria for the testhead-profile template |
Loss TH | The loss threshold value |
InProf Loss TH | The in-profile loss threshold value |
OutProf Loss TH | The out-of-profile loss threshold value |
Latency TH | The latency threshold value |
InProf Latency TH | The in-profile latency threshold value |
OutProf Latency TH | The out-of-profile latency threshold value |
Jitter TH | The jitter threshold value |
InProf Jitter TH | The in-profile jitter threshold value |
OutProf Jitter TH | The out-of-profile jitter threshold value |
Ref. Count | The number of test results in memory that are referencing this profile |
CIR TH | The CIR threshold value, if configured |
PIR TH | The PIR threshold value, if configured |
Frame Payload Id | The ID number of the frame payload associated with the test head |
Payload Type | Displays the frame payload type as l2, tcp-ipv4, udp-ipv4, or ipv4 |
Frame Size | The configured frame packet size |
Rate | The configured frame rate |
Dst Mac | The destination MAC address for the test head packets |
Src Mac | The source MAC address of the test head packets |
Vlan Tag 1 | The first VLAN tag associated with the test head |
Vlan Tag 2 | The second VLAN tag associated with the test head |
Ethertype | The Ethertype associated with the test head packets |
TOS | The IP service type |
Src. IP | The source IP address of the test head packets |
L4 Dst Port | The Layer 4 destination port for the test head packets |
Protocol | The IP protocol associated with the test head |
Data Pattern | The configured |
DSCP | The DSCP associated with the test head |
TTL | The time-to-live value for the test head packets |
Dst. IP | The destination IP address for the test head packets |
L4 Src Port | The Layer 4 source port of the test head packets |
This command displays information about an ITU-T Y.1564 test head with a specific test name and owner.
The following output is an example of ITU-T Y.1564 test information, and Table 33 describes the fields.
Label | Description |
Owner | The test owner |
Test | The test name |
Marker Pkt Src Mac | The MAC address of the test source packets |
Performance Mon | Marker-packet use for delay and jitter measurements, either enabled or disabled |
Profile Id | The profile ID number assigned to the test |
SAP | The SAP ID for the test |
Accept. Crit. Id | The ID number of the acceptance criteria profile associated with the test |
Completed | Indicates if the test has been completed |
Stopped | Indicates if the test has been stopped |
Frame Payload Id | The ID number of the frame payload associated with the test Additional Frame Payload ID values are shown when the test uses parallel flows |
Frame Payload Type | Displays the frame payload type as l2, tcp-ipv4, udp-ipv4, or ipv4 Additional Frame Payload type values are shown when the test uses parallel flows |
Color Aware Test | Indicates if the color-aware test is active on the Y.1564 test |
Start Time | The date and time that the test began |
End Time | The date and time that the test ended |
Total time taken | The time for the test to complete in days, hours, minutes, and seconds |
Test Status | The result of the test, either pass or fail |
Total injected | The total number of packets injected during the test |
Total Received | The total number of packets received during the test |
OutPrf Injected | The total number of out-of-profile packets injected during the test |
OutPrf Received | The total number of out-of-profile packets received during the test |
InPrf Injected | The total number of in-profile packets injected during the test |
In Prf Received | The total number of in-profile packets received during the test |
Throughput Configd | The configured throughput threshold value |
Throughput Agg | The sum of all frame payload rates used for the test |
Throughput Oper | The measured SAP ingress throughput of the test head |
Throughput Measured | The measured throughput value, which must be within 1% of configured CIR or PIR threshold value in order for the test to pass |
Marker Pkt Bandwid* | The extra bandwidth used by the test head, in addition to the provisioned frame payload, in order to run a performance monitoring test |
Tput Acceptance | The throughput acceptance test result, either pass or fail |
PIR Tput Configured | The configured PIR throughput value |
PIR Tput Meas | The measured PIR throughput |
PIR Tput Acep | The PIR throughput acceptance test result, either pass or fail |
CIR Tput Configured | The configured CIR throughput value |
CIR Tput Meas | The measured CIR throughput |
CIR Tput Acep | The CIR throughput acceptance test result, either pass or fail |
FLR Configured | The frame loss rising acceptance criteria value |
FLR Measured | The measured frame loss rising value |
FLR Acceptance | The frame loss rising test result, either pass or fail |
OutPrf FLR Conf | The out-of-profile frame loss rising acceptance criteria value |
OutPrf FLR Meas | The out-of-profile measured frame loss rising value |
OutPrf FLR Acep | The out-of-profile frame loss rising test result, either pass or fail |
InPrf FLR Conf | The in-profile frame loss rising acceptance criteria value |
InPrf FLR Meas | The in-profile measured frame loss rising value |
InPrf FLR Acep | The in-profile frame loss rising test result, either pass or fail |
Latency Configd | The latency acceptance criteria value |
Latency Measurd | The measured latency value |
Latency Acceptance | The latency test result, either pass or fail |
OutPrf Lat Conf | The out-of-profile latency acceptance criteria value |
OutPrf Lat Meas | The out-of-profile measured latency value |
OutPrf Lat Acep | The out-of-profile latency test result, either pass or fail |
InPrf Lat Conf | The in-profile latency acceptance criteria value |
InPrf Lat Meas | The in-profile measured latency value |
InPrf Lat Acep | The in-profile latency test result, either pass or fail |
Jitter Configd | The jitter rising acceptance criteria value |
Jitter Measurd | The measured jitter rising value |
Jitter Acceptance | The jitter rising test result, either pass or fail |
OutPrf Jit Conf | The out-of-profile jitter rising acceptance criteria value |
OutPrf Jit Meas | The out-of-profile measured jitter rising value |
OutPrf Jit Acep | The out-of-profile jitter rising test result, either pass or fail |
InPrf Jit Conf | The in-profile jitter rising acceptance criteria value |
InPrf Jit Meas | The in-profile measured jitter rising value |
InPrf Jit Acep | The in-profile jitter rising test result, either pass or fail |
Total Pkts. Tx. | The total number of packets transmitted during the test |
OutPrf Lat Pkts R* | The out-of-profile latency packets received |
InPrf Lat Pkts. R* | The in-profile latency packets received |
This command clears the SAA results for the specified test and the history for the test. If the test name is omitted, all the results for all tests are cleared.
This command clears the accumulated frame counters during a dual-ended loss measurement (LM) test.
The LM counters are reset when a MEP on the datapath is created or deleted automatically by the system for network or configuration reasons. Some of the reasons for creating or deleting a MEP are as follows, excluding the general functions of manually creating or deleting a MEP:
![]() | Note: The clear>dual-ended loss-test command only resets the “Accumulated Frames During the Test” results for both the far end and near end. The frame counters for aggregated results are not reset. See Output Example - before fewer than two CCMs. |
The following outputs are examples of displays after a show>eth-cfm>.....>dual-ended-loss-test command is issued:
In the display below, counters that have been cleared and restarted are shown in bold.
This command clears the statistics for the TWAMP server.
This command clears the ITU-T Y.1564 test head statistics.
This command enables or disables debugging for OAM.
This command enables debugging for LSP ping.