OAM diagnostic test descriptions
Introduction
This section provides a description of supported NFM-P OAM diagnostic test functionality grouped by their functional area on the STM. Unless where noted, all test are accessible from the STM. See Table 90-1, NFM-P supported OAM diagnostic tests and configurations for a list of all supported OAM diagnostic tests and their applicable procedures.
Ethernet CFM OAM diagnostic tests
Use the Ethernet CFM (Connectivity Fault Management) OAM diagnostic tests to detect, isolate, and report connectivity faults for L2 objects in Ethernet networks. The NFM-P Ethernet CFM function is implemented based on the IEEE 802.1ag OAM standard.
See Chapter 91, Ethernet CFM for a description of each Ethernet CFM OAM diagnostic test and applicable configuration procedure.
PM OAM diagnostic tests
Use the Performance Monitoring (PM) OAM diagnostic tests to assess the configuration and performance of Carrier Ethernet services such as Ethernet frame delay, frame delay variation, frame loss, and frame throughput measurements as specified by the ITU-T Y-1731 standard.
See Chapter 92, Performance Monitoring tests for a description of each PM OAM diagnostic test and applicable configuration procedure.
Service OAM diagnostic tests
Use the Service OAM diagnostic tests to assess the configuration and performance of an Ethernet service before customer notification and delivery, and to troubleshoot and resolve problems that are related to an individual service within the provider network.
Service site ping
The service site ping OAM diagnostic test, which is called svc-ping in CLI, provides end-to-end connectivity testing for an individual service within the provider network.
This diagnostic test operates at a higher level than the tunnel ping OAM because it verifies connectivity for an individual service rather than connectivity across the service tunnel. This allows you to isolate a problem within the service rather than at the port, which is the endpoint of the service tunnel.
The test verifies a service ID for correct and consistent provisioning between two service endpoints.
The following information can be verified from a service site ping OAM:
-
same customer is associated with the local and remote service sites
-
service-to-circuit association at both the local and remote service sites using the Use Local Tunnel and Use Remote Tunnel options, to check the circuit between service sites
See To create and run a service site ping OAM diagnostic test from the STM for information about how to create and run a service site ping OAM diagnostic test from the STM.
Note: The OAM messages, which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address that is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the service site ping OAM diagnostic test use the T-LDP local LSR ID as the source IP address. Previously, the NE’s system interface address was used for this purpose.
VCCV ping
The VCCV ping OAM diagnostic test, which is called vccv-ping in the CLI, performs in-band connectivity tests. It can be used for VPLS, MVPLS, HVPLS, and all types of VLLs.
When applied to a VLL service, the test supports cross-circuit tests as long as the circuit types match; for example, an Epipe-to-Epipe connector, or an Epipe-to-VPLS/MVPLS site connector. The purpose of the ping is to determine that the destination PE device is the egress for the L2 FEC. The following figure shows a sample VCCV ping OAM diagnostic test.
Figure 90-1: VCCV ping OAM diagnostic
In Figure 90-1, VCCV ping OAM diagnostic , the ping test packet or packets are sent with the destination IP address of PE 2. The request is encapsulated in a VLL packet and is forwarded to PE 2. PE 2 replies to the source device IP address. The packets are sent using the same encapsulation and along the same path as user packets in the VLL. This test provides a check of both the control plane and the data plane.
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the VCCV ping OAM diagnostic test use the T-LDP local LSR ID as the source IP address. Previously the NE’s system interface address was used for this purpose.
When this test is applied to a VPLS, MVPLS or HVPLS, downstream SDP bindings are not configurable as they are in VLL services. Downstream bindings are typically related to switching sites and these are not relevant to VPLS. In VPLS, only the first SDP binding is configured, and this can be either a mesh or spoke binding.
Also, since an HVPLS comprises a mixture of active and standby spokes, the VCCV ping test execution will only be successful on active spokes that have associated active return spokes. A test suite will generate all the required VCCV ping tests, but only active spokes with active return spokes are counted in the statistics results. This also includes any service connector used in a composite service, provided that the connector is a spoke connector between a VPLS and an Epipe service.
See To create and run a VCCV ping OAM diagnostic test from the STM for information about how to create and run a VCCV ping OAM diagnostic test from the STM.
VCCV trace
The VCCV trace OAM diagnostic test, which is called vccv-trace in the CLI, displays the hop-by-hop path used by a VLL. VCCV trace can trace the entire path of a PW with a single command issued at the T-PE or at an S-PE. It is an iterative process by which the ingress T-PE or T-PE sends successive VCCV-Ping messages with incrementing the TTL value, starting from TTL=1. The process is terminated when the reply is from the egress T-PE or when a timeout occurs.
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the VCCV Trace OAM diagnostic test use the T-LDP local LSR ID as the source IP address. Previously the NE’s system interface address was used for this purpose.
See To create and run VCCV trace OAM diagnostic test from the STM for information about how to create and run a VCCV trace OAM diagnostic test from the STM. To create a VCCV trace OAM diagnostic test from a static PW to a dynamic PW segment, perform To create and run a VCCV trace OAM diagnostic from a static PW to a dynamic PW segment from the STM . To create a VCCV trace OAM diagnostic test from a dynamic PW to a static PW segment, perform To create and run a VCCV trace OAM diagnostic from a dynamic PW to a static PW segment from the STM .
Y.1564 bidirectional tests
Y.1564 bidirectional tests allow you to assess the configuration and performance of an Ethernet service before customer notification and delivery. Y.1564 provides a standard for measuring throughput, latency, frame loss, and jitter to assess if the service complies with an SLA. Multiple test types are supported. See STM Y.1564 test configuration in Chapter 89, Service Test Manager for more information.
L2 service OAM diagnostic tests
Use the L2 service OAM diagnostic tests to troubleshoot and resolve problems that are related to FIBs, MAC addressing, or hostname in a VLAN. These tests are generally used in combination; for example, MAC populate to inject a MAC address into the network, MAC ping to determine where the address was learned, MAC trace to determine the path, CPE ping to test the VPLS, and MAC purge to remove the injected MAC address.
MAC populate
The MAC populate OAM diagnostic test, which is called mac-populate in CLI, is used to:
-
determine if the FIB table is accurate by testing forwarding plan correctness. This is done by populating a service FIB with an OAM-tagged MAC entry. This MAC entry indicates that the NE is the egress NE for the MAC address of a service. You can then use the FIB manager to see the OAM-tagged MAC entry.
-
send a message through the flooding domain to learn a MAC address, as if a customer packet with that source MAC address had flooded the domain from that ingress point of the service.
You can:
In a MAC populate, the OAM-tagged MAC address is populated on the egress point of the service. You can specify whether to flood this OAM-tagged MAC address to other devices so that the same OAM-tagged entry is added to the FIB tables of other devices.
See To create and run a MAC populate OAM diagnostic test from the STM for information about how to create and run a MAC populate OAM diagnostic test from the STM.
MAC purge
The MAC purge OAM diagnostic test, which is called mac-purge in CLI, is used to delete an OAM-tagged entry from a FIB, which was generated using the MAC populate OAM diagnostic test. This clears the FIB of any learned information for a specific MAC address, allows the FIB to be populated only by a MAC populate request, and can be used to flush all devices in a service domain.
See To create and run a MAC purge OAM diagnostic test from the STM for information about how to create and run a MAC purge OAM diagnostic test from the STM.
MAC ping
The MAC ping OAM diagnostic test, which is called mac-ping in CLI, is used to test connectivity in a VLL or VPLS by verifying a remote MAC address at the far end of a service. The MAC ping determines the existence of the far-end egress point of the service. MAC pings can be sent in-band or out-of-band.
You must specify either:
In a MAC ping that is out-of-band, the ping is forwarded along the flooding domain when no MAC address bindings exist or is sent along the bindings if MAC address bindings exist. A response ping is sent from the far-end device when there is an egress binding for the service.
In a MAC ping that is in-band, the ping is sent with a VC label TTL of 255. The ping packet goes across each hop, and when it reaches the egress router, it is identified by the OAM label and the response is sent back along the management plane.
Figure 90-2, Sample MAC ping OAM diagnostic test shows a sample MAC ping OAM diagnostic test from one end of a service to the far-end MAC address of the service.
See To create and run a MAC ping OAM diagnostic test from the STM for information about how to create and run a MAC ping OAM diagnostic test from the STM.
Figure 90-2: Sample MAC ping OAM diagnostic test
MAC trace
The MAC trace OAM diagnostic test, which is called mac-trace in CLI, displays the hop-by-hop route of MAC addresses used to reach the target MAC address at the far end of a service. MAC traces can be sent in-band or out-of-band.
You must specify either:
In a MAC trace that is out-of-band, the destination IP address is specified by mapping the destination MAC address. If the destination MAC address is known to be a specific site, the far-end IP address of the service tunnel is used. If the destination MAC address is not known, the packet is sent to all service tunnels in the service.
In a MAC trace that is in-band, the trace request contains tunnel encapsulation, VC label, OAM, and other information. If the destination MAC address is known, the appropriate tunnel encapsulation and VC label is used. If the destination MAC address is not known, the packet is sent to all service tunnels, including all necessary tunnel encapsulation and egress VC labels for each bound service tunnel.
The following figure shows a sample MAC trace OAM diagnostic test. See Figure 90-3, MAC trace OAM diagnostic test for information about how to create and run a MAC trace OAM diagnostic test from the STM.
Figure 90-3: MAC trace OAM diagnostic test
CPE ping
The CPE ping OAM diagnostic test, which is called cpe-ping in the CLI, is used to trace the end-to-end switching of specified MAC addresses of customer premises equipment. This ping extends the functionality of the MAC ping beyond the egress (customer-facing) port by allowing a ping to the SAP of a VPLS or a VLL Epipe service over a VPLS PBB backbone.
See To create and run a CPE ping OAM diagnostic test from the STM for information about how to create and run a CPE ping OAM diagnostic test from the STM.
ANCP loopback
The ANCP loopback OAM diagnostic test, which is called oam ancp in the CLI, is used to send DSL OAM commands to complete an OAM test to the access NE from a centralized point or when operational boundaries prevent direct access to the DSLAM. The ANCP loopback test raises an alarm that generates a log event displaying both successful and failed results.
See To create and run an ANCP loopback OAM diagnostic test from the STM for information about how to create and run an ANCP loopback OAM diagnostic test from the STM.
VXLAN ping
VXLAN is the overall Layer 2 tunneling mechanism used to connect services in data center architectures. The VXLAN connection is a point-to-point Layer 2 connection that has only two Virtual Tunnel Endpoints (VTEPs). From a transport perspective, the VXLAN tunnels are similar in nature to a GRE SDP binding. The VXLAN connections are part of the subscriber's VPLS services connecting the Virtual Machine to the data center. Each subscriber has their own VPLS instance.
The VXLAN ping test is used to confirm that the Virtual Tunnel is operational by using Echo Request/Reply functions, as well as query the status of the Virtual Network Instance (VNI).
See To create and run a VXLAN ping OAM diagnostic test from the STM for information about how to create and run a VXLAN ping OAM diagnostic test from the STM.
L3 service OAM diagnostic tests
Use the L3 service OAM diagnostic tests to troubleshoot and resolve problems related to VPRN services provisioned on the NFM-P.
VPRN ping
The VPRN ping OAM diagnostic test determines the existence of the far-end egress point of the service. This allows testing of whether a specific destination can be reached. VPRN pings can be sent in-band or out-of-band. When a VPRN ping test packet is sent, a reply is generated if the targeted prefix is reachable over a VPRN SAP or VPRN spoke interface; otherwise the test packet is dropped in CPM. This also applies in the case of a routed VPLS interface.
You can perform a VPRN ping OAM diagnostic test from the STM, as described in To create and run a VPRN ping or VPRN trace OAM diagnostic test from the STM . You can also perform this test from a VPLS/MVPLS or VLL service form, as described in To create and run a VPRN Ping, VPRN Trace, ICMP Ping, or ICMP Trace OAM diagnostic test from a service manager form , or from a service flat topology map.
VPRN trace
The VPRN trace OAM diagnostic test displays the hop-by-hop path for a destination IP address within a VPRN service. This allows operators to know the destination path of customer traffic. VPRN traces can be sent in-band or out-of-band. When a VPRN trace test packet is sent, a reply is generated if the targeted prefix is reachable over a VPRN SAP or VPRN spoke interface. Otherwise the test packet is dropped in CPM. This also applies in the case of a routed VPLS interface.
You can perform a VPRN trace OAM diagnostic test from the STM, as described in To create and run a VPRN ping or VPRN trace OAM diagnostic test from the STM . You can also perform this test from a VPLS/MVPLS or VLL service form, as described in To create and run a VPRN Ping, VPRN Trace, ICMP Ping, or ICMP Trace OAM diagnostic test from a service manager form , or from a service flat topology map.
Service transport OAM diagnostic tests
Use the service transport OAM diagnostic tests to troubleshoot and resolve problems related to VPRN services provisioned on the NFM-P.
Tunnel ping
The tunnel ping OAM diagnostic test, which is called sdp-ping in the CLI, performs in-band unidirectional or bidirectional connectivity tests on service tunnels (also called an SDP). Use tunnel ping to troubleshoot and resolve tunnel and service problems that are related to issues that circuits may have transmitting traffic across the GRE or MPLS network.
The OAM packets are sent in-band in the tunnel encapsulation, so they follow the same path as the service traffic. The response can be received out-of-band in the control plane or in-band using the data plane for a bidirectional test.
For a unidirectional test, tunnel ping OAM tests:
-
whether the packet can reach the far-end IP address destination of the service tunnel ID within its encapsulation
-
whether a packet of the specified size goes to the far-end IP address of the service tunnel ID within its encapsulation
-
forwarding class mapping to ensure that the test packet is treated the same as the customer traffic
For a bidirectional test, tunnel OAM uses a local egress service tunnel ID and an expected remote service tunnel ID, so the user can specify where the returned messages should be sent from based on the far-end tunnel ID.
Figure 90-4, Sample tunnel ping OAM diagnostic test shows how a tunnel OAM packet can be inserted to test the connectivity between two customer LANs across the IP/MPLS core.
See To create a tunnel ping OAM diagnostic test from the STM for information about how to create and run an tunnel ping OAM diagnostic test from the STM.
Figure 90-4: Sample tunnel ping OAM diagnostic test
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the tunnel ping OAM diagnostic test use the T-LDP local LSR ID as the source IP address. Previously the NE’s system interface address was used for this purpose.
MTU ping
The MTU ping OAM diagnostic test, which is called sdp-mtu in CLI, provides a tool for service providers to:
-
determine the maximum frame (MTU) size supported between the service ingress and the service termination point on a service tunnel (also called an SDP), to within one byte
-
solve troubleshooting issues that are related to equipment used across the network core that may not be able to handle large frame sizes
In a large network, network devices can support a variety of packet sizes, up to a limit, that are transmitted across its interfaces. This size limit is referred to as the MTU of network interfaces. You must consider the MTU of the entire service tunnel end-to-end when you provision services, especially for VLL services in which the service must support the ability to transmit the largest customer packet.
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the MTU ping OAM diagnostic test use the T-LDP local LSR ID as the source IP address. Previously the NE’s system interface address was used for this purpose.
See To create and run an MTU ping OAM diagnostic test from the STM for information about how to create and run an MTU ping OAM diagnostic test from the STM. See To create and run an MTU ping OAM diagnostic test from a service tunnel for creating and running an MTU ping OAM diagnostic test from a service tunnel.
MPLS OAM diagnostic tests
Use the MPLS OAM diagnostic tests to test OAM functionality for MPLS provisioned networks based on RFC 4379.
LSP ping
The LSP ping OAM diagnostic test, which is called lsp-ping in CLI, performs in-band MPLS LSPs, MPLS-TP LSPs, LDPs, and MPLS path connectivity tests.
You can use an LSP ping to:
-
detect data plane failures in LSPs or MPLS-TP LSP and with LSP or MPLS-TP LSP connectivity
-
test whether the LSP or MPLS-TP LSP tunnels are working in both directions
In an LSP or MPLS-TP LSP ping, the originating router creates an MPLS echo request packet for the LSP and MPLS path to be tested. The MPLS echo request packet is sent and awaits an MPLS echo reply packet from the router that terminates the LSP. The status of the LSP is displayed when the MPLS echo reply packet is received. Figure 90-5, LSP ping OAM diagnostic test shows an example of an LSP ping OAM diagnostic test.
See To create and run a MPLS LSP ping OAM diagnostic test from the STM for information about how to create and run an LSP ping OAM diagnostic test from the STM.
Figure 90-5: LSP ping OAM diagnostic test
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the LSP Ping use the T-LDP local LSR ID as the source IP address. Previously the NEs system interface address was used for this purpose.
LSP trace
The LSP trace OAM diagnostic test, which is called lsp-trace in CLI, displays the hop-by-hop route used by MPLS LSPs, MPLS-TP LSPs, LDPs, and the MPLS path. You can use an LSP trace to isolate a data plane failure to a particular router and to provide LSP path tracing.
The following information can be determined from the test:
When performing an MPLS LSP or MPLS-TP LSP trace, the originating router creates an MPLS echo request packet for the LSP to be tested. The packet contains increasing TTL values. The MPLS echo request packet is sent and awaits a TTL exceeded response or the MPLS echo reply packet from the router that terminates the LSP. The devices along the hop-by-hop route reply to the MPLS echo request packets with TTL and MPLS echo reply information.
Figure 90-6, LSP Trace diagnostic test shows an example of an LSP trace OAM diagnostic test.
See To create and run a MPLS LSP trace OAM diagnostic test from the STM for information about how to create and run an LSP trace OAM diagnostic test from the STM.
Figure 90-6: LSP Trace diagnostic test
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the LSP trace OAM diagnostic test use the T-LDP local LSR ID as the source IP address. Previously the NE’s system interface address was used for this purpose.
LDP tree trace
The LDP tree trace OAM diagnostic test, which is called ldp-treetrace in CLI, is used to detect and discover the ECMP routing paths for an LSP between egress and ingress routers.
The following information is determined from the test:
In an LDP tree trace, the originating router creates an MPLS echo request packet. The packet contains a set of IP header destination addresses. Routers along the path reply to the request with information about themselves and neighboring routers in the downstream path. The originating router uses this information to probe the downstream routers until it discovers a bit map setting common to all routers along the path. The result is a tree of available routers that the originating router can use for next hops. After discovery, the paths are tested using LSP ping and LSP trace.
Note: The OAM messages which operate over an LDP LSP, and/or over a PW signaled by T-LDP, and which require a response using the IP path, must use a source IP address which is reachable within the same routing domain as that of the LSR ID of the LDP or T-LDP session. The messages of the LDP tree trace use the T-LDP local LSR ID as the source IP address. Previously the NE’s system interface address was used for this purpose.
See To create and run a MPLS LDP tree trace OAM diagnostic test from the STM for information about how to create and run an LDP tree trace OAM diagnostic test from the STM.
P2MP LSP ping
The PSMP LSP ping OAM diagnostic test, which is called p2mp-lsp-ping in CLI, performs in-band LSP connectivity tests.
The echo request message is sent on the active P2MP instance and is replicated in the data path over all branches of the P2MP LSP instance. By default, all egress LER devices that are leaves of the P2MP LSP instance will reply to the echo request message.
You can reduce the scope of the echo reply messages by entering a list of addresses for the egress LER devices that are required to reply. A maximum of 5 addresses can be specified in a single run of the p2mp-lsp-ping command. If all 5 egress LER devices are 7x50 NEs, they will be able to parse the list of egress LER addresses and will reply. The p2mp-lsp-ping command specifies that only the top address in the P2MP Egress Identifier TLV must be inspected by an egress LER. When interoperating with other implementations, a 7x50 egress LER will respond if its address is anywhere in the list. Furthermore, if another vendor implementation is the egress LER, only the egress LER matching the top address in the TLV may respond.
If you enter the same egress LER address more than once in a single p2mp-lsp-ping command, the head-end NE displays a response to a single one and displays a single error warning message for the duplicate ones. When queried over SNMP, the head-end NE issues a single response trap and issues no trap for the duplicates.
See To create and run a MPLS P2MP LSP ping OAM diagnostic test from the STM for information about how to create and run a P2MP LSP ping OAM diagnostic test from the STM.
P2MP LSP trace
The PSMP LSP trace OAM diagnostic test, which is called p2mp-lsp-trace in CLI, performs in-band LSP connectivity tests.
The LSP trace capability allows you to trace the path of a single S2L path of a P2MP LSP. Its operation is similar to that of the p2mp-lsp-ping command, but the sender of the echo reply request message includes the Downstream Detailed Mapping TLV to request the downstream branch information from a branch LSR or BUD LSR. The branch LSR or BUD LSR will then also include the Downstream Detailed Mapping TLV to report the information about the downstream branches of the P2MP LSP. An egress LER must not include this TLV in the echo response message.
The parameter probe-count operates in the same way as in the LSP trace on a P2P LSP. It represents the maximum number of probes sent per TTL value before giving up on receiving the echo reply message. If a response is received from the traced NE before reaching maximum number of probes, then no more probes are sent for the same TTL. The sender of the echo request then increments the TTL and uses the information it received in the Downstream Detailed Mapping TLV to start sending probes to the NE downstream of the last NE that replied. This continues until the egress LER for the traced S2L path replies.
See To create and run a MPLS P2MP LSP trace OAM diagnostic test from the STM for information about how to create and run a P2MP LSP trace OAM diagnostic test from the STM.
L1/L2 OAM diagnostic tests
Use the L1/L2 OAM diagnostic tests to test ATM PVC connections.
ATM ping
The ATM ping OAM diagnostic test, which is called atmoam-ping in CLI, performs an ATM ping on an ATM PVC from the PVC endpoint using ATM OAM loopback cells. An ATM ping test verifies VC integrity and endpoint connectivity for PVCs using OAM loopback capabilities.
See To create and run an ATM ping OAM diagnostic test from the STM for information about how to create and run an ATM ping OAM diagnostic test from the STM. See To configure an ATM OAM loopback from a device Properties form for creating and running a ATM ping OAM diagnostic test from an NE Properties form.
Multicast OAM diagnostic tests
Use the multicast OAM diagnostic tests to troubleshoot and resolve problems with the multicast component of a VPLS or a VPRN service.
BIER ping
The BIER ping OAM diagnostic test, which is called bier-ping in CLI, confirms connectivity within a BIER-enabled multicast network. Test packets are generated and sent in a specified sub-domain. Bier ping tests can be configured to specify a BFR ID, a range of BFR IDs, or a BFR prefix.
See To create and run a BIER ping OAM diagnostic test from the STM for information about how to create and run a BIER ping OAM diagnostic test from the STM.
BIER trace
The BIER trace OAM diagnostic test, which is called bier-trace in CLI, identifies the hop-by-hop route within a BIER-enabled multicast network. Test packets are generated and sent in a specified sub-domain from any BFR to any other BFR. BIER trace tests can be configured to specify a BFR ID or a BFR prefix.
See To create and run a BIER trace OAM diagnostic test from the STM for information about how to create and run a BIER trace OAM diagnostic test from the STM.
MFIB ping
The multicast FIB (MFIB) ping OAM diagnostic test, which is called mfib-ping in CLI, identifies the SAPs that egress an IP multicast stream within a multicast component of a VPLS. This diagnostic test can also be used to display the SAPs that are operationally up in the VPLS.
See To create and run an MFIB ping OAM diagnostic test from the STM for information about how to create and run an MFIB ping OAM diagnostic test from the STM.
Mrinfo
The Mrinfo (multicast router information) OAM diagnostic test, which is called mrinfo in CLI, identifies VPRN multicast information for the target router. The information includes details that are related to adjacent routers, supported protocols, traffic metrics, and time-to-live thresholds. Administrators can use this information to identify bidirectional adjacency relationships.
See To create and run an Mrinfo OAM diagnostic test from the STM for information about how to create and run a Mrinfo OAM diagnostic test from the STM.
Mtrace
The Mtrace (multicast trace) OAM diagnostic test, which is called mtrace in CLI, identifies the hop-by-hop route used by VPRN multicast traffic to reach the target router. This diagnostic gathers the hop address, routing error conditions, and packet statistics at each hop. The NFM-P attempts to trace the receiver-to-sender route for the traffic. The destination of the diagnostic can be any PIM-enabled interface in the routing instance.
In this test, the command sends a ping to the head of the specified multicast group (which can be one or more hops away from the launch NE). If that ping fails, the command will ping the neighboring NE, then the neighbor's neighbor, and so on up the multicast group chain to determine which NE fails to respond.
See To create and run an Mtrace OAM diagnostic test from the STM for information about how to create and run an Mtrace OAM diagnostic test from the STM.
Mtrace2
The Mtrace2 (multicast trace version 2) OAM diagnostic test, which is called mtrace2 in CLI, is similar to the Mtrace OAM test, but with added functionality for isolating packet loss problems and configuration problems. Tests are initiated from an Mtrace2 client toward a specified source, or a Rendezvous Point (RP) if no source address is specified. In the STM configuration, there is an option for StarG, which allows initiation from any source. Mtrace2 uses UDP-based messages, and supports base router and VPRN instances. Both IPv4 and IPv6 are supported.
See To create and run an Mtrace2 OAM diagnostic test from the STM for information about how to create and run an Mtrace2 OAM diagnostic test from the STM.
ICMP
Use the ICMP OAM diagnostic tests to troubleshoot and resolve IP reachability problems; for example, to send error messages indicating that a requested VPRN service is not available or that a host or router could not be reached.
ICMP ping
The ICMP ping OAM diagnostic test, which is called icmp-ping in CLI, identifies the reachability of a remote host across the IP network. The test is used with ICMP trace to detect and localize faults in IP networks.
You can also enable the ICMP ping OAM diagnostic test from the VRF site of a subscriber VPRN service. An ICMP ping determines the existence of the far-end egress point of the service. This allows testing of whether a specific destination can be reached. ICMP pings can be sent in-band or out-of-band.
ICMP ping tests can be used to control the operational state of L3 service SAPS. On supporting NEs, users can configure a policy-based ICMP ping template and apply it to all required IES and VPRN L3 interfaces. The interfaces can use the template to populate ICMP ping test configuration values. For more information about ICMP ping templates, see To configure an ICMP Ping template.
See To create and run an ICMP ping OAM diagnostic test from the STM for information about how to create and run an ICMP ping OAM diagnostic test from the STM.
ICMP trace
The ICMP trace OAM diagnostic test, which is called icmp-trace in CLI, identifies the diagnostic used to trace the ICMP traceroute control table. The tool is used with ICMP ping to detect and localize faults in IP networks.
ICMP trace displays the hop-by-hop path for a destination IP address within a VPRN service. This allows operators to know the destination path of subscriber traffic. ICMP traces can be sent in-band or out-of-band.
See To create and run an ICMP trace OAM diagnostic test from the STM for information about how to create and run an ICMP trace OAM diagnostic test from the STM.
DNS ping
The DNS ping OAM diagnostic test, which is called dns-ping in CLI, identifies the diagnostic used to ping the DNS name, if a DNS name resolution is configured. See To create and run an ICMP DNS ping OAM diagnostic test from the STM for information about how to create and run a DNS ping OAM diagnostic test from the STM.
VWM diagnostic test
Use the VWM OAM diagnostic tests to detect signal failures between two 1830 VWM TLUs or two 1830 VWM ITPs.
PRBS test
You can verify the data path between two 1830 VWM TLUs or two 1830 VWM ITPs by performing the PRBS test. The test is performed by generating PRBS signals, transmitting the signals through a daisy chain of interfaces, and looping them back to detect signal failures.
The NFM-P allows you to run the PRBS test and view the results. The PRBS measurements are performed on client or line ports of the 1830 VWM TLU and 1830 VWM ITP devices and loopbacks are configured on client or line ports of the 1830 VWM TLU and 1830 VWM ITP devices. The administrative state of both ports is set to Maintenance before the PRBS test is performed.
You can stop the test manually at any time or automatically after the configured duration has elapsed. On the same port, a new measurement can only be started after the previous measurement is stopped. The result of a measurement on a specific port is lost when a new measurement is started on the same port.
The result of the test is obtained by reading the number of errors detected in the received PRBS signal in the 1830 VWM TLU or 1830 VWM ITP.
See To create and run a PRBS test for more information about performing the PRBS test.
AOS CPE OAM diagnostic tests
Use the AOS CPE OAM diagnostic tests to perform L2 ping and link traces on select OmniSwitch devices in Metro Ethernet networks. See Sample OmniSwitch device SLA testing in Chapter 89, Service Test Manager for more information.
CPE SLA test
The NFM-P STM allows you to perform a CPE SLA OAM diagnostic test to validate and test customer SLAs used on select OmniSwitch devices in Metro Ethernet networks. The test is critical for provisioning or troubleshooting network services between customer endpoints. The NFM-P STM allows you to test supports unidirectional traffic and IPv4.
See Sample OmniSwitch device SLA testing for information about how to configure a CPE SLA OAM diagnostic test using the STM.
CPE SLA test group
The CPE SLA test group allows you to perform a CPE SLA test-head test using one CPE test-head profile or a group of profiles. You can also run several tests for one CPE test-head profile or group of profiles.
See Sample OmniSwitch device SLA testing for information about how to create a CPE SLA test-head Group profile using the STM, which can be use to bind individual CPE test-head profiles to form a group of tests.
Non-STM OAM diagnostic and validation tests
The following OAM diagnostic and validation tests are configured from alternate launch points on the NFM-P GUI other than the STM.
OmniSwitch ping and traceroute OAM test
The OmniSwitch ping and traceroute OAM diagnostic test uses user-defined CLI scripts to allow you to troubleshoot and resolve problems with IP reachability on an OmniSwitch.
See To create an OmniSwitch ping or traceroute OAM diagnostic test using a CLI script for information about creating an OmniSwitch ping or traceroute OAM diagnostic test using a CLI script.
See To configure and run an OmniSwitch OAM diagnostic ping test CLI script and To configure and run an OmniSwitch OAM traceroute test CLI script for information about configuring and running an OmniSwitch ping and traceroute CLI scripts.
OmniSwitch advanced loopback test
The OmniSwitch advanced loopback test allows you to troubleshoot and resolve network faults on OmniSwitch ports to isolate the network segments where errors have occurred. See To configure an advanced loopback test on an OmniSwitch from a device Properties form for information about configuring an OmniSwitch advanced loopback test.
F5 OAM loopback test (7705 SAR-M/ME)
The F5 OAM loopback test allows you to validate ATM bonding on DSL ports on a 7705 SAR-M/ME device equipped with a DSL module. The parameters for the F5 OAM loopback test are only visible when a DSL module is connected to an ISAM device with the bonding type of ATM and the device is operationally up.
See To run the F5 OAM loopback diagnostic test from a 7705 SAR-M/ME Properties form for information about configuring an F5 OAM loopback test.
802.3ah EFM OAM diagnostic test
An 802.3ah EFM OAM diagnostic test addresses three key operational issues when deploying Ethernet across geographically disparate locations: link monitoring, fault signaling, and remote loopback.
Link monitoring provides some basic error definitions for Ethernet so entities can detect failed and degraded connections. Fault signaling provides mechanisms for one entity to signal another that it has detected an error. Remote loopbacks allows one NE to put another NE into a state whereby all inbound traffic is immediately reflected back onto the link.
The 802.3ah EFM OAM test supports:
You can configure a 802.3ah EFM OAM diagnostic test on Ethernet ports in network mode on the 7210 SAS, 7450 ESS, 7705 SAR, 7750 SR, and 7950 XRS. See To configure an 802.3ah EFM OAM diagnostic test from an NE Properties form for more information.
For OmniSwitch NEs, the 802.3ah EFM OAM diagnostic test is supported at the NE level or at the Ethernet port level on the Ethernet ports in network mode. See To configure an 802.3ah EFM OAM diagnostic test on an OmniSwitch Properties form for more information.
One-time service validation test
A one-time service validation test provides a mechanism to quickly test a service or composite service either at the time it is provisioned or when it is already in service.
A variety of services and transport components can be tested using this function including:
A one-time service validation test operates like a Validator test suite however the temporary objects that are automatically created for this method are deleted upon its completion. Items deleted include the test suite, tests, MEGs, and MEPs. No user action is required to do this.
Another significant difference with the One-time service validation test is that no results file is created. Instead, all tests and results are stored as archived objects that remain after the test is finished. The results can be viewed in the NFM-P GUI. See the XML API Reference (oneTimeValidate under sas.TestManager) for the required syntax to view the results using the XML API.
Executing a one-time service validation test also updates the OAM Validation Failed state field as required, indicating whether or not the validation was successful.
See To run a one-time validation test on a service for information about configuring a one-time service validation test.