Table Of Contents
Q & A
MPLS Ping and Traceroute
Cisco MPLS VCCV
Cisco MPLS Traffic Engineering AutoTunnel Primary and Backup Mesh Groups
Cisco MPLS Traffic Engineering AutoTunnel Primary
Cisco MPLS Traffic Engineering AutoTunnel Backup
Cisco IOS SAA
MPLS-Aware NetFlow
Q & A
Cisco IOS MPLS Embedded Management
Q. 
What is Cisco IOS® MPLS Embedded Management?
A. Cisco® IOS MPLS Embedded Management is a set of standards and value-added services that facilitate the deployment, operation, administration, and management of Multiprotocol Label Switching (MPLS)-based networks in line with the fault, configuration, accounting, performance, and security (FCAPS) model.
Cisco IOS MPLS Embedded Management is enabled by combining Cisco MPLS Ping and Traceroute, Cisco Virtual Circuit Connectivity Verification (VCCV), Cisco MPLS Traffic Engineering AutoTunnel and AutoMesh, and Cisco Auto Service Assurance Agent (SAA). Refer to Table 1.
Table 1 Cisco IOS MPLS Embedded Management Components and FCAPS
Fault Management
|
•Cisco MPLS Ping and Traceroute
•Cisco VCCV
•MIBs
•Cisco SAA
|
|
|
|
Configuration
|
•Cisco MPLS Traffic Engineering AutoTunnel
•Cisco AutoTunnel mesh groups
•Cisco SAA
|
Accounting
|
•NetFlow
•MIBs
|
Performance
|
•Cisco SAA
•NetFlow
•MIBs
|
|
|
Security
|
•Resource Reservation Protocol (RSVP) message authentication
•Label Distribution Protocol (LDP) message authentication
•Message Digest Algorithm 5 (MD5) authentication for routing protocols:
–Border Gateway Protocol (BGP)
–Open Shortest Path First (OSPF)
|
|
|
|
|
Q. Why is Cisco IOS MPLS Embedded Management important to the service provider?
A. As carriers and service providers worldwide converge services and disparate networks onto an MPLS-based infrastructure, MPLS operations, administration, and maintenance (OA&M) becomes pivotal for enabling them to provide service-level agreement (SLA) guarantees, service assurance, quality of service (QoS) assurance, and overall internetworking service management. Network operators need the ability to reliably conduct SLA testing, detect MPLS control- and user-plane defects, and check MPLS forwarding path integrity in a real-time environment. A service provider that is planning to offer managed services on an MPLS-based infrastructure must carefully consider MPLS OAM to support premium SLAs.
The functions offered by these Cisco Systems® technologies are unique in the industry, and they allow service providers to easily deploy, operate, and monitor MPLS-enhanced services.
MPLS Ping and Traceroute
Q. Which MPLS ping and traceroute draft does Cisco support? Does Cisco support draft-ietf-mpls-lsp-ping-04?
A. Cisco implementation is based on draft 03 of MPLS ping and traceroute.
When working on implementing the function, Cisco provided some enhancements and subsequent comments related to draft 03. These changes are integrated in draft 04.
Q. Which IOS version provide support for MPLS ping and MPLS traceroute?
A. MPLS ping and traceroute are supported as of Cisco IOS Software Release 12.0(27)S on the Cisco 7200 Series, the Cisco 7500 Series, and the Cisco 12000 Series routers. Support for other platforms such as the Cisco 7600 Series will be available with Cisco IOS Software Release 12.2(RLS6)S.
Q. How do MPLS ping and MPLS traceroute work?
A. MPLS ping operation is based on the echo request and echo reply (similar to Internet Control Message Protocol [ICMP] ping).
An MPLS echo reply is sent in reply to an MPLS echo request. The MPLS echo request and replies are all User Datagram Protocol (UDP) packets. The packets are forwarded by MPLS within the MPLS network.
The mechanism allows the use of a different return path, which can be specified by the node that sends the echo request packet. The echo reply can be forwarded as an IP packet or MPLS packet to the Label Switch Router (LSR) that originates the MPLS echo request.
An MPLS echo request is a UDP packet that is sent to a target router using the appropriate label stack that is associated with the LSP to be tested. The destination address of the MPLS echo request UDP packet is different from the address used to select the label stack. It is not used for forwarding. Instead, the IP destination address is defined as a 127/8 address and used to:
•Force the packet to be consumed by the router where an LSP breakage occurs
•Force processing of the packet at the terminal point of the LSP if the LSP is intact
•Influence load balancing during forwarding when the transit routers use the destination address in the IP header for load balancing
LSP ping and LSP traceroute provide diagnostics and troubleshooting capability for MPLS LSPs. These tools provide basic building blocks for the MPLS OAM capabilities, enabling verification of the MPLS data-plane consistency.
LSP ping is a data-plane verification tool that verifies the LSP connectivity and the integrity of the MPLS network. Ping mode can test the integrity of connectivity using the verification on the Forward Equivalence Class (FEC) entity between the ping origin and the egress node for this FEC. This test is carried out by sending an MPLS echo request along the same data path as other packets belonging to this FEC. When the ping packet reaches the end of the path, it is sent to the control plane of the egress LSR, which then verifies that it is indeed an egress for the FEC. The MPLS echo request contains information about the FEC whose MPLS path is being verified.
Currently, the following FECs are supported (in the MPLS ping and traceroute draft): LDP IPv4 prefix, LDP IPv6 prefix, RSVP IPv4 Session Query, RSVP IPv6 Session Query, VPN IPv4 prefix, and VPN IPv6 prefix.
LSP traceroute is a data-plane verification tool that traces LSP paths in the MPLS networks. In the traceroute LSP verification, the packet is sent to the control plane of each transit LSR, which performs various checks, including one that determines if it is a transit LSR for this path. Furthermore, each transit LSR also returns extra information related to the FEC being tested (that is, the label bound to the FEC). This information helps in checking the control plane against the data plane (for example, in checking to see if the local forwarding information matches what the routing protocols determined as the path). Traceroute operation is performed by manipulating the time to live (TTL).
Q. What reply modes does Cisco support?
A. The MPLS ping and traceroute draft allows provision for the following reply modes:
•Do not reply
•Reply via IPv4 UDP packet
•Reply via IPv4 UDP packet with router alert
•Reply via control plane (only RSVP)
The do not reply mode is useful for the keepalive type of application running at the remote end, which triggers a state change if it does not receive a LSP ping packet within a predefined time.
Reply via UDP packet implies that an IPv4 UDP packet should be sent in reply to an MPLS echo request.
Reply via IPv4 UDP packet with router alert forces the packet to traverse back to the destination to be processed by the router processor (RP) at each intermediate hop.
Reply via control plane is specific to RSVP and requires extension to RSVP signaling.
Cisco supports the following reply modes:
•Do not reply is supported but will not be used.
•Reply via IPv4 UDP packet is supported.
•Reply via IPv4 UDP packet with router alert is supported.
•Reply via control plane is supported (RSVP traffic engineering).
Q. What return codes do the Cisco router generate? Is it possible to localize the errors?
A. Possible return codes, given as follows, indicate the possible errors (for example, FEC mismatch...):
Value
|
Meaning
|
0
|
The error code is contained in the error code TLV (Type Length Value)
|
1
|
A malformed echo request has been received
|
2
|
One or more of the TLVs was not understood
|
3
|
replying router is an egress node for the FEC
|
4
|
The replying router has no mapping for the FEC
|
5
|
The replying router is not one of the downstream routers
|
6
|
The replying router is one of the downstream routers, and its mapping for this FEC on the received interface is the given label
|
7
|
The replying router is one of the downstream routers, but its mapping for this FEC is not the given label
|
Error code TLVs are not defined yet, so a value of 0 is expected but not implied because it is conceivable that a transit router or destination router might be running a later implementation of the draft.
The originating router just reports that it received an error code TLV that is not understood.
Q. What target FEC stacks does Cisco support?
A. As of Cisco IOS Software Release 12.0(27)S, the following FECs are supported:
•LDP IPv4 prefix (echo request, echo reply, and traceroute)
•RSVP IPv4 Session Query (echo request, echo reply, and traceroute)
•VCCV Circuit ID (used by Any Transport over MPLS [AtoM] VCCV) (echo request and echo reply)
Support for VPN IPv4 prefix (echo request, echo reply, and traceroute) will be available soon.
Support for other FEC stacks (LDP IPv6, etc.) is under study.
Q. Is there any limitation regarding label stack depth?
A. MPLS ping and MPLS traceroute do not introduce any extra MPLS label; they just use the MPLS forwarding infrastructure to convey the packet to the engress LSR. (Refer to the question "How do MPLS ping and MPLS traceroute work?")
Q. Is downstream mapping supported? Are there limitations?
A. Downstream mapping TLV is used during MPLS traceroute to keep track of the label used going from the headend to the tail end. It allows also to detect alternative paths.
Cisco MPLS VCCV
Q. What is Cisco MPLS VCCV?
A. Cisco MPLS VCCV enhances the monitoring and troubleshooting of Layer 2 services across an MPLS network. Figure 1 shows the preseudowire infrastructure.
Figure 1
Pseudowire Infrastructure
Q. Is Cisco MPLS VCCV available?
A. Cisco MPLS VCCV is available as of Cisco IOS Software Release 12.0(27)S.
Q. How does Cisco MPLS VCCV work?
A. Cisco MPLS VCCV creates a control channel between the two termination-point pseudowire provider edges (PE) to uniquely identify the connectivity verification packets from the regular Layer 2 payloads.
Ideally such a control channel would be completely in band.
When a (Martini) control word is present on a virtual circuit, it is possible to indicate the control channel by setting a bit in the control header.
However, to ensure a smooth interoperability between the different devices participating in the pseudowire service, a MPLS router alert label is used to indicate the control channel.
Q. Is it mandatory to support both in-band and router alert control channels?
A. To accommodate the huge number of already deployed devices, both options are available. When Cisco MPLS VCCV is used (between two provider edges), the first step is to agree on capability (in-band or router alert). Afterward, any connectivity verification packets use the agreed-on mode.
Note: Control word is the preferred mode because it does not require processing of the packet up to the Router Processor (RP) whenever connectivity verification is used. The use of the router alert option implies that each packet is processed by the RP.
Q. Does Cisco support the in-band or the router alert mode?
A. Cisco supports both modes, but depending on hardware, both modes might not be available.
On the Cisco 12000 Series:
•Control word option: The E3 line card is the imposition card.
•Router alert option: All other line cards and when egress not Engine 3 line card.
•On the Cisco 7200 Series and the Cisco 7500 Series, control word is the preferred mode.
Cisco MPLS Traffic Engineering AutoTunnel Primary and Backup Mesh Groups
Q. What are Cisco MPLS Traffic Engineering AutoTunnel Primary and Backup?
A. Cisco MPLS Traffic Engineering AutoTunnel provides the ability to set up traffic engineering tunnels automatically. There are two variants of autotunnels for protection capabilities—primary and backup. Cisco MPLS Traffic Engineering AutoTunnel automates the configuration tasks in the deployment of Cisco MPLS Traffic Engineering Fast Reroute (FRR).
Q. Are Cisco MPLS Traffic Engineering AutoTunnel primary and backup mesh groups available?
A. Yes, as of Cisco IOS Software Release 12.0.(27)S.
Cisco MPLS Traffic Engineering AutoTunnel Primary
Cisco MPLS Traffic Engineering AutoTunnel Primary is a one-hop primary tunnel which, when used in conjunction with Cisco MPLS Traffic Engineering FRR protection, protects any traffic steered through the primary "one-hop tunnel." (Basically, any traffic, including IP traffic going through the physical link, is protected by Cisco MPLS Traffic Engineering FRR).
Cisco MPLS Traffic Engineering AutoTunnel Backup
Cisco MPLS Traffic Engineering AutoTunnel Backup provides the capability to automatically build MPLS traffic engineering backup tunnels for the primary traffic engineering tunnel. These backup tunnels are set up mainly using next hop or next next hop protection, whenever available. A manually configured backup tunnel is preferred and thus provides "tweaking capabilities" for autotunnel features.
Q. How do I enable Cisco MPLS Traffic Engineering AutoTunnel Primary?
A. You can enable Cisco MPLS Traffic Engineering on any interface where you would like to have MPLS traffic engineering. The command follows: mpls traffic-eng tunnel.
To globally enable Cisco MPLS Traffic Engineering AutoTunnel, use the following command: mpls traffic-eng auto-tunnel primary onehop.
Q. How do I enable a backup tunnel for the primary autotunnel?
A. The one-hop traffic engineering tunnel can use either any manually configured backup tunnel(s) or backup tunnel(s) automatically created with the command mpls traffic-eng auto-tunnel backup.
A manually configured backup tunnel is preferred because it provides tweaking capabilities for autotunnel features.
Q. What is the result of the command mpls traffic-eng auto-tunnel backup?
A. This command automatically sets up a backup tunnel for the MPLS traffic engineering one-hop autotunnel. These backup tunnels are set up mainly using next hop or next next hop protection, whenever available as shown on Figure 2.
Figure 2
Cisco MPLS AutoTunnel Primary; Cisco MPLS AutoTunnel Backup
Q. What is the Cisco MPLS Traffic Engineering AutoTunnel Mesh Group?
A. The Cisco MPLS Traffic Engineering AutoTunnel Mesh Group increases the amount of bandwidth available over the same MPLS infrastructure and automates the configuration tasks in deployment of full-mesh MPLS traffic engineering tunnels. A full mesh of similar (sharing same attributes) MPLS traffic engineering tunnels is automatically built between the router members of a specific mesh group.
Such a tool is needed typically when a) transitioning an MPLS network to a fully meshed MPLS traffic engineering (requires heavy configuration) group, or b) adding a new router in a fully meshed MPLS traffic engineering core where traffic engineering tunnels to and from that router to all existing are needed.
Q. How do I enable a Cisco MPLS Traffic Engineering AutoTunnel Mesh Group?
A. All the routers within the same mesh group (for example, voice mesh group or data mesh group) can share the same MPLS traffic engineering characteristics. MPLS traffic engineering characteristics are defined with the use of Auto-Template. The set of router members of a given mesh group is defined with the use of a standard IP ACCESS-LIST, which lists the IP addresses of those routers.
The following are the steps to enable the Cisco MPLS Traffic Engineering AutoTunnel Mesh Group:
•Enable traffic engineering on all routers (members of the mesh group).
•Enable Cisco AutoTunnel mesh groups (global level):
router(config)# mpls traffic-eng auto-tunnel mesh.
•Configure ACCESS-LIST (standard IP access list), which defines the set of possible tunnel destinations.
•Configure Auto-Template:
router(config)#interface Auto-Template 1
router(config-if)#ip unnumbered Loopback0
router(config-if)#tunnel mode mpls traffic-eng
router(config-if)#tunnel mpls traffic-eng autoroute announce
router(config-if)#tunnel mpls traffic-eng priority 1 1
router(config-if)#tunnel mpls traffic-eng auto-bandwidth
router(config-if)#tunnel mpls traffic-eng path-option 1 dynamic
router(config-if)#tunnel destination access-list 1
•Traffic engineering LSP is automatically set up using the locally configured templates.
Cisco IOS SAA
Q. What is Cisco IOS SAA?
A. Embedded within Cisco IOS Software, Cisco IOS SAA provides a scalable, cost-effective solution for performance measurement. Cisco IOS SAA active monitoring can continuously measure the network performance, providing an ongoing baseline to indicate how the network is performing. Cisco IOS SAA collects network performance information in real time: response time, one-way latency, one-way jitter, one-way packet loss, voice quality measurement, as well as other network statistics. Cisco IOS SAA provides unidirectional and bidirectional measurements and supports measurements per class of service. Also available are proactive notification and threshold violation monitoring for jitter, packet loss, latency, and connectivity. All SAA performance statistics are available in the Simple Network Management Protocol (SNMP) MIBs.
Q. Are Cisco IOS SAA measurements Virtual Route Forwarding (VRF)-aware?
A. Yes, Cisco SAA measurements can be sent to a destination that is found in a VRF routing table. This capability is useful for provider edge or point of presence (POP)-to-customer edge measurements and provider edge-to-remote customer edge measurements within a Layer 3 MPLS VPN. VRF-aware Cisco SAA is also used on routers that use Multi-VRF customer edge capability from Cisco.
Q. Does Cisco IOS SAA support LSP ping?
A. A new feature from Cisco called Auto SAA for Layer 3 MPLS VPN supports LSP and traceroute ping as a mechanism for MPLS network connectivity and performance measurements.
Q. What is Cisco Auto SAA for Layer 3 VPN?
A. Cisco SAA is widely used when network performance measurement and SLA monitoring data such as jitter statistics, packet loss, and round-trip time (RTT) are required within an IP-based network. In addition, Cisco SAA provides unique tools that allow monitoring of MPLS Layer 3-based VPNs. However, deploying such a probe is not always straightforward because it requires provisioning on the pair of provider edge devices to be monitored. Cisco Auto SAA enhances the already feature-rich SAA capabilities by simplifying the deployment and configuration of the SAA probes whenever performance measurement and SLA monitoring for an MPLS Layer 3 VPN infrastructure are required. The extended features include automatic generation of probes to measure performance between MPLS provider edge routers, proactive monitoring of the MPLS network, and automatic optimization of probe scheduling, giving a better scan coverage time. The Cisco Auto SAA feature will be available later in 2004.
MPLS-Aware NetFlow
Q. What is NetFlow?
A. NetFlow capitalizes on the flow nature of traffic in the network to provide detailed IP accounting information with minimal impact on router and switch performance. NetFlow monitors IP flows in the router and switch and exports the flows in UDP format to a NetFlow collector. The NetFlow collector can correlate, aggregate, and report on the data received from the network. NetFlow data can be used for a variety of purposes, including network management and planning, enterprise accounting, departmental chargeback, usage-based billing, data warehousing and mining for marketing purposes, etc.
Q. What is NetFlow Version 9?
A. NetFlow Version 9 is a new flexible and extensible export format for NetFlow flow data. Historically NetFlow has utilized a fixed-field export format, but this format is not extensible. NetFlow Version 9 uses a template to describe the data in the export packet and allows flexibility in the content of flow export records. NetFlow Version 9 extends NetFlow to support MPLS label information, IPv6 information, BGP next hop, and multicast information. Version 9 has recently been proposed as an IETF standard.
Q. What is MPLS-aware NetFlow?
A. MPLS-aware NetFlow uses NetFlow Version 9 to export information needed for MPLS capacity planning and IP accounting. MPLS-aware NetFlow can be used to determine and account for traffic to a particular destination in the MPLS cloud. It allows the exports of the complete IP flow information, along with information pertaining to up to three labels (label destination prefix information including MPLS EXP). The user can account for MPLS traffic that contains IP or non-IP packets and can include the MPLS header as part of the accounting information. MPLS-aware NetFlow is available on the Cisco 12000 Series in Cisco IOS Software Release 12.0(24)S and other platforms in Cisco IOS Software Release 12.0(26)S.
Q. What is MPLS egress NetFlow?
A. MPLS egress NetFlow allows users to account for egress traffic exiting an MPLS network on a provider edge (PE) router (that is, from the provider edge (PE) toward a customer edge (CE) in a Layer 3 MPLS VPN). MPLS egress NetFlow can be combined with IP NetFlow used for Layer 3 MPLS VPN accounting.
For more information, refer to the following:
Cisco IOS MPLS:
http://www.cisco.com/go/mpls
Cisco IOS Software Release 12.0S documentation:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/index.html
Advanced performance measurement with Cisco SAA:
http://www.cisco.com/go/saa
VCCV draft, IETF Webpage:
http://www.ietf.org
MPLS ping and MPLS traceroute draft "Detecting Data Plane Liveliness," IETF Webpage:
http://www.ietf.org
Cisco IOS NetFlow:
http://www.cisco.com/application/vnd.ms-powerpoint/en/us/guest/tech/tk362/c1482/ccmigration_09186a0080182b50.ppt
http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00801b3a38.html
Advanced topics in MPLS traffic engineering deployment:
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_white_paper09186a00800a4472.shtml
