sam oam overview v2
TRANSCRIPT
5620 SAM OAM..........................................................5Reference Network.....................................................6Infrastructure OAM....................................................6LSP Diagnostics.....................................................6LSP ping..........................................................7LSP Ping Example................................................7
LSP trace........................................................10LSP Trace Example..............................................11
SDP OAM............................................................15SDP Ping.........................................................16SDP MTU Path Discovery...........................................17Example SDP OAM................................................17
LDP Tree Trace OAM.................................................21Example LDP Tree Trace...........................................21
Service Related OAM..................................................24Service Site Ping..................................................24Example Service Site Ping........................................24
VPLS OAM...........................................................28MAC ping.........................................................28MAC PING Example...............................................29
MAC Trace........................................................32Example MAC Trace..............................................34
MAC Populate.....................................................36MAC Populate Example...........................................37
MAC purge........................................................41MAC Purge Example..............................................41
CPE ping.........................................................43Example CPE Ping...............................................43
MEF MAC Ping.....................................................46VLL OAM............................................................46VCCV Ping........................................................46VCCV-Ping Application..........................................46VCCV Ping Example..............................................48
VCCV-Ping in a Multi-Segment Pseudowire..........................49Example Multi-Segment VCCV-Ping................................50
VPRN ping and VPRN trace...........................................53Example VPRN Ping................................................53Example VPRN Trace.............................................55
CFM 802.1ag........................................................57Example 802.1ag................................................59CFM Continuity Check (CC)......................................63
ANCP Loopback....................................................69ICMP ping........................................................69ICMP trace.......................................................69DNS ping.........................................................69
Multicast OAM......................................................70Multicast FIB ping...............................................70
Multicast router information.....................................70Multicast trace..................................................70ATM OAM ping.....................................................70
Subscriber host connectivity verification..........................70Service assurance system overview....................................71Test Policies......................................................71Test Suites........................................................71Sample SAS Implementation........................................72
Sample SAS implementation configuration sequence.....................73Test Suite Policy for VLL............................................75Test Suite Policy for VPLS...........................................75Test Suite Policy for VPRN...........................................75Test Suite Policy for MPLS Service Transport.........................75
Figure 1: Reference Network Physical Topology.........................6Figure 2: LSP Ping....................................................7Figure 3: Test Reference LSP..........................................7Figure 4: LSP GUI Form................................................8Figure 5: LSP Ping Form...............................................8Figure 6: LSP Ping Test Attributes....................................9Figure 7: LSP Ping Results............................................9Figure 8: LSP Ping CLI-GUI...........................................10Figure 9: LSP Trace..................................................11Figure 10: LSP Trace Form............................................11Figure 11: LSP Trace Results.........................................12Figure 12: LSP Trace Hops............................................12Figure 13: LSP Trace to CLI Match....................................13Figure 14: LSP Trace on Reference Network............................13Figure 15: LSP Trace using CPAM......................................14Figure 16: CPAM LSP Path.............................................14Figure 17: ISIS Link Form............................................15Figure 18: LSP Node Bypass Details...................................15Figure 19: SDP Service OAM...........................................16Figure 20: SDP 1593 on Reference Network.............................17Figure 21: SDP Form..................................................18Figure 22: SDP Ping Form.............................................18Figure 23: SDP Ping Results..........................................19Figure 24: SDP MTU Ping Form.........................................19Figure 25: MTU Ping Probe Details....................................20Figure 26: MTU Discovery Results.....................................20Figure 27: MTU Discovery CLI-SAM.....................................21Figure 28: LDP Tree Trace Ref Network................................22Figure 29: CPAM ECMP Display.........................................22Figure 30: LDP Tree Trace Form.......................................23Figure 31: LDP T Trace Result........................................23
Figure 32: LDP Tree Trace CLI........................................24Figure 33: Service Site Ping Form....................................25Figure 34: Service Site Ping Test Parameters.........................25Figure 35: Service Site Test Results (GUI)...........................26Figure 36: svc-ping CLI Results......................................26Figure 37: CPAM Highlight Service....................................27Figure 38: CPAM Highlight Service Options............................27Figure 39: CPAM Highlight Service Details............................28Figure 40: MAC Ping..................................................29Figure 41: VPLS Reference Service....................................30Figure 42: MAC Ping Form.............................................30Figure 43: MAC Ping Test Parameters..................................31Figure 44: MAC Ping Results..........................................31Figure 45: MAC Ping Results Deeper...................................32Figure 46: MAC Ping CLI..............................................32Figure 47: MAC Trace.................................................33Figure 48: MAC Trace GUI Form........................................34Figure 49: MAC Trace Parameters......................................34Figure 50: MAC Trace Detailed Info...................................35Figure 51: CLI MAC Trace.............................................36Figure 52: MAC Populate Form.........................................38Figure 53: SAP before MAC Populate...................................38Figure 54: MAC Populate Result.......................................39Figure 55: VPLS FIB..................................................40Figure 56: VPLS FIB (2)..............................................40Figure 57: MAC Purge Form............................................42Figure 58: FDB after purge...........................................42Figure 59: CPE Ping Test Architecture................................43Figure 60: CPE Ping Test Injection Point.............................44Figure 61: CPE Ping Form.............................................44Figure 62: CPE Ping Results..........................................45Figure 63: VCCV Ping.................................................46Figure 64: Control Word Format.......................................47Figure 65: VCCV TLV..................................................47Figure 66: VCCV Ping Form............................................48Figure 67: VCCV Ping Results.........................................49Figure 68: VCCV-Ping Multi-Segment PW................................50Figure 69: MS VCCV-Ping..............................................51Figure 70: MS VCCV Ping Form.........................................51Figure 71: MS VCCV Ping Result.......................................52Figure 72: MS VCCV Trace Result......................................52Figure 73: CLI MS VCCV Trace.........................................53
Table 1: OAM Test Table...............................................5
5620 SAM OAM
The proper delivery of services requires a number of operations must occur correctly at different levels within the service creation model. For example, operations such as the association of packets to a service,VC labels to a service, and each service to a service tunnel (SDP) must be performed successfully for the service to pass traffic to subscribersas agreed to according to SLAs.
Even when tunnels are operating correctly and are correctly bound to services, incorrect FIB information may cause connectivity issues.
To verify that a service is operational and that FIB information is correct, a set of configurable in-band or out-of-band, packet-based Operations, Administration, and Maintenance (OAM) tools are available. Each OAM diagnostic has the ability to test each of the individual packet operations.
For in-band, packet-based testing, the OAM packets closely resemble customer packets to effectively test the customer's forwarding path. However, these packets are distinguishable from customer packets, so they are kept within the service provider's network and not forwarded tothe customer. For out-of-band testing, OAM packets are sent across some portion of the transport network, for example, across LSPs to test reachability.
The supported OAM test types, the objects against which the tests can beperformed and the network layer being tested are listed below.
Table 1: OAM Test Table
Network Level Test Type Network object or service component for test
Application (level 7)
DNS Lookup DNSDNS Lookup DHCP
Ethernet Loopback PortsLink TraceContinuity Check
Service (Level 6) VPRN Ping VPRN SiteVPRN TraceICMP PingICMP TraceCPE Ping VPLS Site
Epipe SiteMFIB PingANCP Lookup Network ElementVCCV Ping VLLMAC Populate VPLS Site
Epipe SiteMEF MAC Ping is supported on 7250 SAS
MAC PingMEF MAC PingMAC TraceMAC Purge
Service Transport (Level 4)
MTU Ping Service TunnelSDP Ping
Transport (Level 3) LSP Ping LSPLSP PathLSP Trace
LDP Ping MPLS SiteLDP TraceLDP Tree Trace
Routed Network (Level 2)
ICMP Ping IP Unicast Traffic
ICMP TracerouteOS 6850 ping and traceMulticast Trace IP Multicast TrafficMulticast statMulticast router information
Layer 1 or Layer 2 (Level 1)
MAC Ping Ethernet
MAC TracerouteATM Ping ATM PVC Connection
Reference Network
Throughout this document, examples will be given demonstrating some of the OAM tests available via the 5620 SAM. The tests will be run against a reference network whose physical topology is shown below.
Figure 1: Reference Network Physical Topology
Infrastructure OAM
LSP Diagnostics
The ALU OS LSP diagnostics are implementations of LSP ping and LSP traceroute based onRFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. In an LDPECMP network, a unique-path trace can be accomplished by specifying a unique 127/8 IP address for the path-destination.
The ALU devices support unique-path trace on an LER of an LDP ECMP path.LSP ping, as described in the draft, provides a mechanism to detect data-plane failures in MPLS LSPs. LSP ping and LSP Traceroute are modelled after the ICMP echo request/reply used by ping and traceroute to detect and localise faults in IP networks.
For a given FEC, LSP ping verifies whether the packet reaches the egresslabel edge router (LER), while in LSP traceroute mode, the packet is sent to the control plane of each transit label switched router (LSR) which performs various checks to see if it is actually a transit LSR forthe path.
LSP ping
The LSP ping OAM, which is called an lsp-ping in CLI, performs in-band LSP connectivity tests.In an LSP ping OAM, 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 2: LSP Ping
LSP Ping Example
Using the reference network an LSP has been set up with 200.0.0.59 as the source and 200.0.0.81 as the destination, set to use a ‘HOPLESS PATH’, i.e. loose.
Figure 3: Test Reference LSP
The LSP can be viewed on the 5620 SAM GUI, showing all LSP attributes.
Figure 4: LSP GUI Form
Via the 5620 SAM Test Manager, an LSP Ping OAM Test is configured (note the NE Schedulable option should be selected for test where either SAA and/or Threshold Crossing Alerts are required).
Figure 5: LSP Ping Form
Test parameters can be set for the LSP Ping, including:
Number of Test Probes Probe Interval (secs) Probe Timeout (secs)
Probe Size (octets) TTL FC Fwd Profile
Figure 6: LSP Ping Test Attributes
Once the test is saved on the GUI it is also applied to the network element. The user initiates the test by selecting the ‘Execute’ option. The test is run and the results returned to the SAM server.
Figure 7: LSP Ping Results
The LSP Ping can be executed in CLI and the detailed results matched to the SAM GUI configuration forms. For example, in the CLI output below displaying the same LSP Ping test, we can see the actual hops the LSP Ping took, with the associated labels. We can see the 5620 SAM confirms the sequence of push, swap, swap and pop labels and the next hop interfaces used.(Note: NTP must be configured on all tests that require accurate timing)
Figure 8: LSP Ping CLI-GUI
LSP trace
The LSP trace OAM, which is called an lsp-trace in CLI, displays the hop-by-hop route used by the LSP.
In an LSP trace OAM, the originating router creates an MPLS echo requestpacket for the LSP to be tested. The packet contains increasing values of the Time To Live (TTL) setting in the outermost label. 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 9: LSP Trace
LSP Trace Example
Using the same LSP as in the example for LSP Ping, we can create an LSP Trace Test from within the LSP form (or create one directly using the STM manager tool bar).
Figure 10: LSP Trace Form
Executing from the GUI, the results can be viewed under the “Results” tab.
The general results shows whether the test was successful or not, plus the trace details such as Forwarding Class the test was done over.
Figure 11: LSP Trace Results
Under the Hops and Probes tab, the trace can be viewed in greater detail, showing such things as interfaces used, labels and MTUs along the LSP Path.
Figure 12: LSP Trace HopsThe test can be triggered under CLI, and again matched to GUI responses.The example below shows the details on HOP-1 of the LSP
Figure 13: LSP Trace to CLI Match
Using the Trace information we now map the LSP to the test topology.
Figure 14: LSP Trace on Reference Network
The 5650 CPAM can also be used to provide OAM trace functionality for LSPs.
Using one of the topology views created by CPAM, the user can select a number of options to graphically display LSP routes through he network.
Figure 15: LSP Trace using CPAM
In the example below, the ‘Active Path’ of LSP 166 has been selected forviewing.
Figure 16: CPAM LSP PathThe display highlights all interfaces used by the LSP. The user can select any of the logical links within the path, and by selecting the properties option can display the full interface configuration form, in the example below we have selected the highlighted link between nodes 200.0.0.59 and 200.0.0.60 and the ISIS link sourced on node 200.0.0.59 is being displayed.
Figure 17: ISIS Link Form
The dotted black lines within the CPAM Trace display denote bypass protection for a specific node. Selecting any of these links and highlighting them will then display the LSP route should x-node fail. Inthe example below we can see the LSP path should node 200.0.0.59 or its
resources, become unavailable. The example shows that the bypass route would now be 59 > 61 > 82> 80>81
Figure 18: LSP Node Bypass Details
SDP OAM
The 5620 SAM SDP diagnostics include SDP Ping and SDP MTU Path Discovery
The diagram below shows how OAM troubleshooting tools can be used to fixservice problems. A tunnel OAM packet can be inserted to test the connectivity between two customer LANs across the IP/MPLS core.
Figure 19: SDP Service OAM
SDP Ping
The Tunnel ping OAM, which is called an sdp ping in the CLI, performs in-band unidirectional or bidirectional connectivity tests on service tunnels. The OAM packets are sent in-band, in the tunnel encapsulation, so they follow the same path as the service traffic. The response can bereceived out-of-band in the control plane, or in-band using the data plane for a bidirectional test.
For a unidirectional test, SDP ping OAM tests:
Egress SDP ID encapsulation Ability to reach the far-end IP address of the SDP ID within the
SDP encapsulation Path MTU to the far-end IP address over the SDP ID Forwarding class mapping between the near-end SDP ID encapsulation
and the far-end tunnel termination
For a round-trip test, SDP ping uses a local egress SDP ID and an expected remote SDP ID. SinceSDPs are uni-directional tunnels, the remote SDP ID must be specified and must exist as a configured SDP ID on the far-end 7750 SR. SDP round trip testing is an extension of SDP connectivity testing with the additional ability to test:
Remote SDP ID encapsulation Potential service round trip time
Round trip path MTU Round trip forwarding class mapping
SDP MTU Path Discovery
In a large network, network devices can support a variety of packet sizes that are transmitted across its interfaces. This capability is referred to as the Maximum Transmission Unit (MTU) of network interfaces. You must consider the MTU of the entire path end-to-end whenyou provision services, especially for VLL services where the service must support the ability to transmit the largest customer packet.
Example SDP OAM
Using the reference network, we can see there is an SDP sourced on 200.0.059 whose destination is 200.0.0.82
Figure 20: SDP 1593 on Reference Network
The SAM SDP form, as with the LSP forms, contains a ‘Tests’ tab where any tests assigned to the SDP can be viewed, create or executed.
Figure 21: SDP FormCreating the test is identical to the process to create a LSP Ping, withthe additional option of nominating the return SDP ID
Figure 22: SDP Ping Form
Test result details are viewed under the ‘Results’ tab (note the round-trip, jitter and delay values within the example are not applicable as no NTP had been configured on reference network)
Figure 23: SDP Ping Results
For the SDP MTU Discovery, operators would choose the MTU Ping test. If the test is created from within the SDP form, all SDP attributes are automatically filled in (such as source node, SDP ID etc)
Figure 24: SDP MTU Ping Form
Operators can decide on the probe details, such as the start/stop MTU size; MTU step and the interval between probes (Note by default the start MTU is 40 octets with 1 second between each probe, so discovering large MTU SDPs could potentially take a few minutes). In the example below we have set the test to start at 1380 octets.
Figure 25: MTU Ping Probe Details
The results tab shows the details of test, in the lab example a maximum MTU of 1476 octets has been found for this SDP
Figure 26: MTU Discovery Results
Via CLI, the user would choose “oam sdp-mtu” as the test. The screen shot below show how the CLI results are displayed when executed from the5620 SAM.
Figure 27: MTU Discovery CLI-SAM
LDP Tree Trace OAM
The LDP tree trace OAM tool, which is called LDP-Treetrace in OAM level of the CLI, is used to detect and discover the ECMP routing paths for a LSP between egress and ingress routers. The following information is determined from the test:
Number of ECMP paths Number of failed hops
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 discoversa 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. Once discovered, the paths are tested using LSP ping and LSP trace.
Example LDP Tree Trace
Referring to the reference network, the example LDP Trace will attempt to find all possible ECMP routes between source node 200.0.0.59 and 200.0.0.81. All TE metrics have been made the same and ECMP has been enabled on 200.0.0.59.
There should therefore be two possible routes, one using the northern nodes the other using the southern node.
Figure 28: LDP Tree Trace Ref Network
Using CPAM, we can initiate a SPF lookup between our source and destination nodes, the resulting display shows two ECMP routes, one through .60 and .80 the other via .61 and 82
Figure 29: CPAM ECMP Display
LDP Tree Trace Tests are configured via the Service Test Manager, under the MPLS options. The test inputs include:
Test Object Site ID – System Address of the source node LDP Prefix - System Address of destination node
Figure 30: LDP Tree Trace Form
The results form shows that indeed two discovered paths.
Figure 31: LDP T Trace Result
When the same test is run via CLI (using oam ldp-treetrace prefix x.x.x.x/xx) the result gives greater detail on the actual paths found, including hop by hop interfaces)
Figure 32: LDP Tree Trace CLI
Service Related OAM
Service Site Ping
The Service Site Ping diagnostic, which is a svc-ping in the CLI, provides end-to-end connectivity testing for an individual service. Thisdiagnostic operates at a higher level than the tunnel 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 the port which is the endpoint of the service tunnel.
The diagnostic tests a service ID for correct and consistent provisioning between two service endpoints. The following information can be obtained from a circuit ping OAM:
Verification that the local and remote service exists Verification of the current state of the local and remote service Ensuring that the local and remote service types are correlated Ensuring that the same customer is associated with the local and
remote service Ensuring that there is a service to circuit association with both
the local and remote service Verification that the local and remote ingress and egress service
labels match
Example Service Site Ping
From the Service Test Manager Toolbar, use the Create Service Site Ping option. Test name details can be filled in along with the source site from which the test will be initiated from.
Figure 33: Service Site Ping Form
Under the Test Parameters tab, the user selects the destination service site plus the service ID to be tested.
Figure 34: Service Site Ping Test Parameters
The SAM tests the returned results and gives a success conformation to the initiator.
Figure 35: Service Site Test Results (GUI)
Running the test via CLI does give greater detail on the test results, displaying information on the Egress/Ingress Labels; SDP-IDs used; Customer ID; Service MTU and vc-type.
Figure 36: svc-ping CLI Results
The CPAM can also be used to graphically display elements of a nominatedservice. Once the service has been selected for highlighting, dotted lines display the endpoints of the service.
Figure 37: CPAM Highlight Service
Selecting any of the lines opens up for options for display
Figure 38: CPAM Highlight Service Options
The example display below for Epipe Service ID=2, shows that the nodes in the active path for the SDP/LSP from 200.0.59 to 200.0.0.81 are bypass protected whilst the SDP/LSP from 200.0.0.81 to 200.0.0.59 takes a different route with no node bypass.
Figure 39: CPAM Highlight Service Details
VPLS OAM
While LSP ping, SDP ping and service ping tools enable transport tunnel testing and verify whether the correct transport tunnel is used, they donot provide the means to test the learning and forwarding functions on aper-VPLS-service basis.
It is conceivable, that while tunnels are operational and correctly bound to a service, an incorrectForwarding Information Base (FIB) table for a service could cause connectivity issues in the service and not be detected by the ping tools. Alcatel-Lucent has developed VPLS OAM functionality to specifically test all the critical functions on a per-service basis.
The VPLS OAM tools are:
MAC Ping — provides an end-to-end test to identify the egress customer-facing port where a customer MAC was learned. MAC ping can also be used with a broadcast MAC address to identify all egress points of a service for the specified broadcast MAC.
MAC Trace — provides the ability to trace a specified MAC address hop-by-hop until the last node in the service domain. An SAA test with MAC trace is considered successful when there is a reply froma far-end node indicating that they have the destination MAC address on an egress SAP or the CPM.
CPE Ping — provides the ability to check network connectivity to the specified client device within the VPLS. CPE ping will return the MAC address of the client, as well as the SAP and PE at which it was learned.
MAC Populate — allows specified MAC addresses to be injected in the VPLS service domain. This triggers learning of the injected MAC address by all participating nodes in the service. This tool is generally followed by MAC ping or MAC trace to verify if correct learning occurred.
MAC Purge — Allows MAC addresses to be flushed from all nodes in aservice domain.
MAC ping
The MAC ping OAM, which is called a mac-ping in CLI, is used to test connectivity in a VLL or VPLS service by verifying a remote MAC address.The diagram below shows a sample MAC ping from one end of a service to the far-end MAC address of the service.
Figure 40: MAC Ping
For a MAC ping test, the destination MAC address (unicast or multicast) to be tested must be specified. A MAC ping packet can be sent through the control plane or the data plane. When sent by the control plane, theping packet goes directly to the destination IP in a UDP/IP OAM packet.If it is sent by the data plane, the ping packet goes out with the data plane format.
In the control 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 (if they are active). Finally,a response is generated only when there is an egress SAP binding to thatMAC address. A control plane request is responded to via a control replyonly.
In the data plane, a MAC ping is sent with a VC label TTL of 255. This packet traverses each hop using forwarding plane information for next hop, VC label, etc. The VC label is swapped at each service-aware hop, and the VC TTL is decremented. If the VC TTL is decremented to 0, the packet is passed up to the management plane for processing. If the packet reaches an egress node, and would be forwarded out a customer facing port, it is identified by the OAM label below theVC label and passed to the management plane. MAC pings are flooded when they are unknown at an intermediate node. They are responded to only by the egress nodes that have mappings for that MAC address
MAC PING Example
Using the multi-site VPLS service, displayed below, a reference:
Figure 41: VPLS Reference Service
Creating a MAC Ping test can be done from within the service form or directly under the Service Test Manager.
Figure 42: MAC Ping Form
As will most OAM tests, the user can define how many and how often test probes are sent plus the forwarding class the test packets should be deployed over.
Figure 43: MAC Ping Test Parameters
The test results show that 6 responses have been received.
Figure 44: MAC Ping Results
Under the Responders and Probes tab, the details of each returned SAP can be seen.
Figure 45: MAC Ping Results Deeper
And via CLI, the SAP responses to the MAC Ping test
Figure 46: MAC Ping CLI
MAC Trace
A MAC trace functions like an LSP trace with some variations. Operationsin a MAC trace are triggered when the VC TTL is decremented to 0.
Like a MAC ping, a MAC trace can be sent either by the control plane or the data plane.
For MAC trace requests sent by the control plane, the destination IP address is determined from the control plane mapping for the destinationMAC. If the destination MAC is known to be at a specific remote site, then the far-end IP address of that SDP is used. If the destination MAC is not known, then the packet is sent unicast, to all SDPs in the service with the appropriate squelching.
A control plane MAC traceroute request is sent via UDP/IP. The destination UDP port is the LSP ping port. The source UDP port is whatever the system gives (note that this source UDP port is really the demultiplexor that identifies the particular instance that sent the request, when correlating the reply). The source IP address is the system IP of the sender.
When a traceroute request is sent via the data plane, the data plane format is used. The reply can be via the data plane or the control plane.
A data plane MAC traceroute request includes the tunnel encapsulation, the VC label, and theOAM followed by an Ethernet DLC, a UDP and IP header. If the mapping forthe MAC address is known at the sender, then the data plane request is sent down the known SDP with the appropriate tunnel encapsulation and VClabel. If it is not known, then it is sent down every SDP (with the appropriate tunnel encapsulation per SDP and appropriate egress VC labelper SDP binding).
The tunnel encapsulation TTL is set to 255. The VC label TTL is initially set to the min-ttl (default is 1). The OAM label TTL is set to2. The destination IP address is the all-routers multicast address. The source IP address is the system IP of the sender.
The destination UDP port is the LSP ping port. The source UDP port is whatever the system gives(Note that this source UDP port is really the demultiplexor that identifies the particular instance that sent the request, when correlating the reply).
The Reply Mode is either 3 (i.e., reply via the control plane) or 4 (i.e., reply through the data plane), depending on the reply-control
option. By default, the data plane request is sent with Reply Mode 3 (control plane reply).
The Ethernet DLC header source MAC address is set to either the system MAC address (if no source MAC is specified) or to the specified source MAC. The destination MAC address is set to the specified destination MAC. The Ether Type is set to IP.
Figure 47: MAC TraceExample MAC Trace
Using the same VPLS service that the MAC Ping was generated for, a MAC Trace has now been created from within the Service Creation Form ( Test can also be created directly under the Service Test Manager).
Figure 48: MAC Trace GUI Form
Test parameters are as per the MAC Ping.
Figure 49: MAC Trace Parameters
The results for MAC Trace contain a lot more detail than that for MAC Ping. Results include responses from the CPMs and SAPs involved, giving mappings to SDP used.
Figure 50: MAC Trace Detailed Info
Running the test under CLI (oam mac-trace service x destination-mac) thesame level of detail is seen as with the GUI form results.
Figure 51: CLI MAC Trace
MAC Populate
MAC Populate is used to send a message through the flooding domain to learn a MAC address as if a customer packet with that source MAC addresshad flooded the domain from that ingress point in the service. This allows the provider to craft a learning history and engineer packets in a particular way to test forwarding plane correctness.
The MAC populate request is sent with a VC TTL of 1, which means that itis received at the forwarding plane at the first hop and passed directlyup to the management plane. The packet is then responded to by populating the MAC address in the forwarding plane, like a conventional learn although the MAC will be an OAM-type MAC in the FIB to distinguishit from customer MAC addresses.
This packet is then taken by the control plane and flooded out the flooding domain (squelching appropriately, the sender and other paths that would be squelched in a typical flood).
This controlled population of the FIB is very important to manage the expected results of an OAM test. The same functions are available by sending the OAM packet as a UDP/IP OAM packet. It is then forwarded to each hop and the management plane has to do the flooding.
Options for MAC Populate are to force the MAC in the table to type OAM (in case it already existed as dynamic or static or an OAM induced learning with some other binding), to prevent new dynamic learning to over-write the existing OAM MAC entry, to allow customer packets with this MAC to either ingress or egress the network, while still using the OAM MAC entry.
Finally, an option to flood the MAC Populate request causes each upstream node to learn the MAC (i.e., populate the local FIB with an OAMMAC entry), and to flood the request along the data plane using the flooding domain.
An age can be provided to age a particular OAM MAC after a different interval than other MACs in a FIB.
MAC Populate Example
MAC Populate can be instantiated either from within the service context or directly under Service Test Manager L2 Service Create Mac Populate.
The user specifies the MAC address to be placed in the fdb. The service is selected, the service site and the SAP to be configured. The other options are detailed in the test overview above.
In the example below, the MAC Address AA-11-11-11-11-AA will be populated into the fdb for sap 1/1/4:44.77 on router 200.0.0.60, within VPLS service ID 3 context.
Figure 52: MAC Populate Form
Before the test is run no FIB entries can be seen on the VPLS sap.
Figure 53: SAP before MAC Populate
CLI confirms that although FDB exists for VPLS ID 3, there are no entries.
CLI also confirms no MAC entries for any service on router 200.0.0.60
The results tab from the MAC Populate test confirms that the required MAC address has been sent to the nominated SAP.
Figure 54: MAC Populate Result
Viewing the FIB Entries for the nominated sap we can now see the MAC address entry.
Figure 55: VPLS FIB
Running the MAC Populate a second time with a different MAC address addsto the list.
Figure 56: VPLS FIB (2)
CLI fdb-info confirms there are now 2 FDB Entries learnt by OAM.
CLI confirms the MAC addresses are within the correct service context and on the required sap.
MAC purge
MAC Purge is used to clear the FIBs of any learned information for a particular MAC address.
This allows one to do a controlled OAM test without learning induced by customer packets. In addition to clearing the FIB of a particular MAC address, the purge can also indicate to the control plane not to allow further learning from customer packets. This allows the FIB to be clean,and be populated only via a MAC Populate.
MAC Purge follows the same flooding mechanism as the MAC Populate.
A UDP/IP version of this command is also available that does not follow the forwarding notion of the flooding domain, but the control plane notion of it.
MAC Purge Example
We will use the MAC purge, which is called a mac-purge in CLI, to deletethe OAM-tagged entry from the FIB which was generated using the MAC populate example. The MAC address AA-11-11-11-11-BB is targeted to be removed from the FDB.
Figure 57: MAC Purge Form
After the MAC Purge is run we can see the MAC entry has been removed from the FIB Entry table on the sap.
Figure 58: FDB after purge
CLI confirms the entry has been deleted from the nodal database.
CPE ping
The MAC ping OAM tool makes it possible to detect whether a particular MAC address has been learned in a VPLS.
The cpe-ping command extends this capability to detecting end-station IPaddresses inside a VPLS. A CPE ping for a specific destination IP address within a VPLS will be translated to a MAC-ping towards a broadcast MAC address. Upon receiving such a MAC ping, each peer PE within the VPLS context will trigger an ARP request for the specific IP address. The PE receiving a response to this ARP request will report back to the requesting 7750 SR. It is encouraged to use the source IP address of 0.0.0.0 to prevent the provider’s IP address of being learnedby the CE, this option though is only available through CLI.
Example CPE Ping
Using the reference network a CPE device is connected to node 200.0.0.59, with an IP address of 55.0.0.1. A VPLS sap is configured on VPLS ID = 14. The CPE is connected to port 1/1/4 with null encap set.
Figure 59: CPE Ping Test Architecture
The test is created which will inject the test request at router 200.0.0.81, which translates it into broadcast MAC address; as router
200.0.0.59 will get a response to the triggered ARP request, the CPE details will be returned to the testing context.
Figure 60: CPE Ping Test Injection Point
The CPE Ping Test can be initiated from within the VPLS service context form or directly under the Service Test Manager using L2 Service Create CPE Ping. The service context and injection site are selected in the form (auto-populated if done from within the VPLS form), and the CPE IP address is added as the Destination IP. The source node in this example has been set as the system IP of the 200.0.0.81 node.
Figure 61: CPE Ping Form
After the test has been run, the results are displayed. In the example he test showed successful, confirming the reply from node 200.0.0.59. The test also returns the CPE MAC address and the sap from which the ARPreply was received.
Figure 62: CPE Ping Results
Running the test via cli using (oam cpe-ping service 14 destination 55.0.0.1 source 200.0.0.81 sees the response plus RTT as per the SAM results display.
MEF MAC Ping
The MEF MAC ping OAM tool is used to test connectivity in a 7250 SAS-ES or 7250 SAS-ESA VPLS site by verifying a remote MAC address at the far end of the service.
VLL OAM
All the OAM tests described for VPLS can also be applied to VLL instances; however there are additional tests that can be run for the VLL services
VCCV Ping
VCCV ping is used to check connectivity of a VLL in-band. It checks thatthe destination (target) PE is the egress for the Layer 2 FEC. It provides a cross-check between the data plane and the control plane. It is in-band, meaning that the VCCV ping message is sent using the same encapsulation and along the same path as user packets in that VLL. This is equivalent to the LSP ping for a VLL service. VCCV ping reuses an LSPping message format and can be used to test a VLL configured over an MPLS and GRE SDP.
VCCV-Ping Application
Figure 63: VCCV Ping
VCCV effectively creates an IP control channel within the pseudowire between PE1 and PE2. PE2 should be able to distinguish on the receive
side VCCV control messages from user packets on that VLL. There are three possible methods of encapsulating a VCCV message in a VLL which translates into three types of control channels:
1. Use of a Router Alert Label immediately above the VC label. This method has the drawback that if ECMP is applied to the outer LSP label (for example, transport label), the VCCV message will not follow the same path as the user packets. This effectively means it will not troubleshoot the appropriate path. This method is supported by the 7750 SR.
2. Use of the OAM control word as illustrated below
Figure 64: Control Word Format
The first nibble is set to 0x1. The Format ID and the reserved fields are set to 0 and the channel type is the code point associated with the VCCV IP control channel as specified in the PWE3 IANA registry [RFC 4446]. The channel type value of 0x21 indicates that the Associated Channel carries an IPv4 packet.
The use of the OAM control word assumes that the draft-martini control word is also used on the user packets. This means that if the control word is optional for a VLL and is not configured, the7750 SR PE node will only advertise the router alert label as the CC capability in the Label Mapping message. This method is supported by the7750 SR.
3. Set the TTL in the VC label to 1 to force PE2 control plane to process the VCCV message. This method is not guaranteed to work under all circumstances. For instance, the draft mentions some implementations of penultimate hop popping overwrite the TTL field. This method is not supported by the 7750 SR.
When sending the label mapping message for the VLL, PE1 and PE2 must indicate which of the above OAM packet encapsulation methods (for example, which control channel type) they support. This is accomplished by including an optional VCCV TLV in the pseudowire FEC Interface Parameter field. The format of the VCCV TLV is shown below.
Figure 65: VCCV TLV
Note that the absence of the optional VCCV TLV in the Interface parameters field of the pseudowire FEC indicates the PE has no VCCV capability. The Control Channel (CC) Type field is a bit mask used to indicate if the PE supports none, one, or many control channel types.
0x00 None of the following VCCV control channel types are supported
0x01 PWE3 OAM control word 0x02 MPLS Router Alert Label 0x04 MPLS inner label TTL = 1
If both PE nodes support more than one of the CC types, then a 7750 SR PE will make use of the one with the lowest type value. For instance, OAM control word will be used in preference to the MPLS router alert label.
The Connectivity Verification (CV) bit mask field is used to indicate the specific type of VCCV packets to be sent over the VCCV control channel. The valid values are:
0x00 none of the below VCCV packet type are supported. 0x01 ICMP Ping. Not applicable to a VLL over a MPLS or GRE SDP and
as such is not supported by the 7750 SR. 0x02 LSP Ping. This is used in VCCV-Ping application and applies
to a VLL over an MPLS or a GRE SDP. This is supported by the 7750 SR.
A VCCV-Ping is an LSP Echo Request message as defined in RFC 4379. It contains an L2 FEC stack TLV which must include within the sub-TLV type 10 “"FEC 128" Pseudowire”. It also contains a field which indicates to the destination PE which reply mode to use. There are four reply modes defined in RFC 4379:
Reply Mode: Meaning:
1. Do not reply. This mode is supported by the 7750 SR.2. Reply via an IPv4/IPv6 UDP packet. This mode is supported by the
7750 SR.3. Reply via an IPv4/IPv6 UDP packet with Router Alert. This mode
sets the router alert bit in the IP header and is not be confused with the CC type which makes use of the router alert label. This mode is not supported by the 7750 SR.
4. Reply via application level control channel. This mode sends the reply message in-band over the pseudowire from PE2 to PE1. PE2
will encapsulate the Echo Reply message using the CC type negotiated with PE1. This mode is supported by the 7750 SR. The reply is an LSP echo reply message as defined in RFC 4379. The message is sent as per the Reply Mode requested by PE1. The returncodes supported are the same as those supported in the 7750 SR LSPping capability. The VCCV ping feature is in addition to the service ping OAM feature which can be used to test a service between 7750 SR nodes. The VCCV ping feature can test connectivityof a VLL with any third party node which is compliant to RFC 5085.
VCCV Ping Example
The VCCV Ping Test can be initiated from within the VLL service context form or directly under the Service Test Manager using Service Create VCCV Ping. The operator selects the SDP:VC binding on which the test should be sent, as the correct SDP is selected, the source/destination node/service I and service name are automatically populated.
Figure 66: VCCV Ping FormThe results of the test can be displayed via the SAM GUI, showing by default, 5 probes sent within the data plane.
Figure 67: VCCV Ping Results
Running the test from within CLI also provides the VCCV Ping Statistics
VCCV-Ping in a Multi-Segment Pseudowire
The figure below displays an example of an application of VCCV pings over a multi-segment pseudowire.
Pseudowire switching is a method for scaling a large network of VLL or VPLS services by removing the need for a full mesh of T-LDP sessions between the 7750 SR PE nodes as the number of these nodes grow over time. Pseudowire switching is also used whenever there is a need to deploy a VLL service across two separate routing domains.
In the network, a Termination PE (T-PE) is where the pseudowire originates and terminates. TheSwitching PE (S-PE) is the node which performs pseudowire switching by cross-connecting two spoke SDPs.
VCCV-Ping is extended to be able to perform the following OAM functions:
1. VCCV-Ping to a destination PE: A VLL FEC Ping is a message sent byT-PE1 to test the FEC at T-PE2. The operation at T-PE1 and T-PE2 is the same as in the case of a single segment pseudowire. The 7750 SR pseudowire switching node, S-PE1, pops the outer label, swaps the inner (VC) label, decrements the TTL of the VC label, and pushes a new outer label. The 7750 SR S-PE1 node does not process the VCCV OAM Control Word unless the VC label TTL expires.In that case, the message is sent to the CPM for further validation and processing.
Note that the originator of the VCCV-Ping message does not need to be a T-PE node; it can be an S-PE node. The destination of the VCCV-Ping message can also be an S-PE node.
2. VCCV-Trace to trace the entire path of a pseudowire with a single command issued at the T-PE: This is equivalent to LSP-Traceand is an iterative process by which T-PE1 sends successive VCCV-Ping messages while incrementing the TTL value, starting from TTL=1. The procedure for each iteration is the same as above and each node in which the VC label TTL expires checks the FEC and replies with the FEC to the downstream S-PE or T-PE node. The process is terminated when the reply is from T-PE2 or when a timeout occurs.
Figure 68: VCCV-Ping Multi-Segment PW
Example Multi-Segment VCCV-Ping
A multi-segment PW has been created with 200.0.0.59 and 200.0.0.81 as the T-PEs, with 200.0.0.61 as the S-PE.
Note also that the Control Word has to be set to ‘Preferred’ on each SDPbinding.
Figure 69: MS VCCV-Ping
A VCCV-Ping is configured from within the service context, identifying the fist spoke-sdp as the one from T-PE1 to S-PE1. The form then allows the user to select the next ‘hop’ sdp binding from s-PE1 to T-PE2
Figure 70: MS VCCV Ping FormAs can be seen from the results tab, the response to the VCCV-Ping is from 200.0.0.81 via the data plane.
Figure 71: MS VCCV Ping Result
The VCCV-Trace is set up in a similar way to the VCCV Ping; however on the first SDP Spoke biding is required as an input.
From the results we can see the service connect has been discovered as the end-to-end results of each hop is reported on.
Figure 72: MS VCCV Trace Result
Executing the vccv-trace via cli, we can again see only the initial spoke binding is required.
Figure 73: CLI MS VCCV Trace
VPRN ping and VPRN trace
The VPRN ping and VPRN trace OAM are enabled from the VRF site of the subscriber’s VPRN service. The VPRN ping OAM determines the existence ofthe far-end egress point of the service. VPRN pings can be sent in-band or out-of-band.
The VPRN trace OAM displays the hop-by-hop route used to reach the target address at the far-end. VPRN traces can be sent in-band or out-of-band.
VPRN ping results are available from the History and Faults tabs. VPRN trace results are available from the History, Faults, and L3 Map tabs.
Example VPRN Ping
In the example below a VPRN (ID=4000000) has been created on nodes 200.0.0.59 and 200.0.60. An IP interface (9.8.7.1) has been assigned to port 1/1/4:3.45 on 200.0.0.60 and another (55.0.0.2 on port 1/1/4 on router 200.0.59). A CPE device with IP address 55.0.0.1 is connected to the 200.0.0.59 node
Figure 74: VPRN Ping Test
The 5620 SAM view of the service is shown below, showing the access interfaces and the SDP bindings
Figure 75: VPRN SAM View
The VPRN Ping test can be set up from within the service context, or directly under Service Test Manager L3 Service Create VPRN Ping. The service details are added, plus the source and destination IP addresses
Figure 76: VPRN Ping Form
In the example below, the test is initiated from the 9.8.7.1 interface, and the result is conformed as successful with the correct SAP information.
Figure 77: VPRN Ping Results
Figure 78: CLI VPRN Ping
Example VPRN Trace
The VPRN Trace is set up in similar manner to the VPRN Ping.
Figure 79: VPRN Trace Form
The results for the trace on the same service used for the VPRN Ping, show two responses; one from the distant end CPM and the second hop fromthe SAP.
Figure 80: VPRN Trace Results
Figure 81: CLI VPRN Trace
CFM 802.1ag
The 5620 SAM implementation of the CFM (Connectivity Fault Manager) 802.1ag protocol provides a standard for detecting, isolating and reporting connectivity faults in an Ethernet network. 5620 SAM support for CFM 802.1ag provides:
path discovery fault detection fault verification and isolation fault notification
An Ethernet network enables CFM 802.1ag which partitions the network into 8 hierarchical MD (Maintenance Domain) levels. An MD is a network or part of a network that is managed using CFM 802.1ag protocol. Each MDis provisioned with a set of MAs (Maintenance Associations). Nodes and services are grouped into MAs. Typically one MA represents one service and consists of a group of MEPs (Maintenance Association End Points). Although one MA can be associated with one service, one service can be associated with more than one MA.
MEPs can be any SAP or SDP binding in a service and associated to a MA. A set of MEPs configured with the same MA ID defines a MA. CFM tests detect connectivity failures between any pair of local and remote MEPs in a MA. Each MEP is a provisioned reference point that can initiate or terminate one of the following CFM tests within the defined MA and MD:
CFM loopback
CFM Link Trace CFM Continuity Check
MEPs can be added to Services during service configuration or during CFMContinuity Check test configuration. MEPs can be applied to a single SAPor SDP binding or all SAPs and SDP bindings in the service sites. When the Direction parameter is set to up, a MEP can be associated with the following Ethernet services:
VLPS Ethernet SAP Ethernet Spoke SDP binding VLPS Ethernet Mesh SDP binding VLPS
When the Direction parameter is set to down, a MEP can be associated with the following Ethernet services:
IES SAP IES Spoke SDP VPRN SAP Epipe SAP VPLS SAP Ethernet Spoke SDP binding Epipe Ethernet Spoke SDP binding VPLS Mesh SDP binding VPLS
MEPs reside at the edge of the maintenance domain and perform the following:
Periodically sends continuity check messages Validates CFM PDU replies Discards CFM PDU messages that are not within the MEP
configuration Transmits loopback messages and receives loopback replies Transmits link trace messages and receives link trace replies
Figure 82: Up/Down MEP
Maintenance intermediate points (MIPs) are internal points within the domain and perform the following:
Validates received CFM PDUs Validates received LTMs (Link Trace Message) and responds to LTMs Validates received LBMs (Loopback Message)and responds to LBR
(Loopback Reply) Do not originate CFM Messages
MIP is defined as unidirectional behavior so they split up into two unidirectional pieces: MHF – MIP Half function
Figure 83: MIPs
The figure below shows an example of MEPs, MIPs and MDs in a CFM 802.1agenabled network. The example shows 4 MDs. MD 5 is provisioned for the customer, MD 3 is provisioned for the service provider, MD 2 is provisioned for the operator and MD 0 is provisioned for the physical level.
MD 5 has access to 2 down MEPs on each CE device and 2 MIPs on each provider bridge. MD 3 has access to an up MEP and a MIP on each providerbridge. Each MIP has 2 MIP half-function objects. MIP half-function objects allow MIPs to be recognized a MIPs on one MD level and MEPs on ahigher level when the MHF Creation parameter is set to explicit.
Example 802.1ag
The fist step would be to set up the Maintenance Domains within the managed network. Using the reference architecture the following MDs willbe created:
Figure 84: 802.1ag Test Set Up
The MDs are created on the SAM under Policies>Ethernet CFM>Maintenance Domain
The operator can choose the Name Type from:
dns string mac none
In the example below, we have chosen the ‘string’ option and named the MD “Service_Provider_MD” and assigned it to level 3. There is no requirement to deploy the MDs to the network elements; this is done automatically when they are assigned to a MA when creating a CFM test.
Figure 85: MD Creation
All the MDs are created for the test set-up. The SAM has automatically allocated the MD IDs for each domain.
Figure 86: MD List
A VPLS test service is created with SAP endpoints on 200.0.0.59 and 200.0.0.81, with intermediate nodes 200.0.0.60 and 200.0.0.80
CFM Continuity Check (CC)
To run a CFM CC test on the Epipe, the user selects from the Service Test Manager Create CFM Continuity Check, or from within the service form context.
Figure 87: CFM CCThe initial CC form allows the user to name the test and to select the MD over which the test should be run. In the example below the ‘Service_Provider_MD’ has been selected. The user also now has to input the Maintenance Association (MA), choosing from one of the following formats:
ICC Based Integer String VID VPN ID
The test duration can also be set, by default it will run for 60 seconds.
Figure 88: CFM CC Form 1
The next stage is to assign a service to the test and to select where the MEPs will be placed. The SAM will automatically assign these once the test has been saved. (If created test created from within the service form context the Access Interface MEPs will be assigned ‘Down’ direction automatically).
Figure 89: CFM CC Service Assign
As the test is saved, the MEPs are automatically created on the SAPs; the MEPs appear under the Local MEPs tab on the CFM Continuity Test form
The four MAs are also created automatically, two on the endpoint nodes and two on the transit nodes
Figure 90: MAs
T
Figure 91: Local MEP
As the test is saved the details are now sent to the network elements The ‘bridge-identifier’ in this instance is the VPLS service ID.
Figure 92: CFM CLI Info (1)
Figure 93: CFM CLI Service Info
By default the Local MEP do not have CC messages set, so would only respond to messages rather than originate and respond. At least one MEP
within the test must have CC enabled. Also the MEPs are configured in the ‘admin down’ state, so all should be set to ‘admin up’.
Figure 94: SAM CC MEP Form
Before any test is run, the Highest Defect is flagged as ‘none’.
Figure 95: CFM CLI MEP infoAs the test is executed (by default set to run for 1 minute), the CFM correctly finds the MEPs at either end of the service, known as Remote MEPs.
CC is enabled on the SAPs
On inspection, after the test, the MEPs show no defects
Once the test is completed, the field “High-priority Defect” will show something other than “No Defect” if a problem is found.
There are 5 different defect types:
bDefRDICCM – A remote MEP has reported the RDI bit in its last CCM
bDefMACstatus – Either some remote MEP is reporting its interface status as not isUP (interface state), or all remote MEPs are reporting a port status that contains some value other than psUP (port state)
bDefRemoteCCM – The MEP is not receiving valid CCMs from at least one of the remote MEPs
bDefErrorCCM – The MEP has received at least one invalid CCM whoseCCM interval has not yet timed out
bDefXconCCM – The MEP has received at least one CCM from either another MAID
or a lower MD level whose CCM interval has not yet timed out
If any error is found during the test, the alarm is raised within the 5620 SAM Alarm manager window.
As an example if we set the admin state of the SAP on 200.0.0.81 node to‘down’ and run the test again, we can see that the MEP now has an error code:
Decoding the message CC message we can see that no CC message was returned from the port the SAP was applied to for remote MEP 1.
Figure 96: CFM CC Error Decode
ANCP Loopback
The ANCP loopback test, which is called OAM ANCP in the CLI, is used to send DSL OAM commands to complete an OAM test 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 displayingboth successful and failed results.
ICMP ping
The ICMP ping OAM tool, which is called icmp-ping in CLI, identifies thereachability of a remote host across the IP network. The tool is used with ICMP trace to detect and localize faults in IP networks. Under CLI it is initiated under the SAA function.
The ICMP ping OAM tool can also be enabled from the VRF site of the subscriber’s 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 trace
The ICMP trace OAM tool, which is called icmp-trace in CLI, identifies the diagnostic used to trace the ICMP traceroute control table. The toolis 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.
DNS ping
The DNS ping OAM tool, which is called dns-ping in CLI, identifies the diagnostic used to ping the DNS name, if DNS name resolution is configured.
Multicast OAM
Multicast FIB ping
The multicast FIB ping OAM tool, which is called mfib-ping in CLI, identifies the SAPs that egress an IP multicast stream within a VPLS. This diagnostic can also be used to display the SAPs that are operationally up in the VPLS service.
Multicast router information
The multicast router information OAM tool, which is called mrinfo in CLI, identifies VPRN multicast information for the target router. The information includes details related to adjacent routers, supported protocols, traffic metrics, and time-to-live thresholds. Administrators can use this information to identify bidirectional adjacency relationships.
Multicast trace
The multicast trace OAM tool, 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 5620 SAM 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.
ATM OAM ping
The ATM OAM ping tool, which is called atmoam-ping in CLI, performs an ATM ping on an existing ATM PVC from the PVC endpoint using ATM OAM loopback cells. An ATM ping tests VC integrity and endpoint connectivityfor PVCs using OAM loopback capabilities.
Subscriber host connectivity verification
Aside from relatively infrequent IP-address lease renewal, DHCP has no session-monitoring or connection-monitoring capability. Residential subscriber management in the 5620 SAM provides this functionality for DHCP hosts and static hosts in the form of subscriber host connectivity verification, or SHCV. When SHCV is enabled on a SAP, an NE issues a periodic ARP request to each host on the SAP. If the NE receives no reply to an ARP request within the specified time period, the NE raises an event. When SHCV is configured to drop a lost host, the NE immediately removes the host from its active subscriber host table.
SHCV records the state information that it collects for hosts on a SAP and maintains a history of connectivity-related events for troubleshooting purposes.
SHCV operates in conjunction with DHCP snooping and is configurable on VPLS, VPRN, and IES SAPs, and on IES group interfaces. Because it uses ARP, SHCV automatically populates the FIBs of bridging devices in the access and provider networks. The configurable items for SHCV on a SAP include:
• the frequency of connectivity checks• the source of the ARP request• the action to perform when a host loses connectivity
Service assurance system overview
The 5620 SAM service assurance system (SAS) provides the ability to group various OAM tests into test suites for network troubleshooting andto verify compliance with SLAs. You can schedule the periodic execution of a test suite to provide continual performance feedback, or run a testsuite on demand to investigate service issues. The 5620 SAM archives test-result data for monitoring and trend analysis purposes. The grouping of tests into a test suite allows a 5620 SAM operator to use one schedule for the periodic execution of multiple OAM diagnostics against multiple network objects; for example, services, devices, or
network transport components. An operator can choose to include existingtests, use the 5620 SAM to generate the tests that comprise a test suite, or both. Groups of tests in a suite can be configured to execute sequentially or concurrently.
Test Policies
To enable the automatic generation of tests for a test suite, the 5620 SAM requires a test policy that contains a set of test definitions and pre- and post-processing rules. A test policy also specifies the order of execution for the generated tests. A test policy applies to only one test suite, and a test suite has only one test policy associated with it. A test policy is specific to one type of entity; for example, a VLL service or service tunnel. The test definitions in the policy are restricted to the tests that apply to the entity type specified in the policy. A test policy is applied to a test suite during test suite creation. The figure below shows the test policy creation form.
Test Suites
A test suite contains three test groups:
First-run tests Generated tests
Last-run tests
First-run tests are the tests in a suite that the 5620 SAM executes before the tests in the other groups. First-run tests are chosen from a list of existing tests and might typically include high-level diagnostics; for example, a service site ping or VPRN ping. No restrictions apply to the types of tests that are selectable as first-run tests.
Generated tests are created by the 5620 SAM for use against a particularnetwork entity, based on the type of entity specified in the suite and the information in the associated test policy. For example, a policy that specifies a service site ping as a test definition is associated with a test suite for a VPRN service that has three sites. The 5620 SAM thus generates six tests: one site ping test from each site in the VPRN to the other sites. When you change the configuration of a network entity, such as a service, you must regenerate the existing generated tests that apply to the entity.
Last-run tests are the tests in a suite that the 5620 SAM executes afterthe tests in the other groups. Last-run tests are chosen from a list of existing tests and might typically include transport-layer diagnostics; for example, an LSP trace or a tunnel ping. No restrictions apply to thetypes of tests that are selectable as last-run tests.
The use of test suites offers a high degree of configuration flexibility. The inclusion of tests in any group of a test suite is optional. When you specify that no network entity is associated with a test suite, the test suite is limited to the first-run and last-run testgroups. In this way, you can create a group of disparate tests to which no test policy restrictions apply.
To manage the system resources that test execution consumes, the 5620 SAM assigns a weight value to a test . When the 5620 SAM executes a test, it attempts to reserve the test weight from a resource pool, performs the test, then returns the test weight to the pool. The weight of a test suite is the sum of the weights of the individual tests in thesuite. The 5620 SAM attempts to reserve the weight of the whole suite for the duration of suite execution. If the required weight for a test or test suite is unavailable, execution is halted and the Status value contained in the test result is set to Not Enough Resources.
Sample SAS Implementation
The figure below shows a sample SAS implementation that illustrates how you can use SAS suites to verify service operation and identify network problems.
In the sample network, scheduled SAS test suites run continually to ensure that the transport elements, such as SDPs (service tunnels) and LSPs, are operating normally. Network staff quickly update the test suites to reflect network topology changes by adding or removing items from the list of tested entities in a suite and regenerating the tests. An OSS application collects the test result information and presents it for monitoring by NOC staff.
The SDP test suite contains the following generated tests for each SDP:
tunnel ping MTU ping
The LSP test suite contains the following generated test for each LSP path:
LSP ping (tested entity type is LSP path)
NOC monitoring staff become aware that tunnel ping operations fail occasionally on one SDP. Packet loss is not yet significant enough to affect SLAs, but threatens to become so, based on the observed trend. NOC staff run a test suite against the LSPs in the affected LSP path. The test suite contains the following generated test for each LSP in theLSP path:
LSP ping (tested entity type is LSP)
Test results show that the packet loss is related to a particular LSP inthe path. Investigation of the LSP traffic pattern indicates that a recently provisioned subscriber service is causing the LSP to be oversubscribed. The problem is addressed by a network designer and is corrected through later reconfiguration.
Sample SAS implementation configuration sequence
Task Description1. Scheduled SAS test-suite creation Create SAS test policies for transport-layer
elements.
Create a test policy for the SDPs. Specify Tunnel (SDP) as the Entity Type for the policy, and choose Tunnel Ping and MTU Pingas the test definitions. Create separate tunnel ping definitions for different forwarding classes, as required.
Create a test policy for the LSP paths. Specify LSP as the Entity Type for the policy and choose LSP Ping as the test definition. In the test definition, specifyLSP Path as the Target Type. Create separate LSP ping definitions for differentforwarding classes, as required.
Create SAS test suites for transport-layer elements.
Create a test suite for the SDPs. Specify Tunnel (SDP) as the Entity Type for the suite, choose the SDP test policy, choose the SDPs against which the suite is to run,and use the 5620 SAM to generate the tests in the suite. Create a schedule for the test suite according to network monitoring requirements, apply the schedule to the test suite, and enable the scheduled task.
Create a test suite for the LSP paths. Specify LSP as the Entity Type for the suite, choose the LSP test policy, choose the LSP paths against which the suite is torun, and use the 5620 SAM to generate the tests in the suite. Create a schedule for the test suite according to network monitoring requirements, apply the schedule
to the test suite, and enable the scheduledtask.
2. Data presentation Customize the tabular display of test results in
the 5620 SAM, or create an OSS application that retrieves test-result data from the 5620 SAM and presents it as information in graphical format for NOC stafff.
3. Creation of non-scheduled SAS test suite or individual OAM tests for network troubleshooting
Create an SAS test policy for the LSPs for use during network troubleshooting.
Create a test policy for the LSPs. Specify LSP as the Entity Type for the policy and choose LSP Ping as the test definition. In the test definition, specify LSP as the Target Type. Create separate LSP ping definitions for different forwarding classes, as required.
Create a non-scheduled SAS test suite (or individual OAM tests, depending on the number of LSPs involved) for the LSPs in the LSP path.
Specify LSP as the Entity Type for the suite, choose the newly created LSP test policy, choose the LSPs in the LSP path against which the suite is to run, and use the 5620 SAM to generate the tests for the suite.
4. Network monitoring
Use the 5620 SAM to display the scheduled test results in tabular format, or use an OSS application to monitor the LSP ping, tunnel ping,and MTU ping diagnostic results in real time. Note inconsistencies and trends, and troubleshootthe network as required.
5. Network troubleshooting When potential trouble arises, use a non-
scheduled SAS test suite or individual SAS tests to help identify the cause.
Create individual tests or edit the existing non-scheduled test suite. Include as tested entities the LSPs that comprise the LSP path and regenerate the tests for the suite, as required.
Execute the non-scheduled test suite and monitor the test results.
Edit the test definition in the test policy. Change test parameter values as required, regenerate the tests in the suite, and re-execute the suite. Continue to refine the diagnostic test results untilthe problem manifests itself in the test results.
Test Suite Policy for VLL
Test Suite Policy for VPLS
Test Suite Policy for VPRN
Test Suite Policy for MPLS Service Transport