MPLS - Troubleshooting Guide

TM
Advanced Services
Advanced Service
MPLS - Troubleshooting Guide Version 1.0
Corporate Headquarters Cisco 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
Contents
Contents ..........................................................................................................................................2 Figures ............................................................................................................................................5 Introduction ....................................................................................................................................6 Document Purpose ...................................................................................................................6 Motivation ..................................................................................................................................6 Intended Audience ....................................................................................................................6 Organisation ..............................................................................................................................6 Part 1: Technology Description ....................................................................................................7 MPLS and MPLS/VPN Introduction ..............................................................................................8 MPLS Features ..........................................................................................................................8 MPLS Architecture ....................................................................................................................8 What Are MPLS Labels? ........................................................................................................ 10 What Are MPLS VPNs? .......................................................................................................... 11 MP-BGP ................................................................................................................................... 12 What Is The MPLS VPN Architecture? ................................................................................. 13 How Is The Routing Between CE-PE and PE-PE? .............................................................. 14 What Is Multi-VRF CE (VRF-Lite)? ........................................................................................ 16 What Are the Effects of MPLS VPNs on Packet Forwarding? ........................................... 16 MTU issues ............................................................................................................................. 16 MPLS Traffic Engineering Introduction .................................................................................... 17 What is MPLS TE? ................................................................................................................. 17 Why use MPLS TE? ............................................................................................................... 17 CBR (Constraint-Based Routing) ......................................................................................... 18 Traditional RSVP .................................................................................................................... 19 RSVP-TE.................................................................................................................................. 20 Fast Reroute (FRR) ................................................................................................................ 20 Auto Tunnel Mesh and Backup ............................................................................................ 22 AToM Introduction ...................................................................................................................... 23 Why implement AToM? ......................................................................................................... 23 Transport Types ..................................................................................................................... 23 How AToM works? ................................................................................................................. 24
July 10
A printed copy of this document is considered uncontrolled.
Advanced Service
Part 2: Troubleshooting Methodology ...................................................................................... 26 Essential MPLS/VPN configs ..................................................................................................... 27 Essential TE configs .............................................................................................................. 28 Essential AToM configs ........................................................................................................ 29 Part 3: Some MPLS Commands................................................................................................. 30 A Simplistic Topology to be used as an example for the Troubleshooting .................... 39 Part 4: List of Show Commands ................................................................................................ 40 Troubleshooting Summary ........................................................................................................ 41 MPLS and MPLS/VPN Troubleshooting ............................................................................... 41 MPLS/TE and FRR Troubleshooting .................................................................................... 43 AToM Troubleshooting .......................................................................................................... 45 Troubleshooting commands ...................................................................................................... 46 MPLS and MPLS/VPN ............................................................................................................ 46 MPLS/TE and FRR .................................................................................................................. 64 AToM ....................................................................................................................................... 88 Tracing a LSP end to end ...................................................................................................... 89 Part 5: Failure Scenarios ............................................................................................................ 94 Troubleshooting Scenarios........................................................................................................ 95 Mis-configuration ................................................................................................................... 95 Some MPLS and MPLS/VPN issues ................................................................................... 109 PE Node Failure.................................................................................................................... 114 PE-CE Link Failure ............................................................................................................... 115 RR Node Failure ................................................................................................................... 116 Link Failure ........................................................................................................................... 117 P Node Failure ...................................................................................................................... 130 AToM issues ......................................................................................................................... 139 Conclusion ................................................................................................................................. 141 Part 6: Appendix ........................................................................................................................ 143 Appendix I .................................................................................................................................. 144 Troubleshooting GSR forwarding ...................................................................................... 144 Debug commands of interest for Control Plane ............................................................... 146 Debug commands of interest for Data Plane .................................................................... 155 Debug commands of interest for MPLS and MPLS/VPN ................................................. 155
July 10
Advanced Service
Debug commands of interest for AToM ............................................................................ 155 How to measure packet loss............................................................................................... 156 Useful MIBs and how to poll them ..................................................................................... 159 Appendix II ................................................................................................................................. 162 Configuration used in lab .................................................................................................... 162 Glossary ..................................................................................................................................... 171 References ................................................................................................................................. 173 About This MPLS - Troubleshooting Guide ........................................................................... 175 History ................................................................................................................................... 175 Review ................................................................................................................................... 175
July 10
Advanced Service
Figures
Figure 1 Information Base Figure 2 - Interactions between MPLS applications Figure 3 Routing look up using CEF and BGP prefixes Figure 4 - Non BGP Route Propagation - Outbound Figure 5 - Non BGP Route Propagation - Inbound Figure 6 - Primary Tunnel Path Figure 7 - Backup Tunnel - Node Protection Figure 8 - Backup Tunnel - Link Protection Figure 9 - AToM - Label exchanging Figure 10 - AToM - frame forwarding Figure 11 - Topology used in lab for capturing output Figure 12 - Lab topology for LINK and NODE failures scenarios
9 11 12 15 15 21 21 22 24 25 39 140
July 10
Advanced Service
Introduction
Document Purpose
This document serves as a generic troubleshooting resource for operational staff when diagnosing and identifying faults in the MPLS network, focusing the following technologies: MPLS label exchanging (via LDP). MPLS VPN (via MP-BGP). MPLS TE and FRR (via RSVP). AToM Any Transport over MPLS (via IGP and LDP).
This document will particularly focus on troubleshooting aspect of MPLS environment (LDP, VPN, TE and AToM) and will not describe specific MPLS implementation or design. A brief overview will be provided, however the reader is encouraged to read the reference material for a comprehensive overview.
Motivation
Troubleshooting can sometimes be perceived as a black art and thus Cisco Advanced Services is focused to provide with a clear outline for troubleshooting issues relating to some MPLS deployment including traffic Engineering. This document is primarily aimed to help Operational Support Staff, firstly to debug and diagnose issues, and also to collect necessary information that will be required in the event a Cisco TAC Service Request is opened.
Intended Audience
The intended audience for this document is: Operational stuff. Cisco Advanced Services Teams.
Organisation
Part 1: A brief summary of the MPLS Technology: MPLS, LDP, MP-BGP, RSVP and AToM Part 2: Troubleshooting Methodology: step-by-step checking list per technology Part 3: List of the MPLS commands used in the lab topology Part 4: List of the show commands to check the network status Part 5: Examples of some issue and how to identify them based on show commands Part 6: Appendixes
July 10
Advanced Service
TM
Part 1: Technology Description
MPLS and MPLS/VPN Introduction

Before basic MPLS functionality is explained, these three foundations of traditional IP routing need to be highlighted: Routing protocols are used on all devices to distribute routing information. Each router analyses the Layer 3 header of each packet compared to the local routing table and makes a decision about where to forward the packet. Regardless of the routing protocol, routers forward packets contingent on a destination address-based routing lookup. The routing lookup is performed independently on every router in the network.
MPLS Features
MPLS is a packet-forwarding technology that uses appended labels (tags) to make forwarding decisions for packets. Within the MPLS network, the Layer 3 header analysis is done just once (when the packet enters the MPLS domain). Labels are appended to the packet, and then the packet is forwarded into the MPLS domain. Simple label inspection integrated with CEF switching drives subsequent packet forwarding.
MPLS was designed to support efficiently forwarding packets across the network core based on a simplified header. Label switching is performed regardless of the Layer 3 routing protocol. MPLS decreases the forwarding overhead on the core routers. MPLS supports multiple useful applications such as those listed here: Unicast and Multicast IP routing. VPN (Virtual Private Network). TE (Traffic Engineering). QoS (Quality of Services). AToM (Any Transport Over MPLS).
MPLS supports the forwarding of non-IP protocols, because MPLS technologies are applicable to any network layer protocol.
MPLS Architecture
MPLS consists of these two major components: Control Plane. Data Plane.
July 10
Advanced Service
Control Plane
The control plane builds a routing table (RIB Routing Information Base) based on the routing protocol. The control plane uses a label exchange protocol to create and maintain labels internally, and to exchange these labels with other devices. The label exchange protocols include MPLS LDP or TDP, BGP (used by MPLS VPN) and RSVP (used by MPLS TE to accomplish label exchange). The control plane also builds two forwarding tables, a FIB from the information in the RIB, and a LFIB (Label Forwarding Information Base) table based on the label exchange protocol and the RIB. The LFIB table includes label values and associations with the outgoing interface for every network prefix.
Data Plane
Data Plane is a simple forwarding engine that is independent of the type of routing protocol or label exchange protocol being used. The data plane forwards packets to the appropriate interface based on the information in the LFIB or the FIB tables. Figure 1 Information Base
MPLS Terminology
LSR (Label Switch Router): A device that implements label distribution procedures and primarily forwards packets based on labels. Typically known as a P (Provider) router. Edge LSR: An LSR on the edge of an MPLS domain that implements label distribution procedures, forwards packets based on labels, and primarily inserts labels on packets or remove labels for non-MPLS devices. Typically known as a PE (Provider Edge) router.
July 10
Advanced Service
What Are MPLS Labels?

MPLS uses a 4-byte, fixed-length (32-bit) level field that contains the information that follows: 20-bit label. 3-bit experimental field (typically used to carry IP precedence value). 1-bit bottom-of-stack indicator (indicates whether this is the last label before the IP header). 8-bit TTL (equal to the TTL in the IP header).
An MPLS label is a locally significant identifier that is used by network core devices to make forwarding decisions for a packet. Labels define the destination and services for each packet, and identify a FEC (Forwarding Equivalence Class). The label put on a particular packet represents the FEC to which the packet is assigned. Each LSR in the network makes an independent, local decision regarding which value to use to represent an FEC. This mapping is known as a label binding. FEC is a group of packets forwarded: In the same manner. Over the same path. With the same forwarding treatment.
MPLS uses FEC-based forwarding to evolve connectionless IP networks to connection-oriented networks. MPLS technology is intended to be used anywhere regardless of Layer 1 media and Layer 2 encapsulation. Frame-mode MPLS is MPLS over a frame-based Layer 2 encapsulation: The label is inserted between the Layer 2 and Layer 3 headers. The fields in the ATM header are used as the label. Cell-mode MPLS is MPLS over ATM:
If ATM is being used as a WAN link and the ATM switches do not act as LSRs, this is a frame-mode MPLS.
What Are MPLS Label Operations?

An LSR can perform these functions: Insert (impose or push) a label or a stack of labels on ingress edge LSR. Swap a label with a next-hop label or a stack of labels in the core. Remove (pop) a label on egress edge LSR.
MPLS Applications
MPLS can be used in different applications, as outlined here:
July 10
Unicast IP routing is the most common application for MPLS. Multicast IP routing is treated separately because of different forwarding requirements. MPLS TE is an add-on to MPLS that provides better and more intelligent link use. Differentiated QoS can also be provided with MPLS. MPLS VPNs are implemented using labels to allow overlapping address space between VPNs. AToM is a solution for transporting Layer-2 packets over an IP or MPLS backbone.
Advanced Service
10
What Are MPLS VPNs?

MPLS enables highly scaleable VPN services to be supported. For each MPLS VPN user, the network appears to function as a private IP backbone over which the user can reach other sites within the VPN organisation, but not the sites of any other VPN organisation. MPLS VPNs are a common application for service providers. Building VPNs in Layer 3 allows delivery of targeted services to a group of users represented by a VPN. Customer networks are learned via an IGP (OSPF, BGP, RIPv2, static and recently ISIS and EIGRP) from a customer, or via BGP from other MPLS backbone routers (Inter AS- MPLS/VPNs). MPLS VPNs use two labels: The top label points to the egress router. The second label identifies the outgoing interface on the egress router or a routing table where a routing lookup is performed.
LDP is needed in the top label to link edge LSRs with a single label-switched Path (LSP) tunnel. MP-BGP (Multiprotocol BGP) is used in the second label to propagate VPN routing information and labels across the MPLS domain. LSPs are unidirectional: Return traffic uses a different LSP (usually the reverse path because most routing protocols provide symmetrical routing). An LSP can take a different path from the one chosen by an IP routing protocol (MPLS TE).
What Are The Interactions Between MPLS Application?

Figure 2 - Interactions between MPLS applications
The Figure 2 shows the overall architecture when multiple applications are used. Regardless of the application, the functionality is always split into the control plane and the data (forwarding) plane, as discussed here:
July 10
The applications may use a different routing protocol and a different label exchange protocol in the control plane. The applications all use a common label-switching data (forwarding) plane. Edge LSR Layer 3 data planes may differ to support label imposition and disposition. In general, a label is assigned to an FEC.
Advanced Service
11
MP-BGP
The BGP-4 is capable of carrying routing information only for IPv4. The Multiprotocol Extension BGP (MP-BGP) defines extensions to BGP to carry routing information for multiple Network Layer protocols (e.g. IPv6, IPX, CLNS, VPNv4, multicast, etc ). Multiprotocol Reachable NLRI (MP_REACH_NLRI) is a new non-transitive and optional BGP attribute that is used for the following purposes: To advertise a feasible route to a peer. To permit a router to advertise the Network Layer Address of the router that should be used as the next-hop to the destinations listed in the Network Layer Reachability Information field of the MP_NLRI attribute. To allow a given router to report some or all of the SNPAs (Subnetwork Points of Attachment) that exist within the local system.
The attribute contains one or more triples: Address Family Information. Next-hop Information. Network Layer Reachability Information.
The Address Family carries the identity of the Network Layer Protocol associated with the Network Address that follows. Figure 3 Routing look up using CEF and BGP prefixes
For BGP prefixes the routing look up occurs twice: First to identify BGP-next-hop. Second time to identify how to reach BGP-next-hop, usually is a remote PE. This IP prefix should be learnt via an internal gateway protocol such as IS-IS1.
It cant be learnt via BGP, otherwise you will have an unstable network with flapping prefixes on routing table.
Advanced Service
July 10
12
What Is The MPLS VPN Architecture?

The MPLS VPN architecture offers service providers a peer-to-peer VPN architecture that combines the best features of overlay VPNs (support for overlapping customer address spaces) with the best features of peer-to-peer VPNs. PE routers participate in customer routing, guaranteeing optimum routing between customer sites. PE routers carry a separate set of routes for each customer, resulting in perfect isolation between customers. Customers can use overlapping addresses.
The architecture of a PE router in an MPLS VPN is very similar to the architecture of a POP with customer-dedicated PE routers used in the dedicated-router peer-to-peer VPN model. The only difference is that the whole architecture is condensed into one physical device with the PE router in an MPLS VPN. Each customer is assigned an independent routing table (virtual routing table of VRF) that corresponds to customer dedicated PE router in the traditional peer-to-peer model. Routing across the provider backbone is performed by another routing process that uses a global IP routing table corresponding to the intra-POP P router in the traditional peer-to-peer model.
What Are Route Distinguishers (RD)?

The RD is used only to transform non-unique 32-bit customer IPv4 addresses into unique 96-bit VPNv4 addresses2. VPNv4 addresses are exchanged only between PE routers; they are never used between CE routers. Between PE routers, BGP must therefore support the exchange of traditional IPv4 prefixes and the exchange of VPNv4 prefixes. A BGP session between PE router is consequently called an MP-BGP session. The RD has no special meaning or role in MPLS VPN architecture; its only function is to make overlapping IPv4 addresses globally unique. The RD value has a local significance on the router where it is configured in order to distinguish a FIB table per VPN routing table (VRF table).
Is The RD Enough?
Simple VPN topologies require only one RD per customer, raising the possibility that the RD could serve as a VPN identifier. This design, however, would not allow implementation of more complex VPN topologies, such as when a customer site belongs to multiple VPNs, such as Management VPNs, Central Services VPNs, Hub&Spoken VPNs.
What Are Route-Targets (RTs)?

RTs were introduced into the MPLS VPN architecture to support identifying a site that participates in more than one VPN. RTs are attributes that are attached to a VPNv4 BGP route to indicate its VPN membership. The extended BGP communities of routing updates are used to carry the RT of the update, thus identifying to which VPN the update belongs. Extended BGP communities are 64-bit values. The semantics of the extended BGP community are encoded in the high-order 16bits of the value, making those bits useful for a number of different applications, such as MPLS VPN RTs.
In an IP version 6 implementation, the theory is the same.

Advanced Service
July 10
13
RTs: How Do They Work?

MPLS VPN RTs are attached to a customer route at the moment that it is converted from an IPv4 route to a VPNv4 route by the PE router. The RTs attached to the route are called export RTs and are configured separately for each virtual routing table in a PE router. Export RTs identify a set of VPNs in which sites associated with the virtual routing table belong. When the VPNv4 routes are propagated to other PE routers, those routers need to select the routes to import into their virtual routing tables. This selection is based on import RTs. Each virtual routing table in a PE router can have a number of configured import RTs that identify the set of VPNs from which the virtual routing table is accepting routes.
How Have Complex VPNs Redefined The Meaning of VPNs?

With the introduction of complex VPN topologies, the definition of a VPN has needed to be changed. A VPN is simply a collection of sites sharing common routing information. In traditional switched WAN terms (for example, in X.25 terminology), such a concept would be called a closed user group (CUG). In the classic VPN, all sites connected to a VPN shared a common routing view. In complex VPNs, however, a site can be part of more than one VPN. This results in differing routing requirements for sites that belong to a single VPN and those that belong to more than one VPN. These routing requirements have to be supported with multiple virtual routing tables on the PE routers. A Virtual routing table in a PE router can be used only for sites with identical connectivity requirements. Complex VPN topologies require more than one virtual routing table per VPN. As each virtual routing table requires a distinct RD value, the number of RDs in the MPLS VPN network increases.
How Is The Routing Between CE-PE and PE-PE?

Outbound Propagation
IGP speaking CE routers identify the correct instance of IGP on the PE router when an inbound PE interface is associated with a VRF. This association allows CE routers to announce their networks to the appropriate per-VRF routing table. MP-BGP is used in the MPLS VPN backbone to carry VPN routes (prefixed with the RD) as 96-bit VPNv4 routes between the PE routers. The backbone BGP process looks exactly like a standard iBGP setup from the perspective of the VRF. The per-VRF IGP routes therefore must be redistributed into the per-VRF instance of the BGP process to allow them to be propagated through the backbone MP-BGP process to other PE routers (see Figure 4).
Inbound Propagation
The MP-iBGP routers, although they are inserted in the per-VRF IP routing table, are NOT propagated to IGP speaking CE routers automatically. To propagate these MP-iBGP routes to the IGP speaking CE routers, you must manually configure the redistribution between per-VRF instance of BGP and per-VRF instance of IGP (see Figure 5).
July 10
Advanced Service
14
Figure 4 - Non BGP Route Propagation - Outbound
1 5
Figure 5 - Non BGP Route Propagation - Inbound
10
8 6 9
For troubleshooting we will follow these steps which are in detail in
July 10
Advanced Service
15
What Is Multi-VRF CE (VRF-Lite)?

Multi-VRF CE (VRF-lite) is an application based on VRF implementation. VRF-lite supports multiple overlapping and independent VRFs on the CE router. There is no MPLS functionality on the CE router. No label exchange between the CE and PE router. No labelled packet flow between the CE and PE router.
What Are the Effects of MPLS VPNs on Packet Forwarding?

The VPN label of the BGP route is understood only by the egress PE router. An end-to-end LSP tunnel is required between the ingress and egress PE routers. BGP next-hop addresses must be IGP routes. LDP labels will be assigned to addresses in the global routing table. LDP labels are not assigned to BGP routes (BGP routes receive VPN labels). Summarisation breaks the LSP tunnel.
BGP next-hops announced in IGP must not be summarised in the core network. Customers can use overlapping addresses.
For successful propagation of MPLS VPN packets access an MPLS backbone, there must be an unbroken LSP tunnel between PE routers. This is because the second label in the stack is recognised only by the egress PE router that has originated it, and will not be understood by any other router should it ever become exposed.
MTU issues
One way of preventing labelled packets from exceeding the maximum size (and being fragmented as a result) is to increase the MTU size of labelled packets for all segments in the LSP tunnel. The problem will typically occur on LAN switches, where it is more likely that a device does not support oversized packets (also called jumbo frames or, sometimes, giants or baby giants). Some devices support jumbo frames, and some need to be configured to support them. The MPLS MTU size is increased automatically on WAN interfaces and needs to be increased manually on LAN interfaces. The MPLS MTU size has to be increased on all LSRs attached to a LAN segment. Additionally, the LAN switches used to implement switched LAN segments need to be configured to support jumbo frames. A different approach is needed if a LAN switch does not support jumbo frames. The problem may be even worse for networks that do not allow ICMP MTU discovery messages to be forwarded to sources of packets and if the Dont Fragment bit (DF bit) is strictly used. This situation can be encountered where firewalls are used. http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010 edab.shtml
July 10
Advanced Service
16
MPLS Traffic Engineering Introduction

The following section is by no means a comprehensive description of MPLS Traffic Engineering. Each of the topics covered therein try to give the reader a good high level view. Readers are encouraged to refer to the reference material for a complete discussion of the respective topic.
What is MPLS TE?

Aside from being an acronym for Traffic Engineering, the concept of TE is essentially manipulating network traffic to fit the underlying network. The main objectives of TE are to choose paths for data traffic which are efficient and reliable while optimising network resources and traffic performance. Therefore TE will compute a path from a particular node to another given node such that the path does not violate any constraints (bandwidth/administrative requirements) and is optimal (note, this doesnt mean it is the lowest metric path, rather by some scalar metric). Once such a path is computed, TE is responsible for establishing and maintaining forwarding along this path. The Traffic Engineering addresses the key issues as follows: Fast Convergence for core link and core node failure. Minimise network delay under fault conditions. Maintain diverse paths between PE1 and PE2 routers. Reduce the overall cost of operations by more efficient use of bandwidth resources. Prevent a situation where some parts of a service provider network are over utilised (congested), while other parts remain under utilised. Implement traffic protection against failures. Enhance SLA in combination with QoS.
Why use MPLS TE?

If we had unlimited bandwidth which resulted in no congestion, we wouldnt need MPLS TE, but the fact of the matter is that in reality networks have to consider MPLS TE for it: Optimises network utilisation. Handles unexpected congestion. Handles link and node failures, main reason for MPLS/TE deployment.
How does MPLS TE optimise network utilisation?

MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering. Thus, it can be offered in a network what now can be achieved only by overlaying a Layer 3 network on a Layer 2 network. MPLS traffic engineering automatically establishes and maintains LSPs across the backbone, using RSVP. The path used by a given LSP at any point in time is determined based on the LSP resource requirements and network resources, such as bandwidth.
July 10
Advanced Service
17
MPLS TE is built on the following mechanisms: Tunnel interfaces. An MPLS TE path calculation module. RSVP with traffic engineering extensions. An MPLS TE link management module.
How does MPLS TE handle unexpected congestion?

One approach to engineer a backbone is to define a mesh of tunnels from every ingress device to every egress device. The MPLS TE path calculation and signalling modules determine the path taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network. The IGP, operating at an ingress device, determines which traffic should go to which egress device, and steers that traffic into the tunnel from ingress to egress. Sometimes, a flow from an ingress device to egress device is so large that it cannot fit over a single link, so it cannot be carried by a single tunnel. In this case multiple tunnels between a given ingress and egress can be configured, and the flow is load shared among them.
How does MPLS TE handle unexpected link and node failures?

Failures in the network happen, if they didnt then a lot of us would be out of a job. There are usually two kinds of failures in the network; link failures and node failures. When such failures occur in the network it is imperative to mitigate packet loss and disruption to users of the network. MPLS TE provides a mechanism known as Fast Reroute (FRR) or MPLS TE Protection to deal with fast recovery in such failure scenarios.
CBR (Constraint-Based Routing)

In traditional networks, the IGP calculates paths through the network based on the network topology alone. Routing is destination-based, and all traffic to a given destination from a given source uses the same path through the network. That path is based simply on what the IGP regards as the least cost between the two points (source and destination). For Constraint-based routing (also referred as CSPF Constrained Shortest Path First), either IS-IS or OSPF with extensions is used to carry resource information like available bandwidth on the link. Both linkstate protocols use new attributes to describe the nature of each link with respect to the constraints. It is calculated at the edge of a network, modified Dijkstras algorithm at tunnel headend. The output is a sequence of IP interface addresses (next-hop routers) between tunnel endpoints. However, this list of routers is known only to the router at the headend of the tunnel that is attempting to build the tunnel. Somehow, this now explicit path must be communicated to the intermediate routers. It is not up to the intermediate routers to make their own CSPF calculations: they merely abide by the path that is provided to them by the headend router. Therefore, some signalling protocol is required to confirm the path, to check and apply the bandwidth reservations, and finally to apply the MPLS labels to form the MPLS LSP through the routers. RSVP is used to confirm and reserve the path and apply the labels that identify the tunnel. LDP or TDP is used to apply the labels for underlying MPLS network. RSVP plays a significant role in path setup for LSP tunnels and supports both unicast and multicast applications.
July 10
Advanced Service
18
Traditional RSVP
The IETF specified RSVP as a signalling protocol for the INTSERV architecture. RSVP enables application to signal per-flow QoS requirements to the network. Service parameters are used to specifically quantify there requirements for admission control. RSVP signals resource reservation requests along the routed path available within the network. It does not perform its own routing; instead, it is designed to use the Internets current robust routing protocols. Like other IP traffic, it depends on the underlying routing protocol to determine the path for both its data and its control traffic. The RSVP daemon in a router communicates with two local decision modules before making a resource reservation: Admission control: Determines whether the node has sufficient available resources to supply the requested QoS. Policy control: Determines whether the user has administrative permission to make the reservation. If either check fails, the RSVP daemon sends an error notification to the application process that originated the request.
The RSVP process can be broken down into five distinct steps: Data senders send RSVP PATH control messages the same way they send regular data traffic. There messages describe the data they are sending or intend to send. Each RSVP router intercepts the PATH messages, saves the previous hop IP address, writes its own address as the previous hop, and sends the updated message along the same route the application data is using. Receiver stations select a subset of the sessions for which they are receiving PATH information and request RSVP resource reservations from the previous hop router using an RSVP RESV message. The RSVP RESV messages going from a receiver to a sender takes an exact reserve path when compared to the path taken by the RSVP PATH message. The RSVP routers determine whether they can honour those RESV requests. If they cannot, they refuse the reservations. If they can, they merge reservation requests being received and request a reservation from the previous hop router. The senders receive reservation requests from the next-hop routers indication that reservations are in place. Note that the actual reservation allocation is made by the RESV messages.
The RSVP messages type used in the path setup is as following: Path: Messages run from Sender (Headend in case of TE) toward Receiver (Tail in case of TE). Resv: Messages run from Receiver toward Sender. PathTear: When call has finished this message is send to free up the resources on network. ResvErr: When an error occurs during reservation task. PathErr: When an error occurs related to Path discovering or failure.
July 10
Advanced Service
19
RSVP-TE
RSVP-TE extends the available RSVP protocol to support LSP path signalling. RSVP-TE uses RSVPs available signalling messages, making certain modifications to support TE. Some important extensions include the following: Label reservation support: To use RSVP for LSP tunnel signalling, RSVP needs to support label reservations and installation. Unlike normal RSVP flows, TE-RSVP uses RSVP for label reservations for flows without any bandwidth reservations. A new type of FlowSpec object is added for this purpose. TE-RSVP also manages labels to reserve labels for flows. Source routing support: LSP tunnels use explicit source routing. Explicit source routing is implemented in RSVP by introducing a new object, SRO. RSVP host support: In TE-RSVP. RSVP PATH and RESV messages are originated by the network head-end routers. This is unlike the original RSVP, in which RSVP PATH and RESV messages are generated by applications in end-hosts. Support for identification of the ER-LSP-based TE tunnel: New types of Filter_Spec and Sender_Template objects are used to carry the tunnel identifier. The Session Object is also allowed to carry a null IP protocol number because an LSP tunnel is likely to carry IP packets of many different protocol numbers. Support for new reservation removal algorithm: A new RSVP message, RESV Tear Confirm, is added. This message is added to reliably tear down an established TE tunnel.
A summary of the RSVP Objects that were added or modified to support TE is following: Label: It performs label distribution; carried by RESV message. Label Request: It is used to request label allocation; carried by PATH message. Source Route: It specifies the explicit source router; carried by PATH message. Record Route: It is used to record the path taken by the RSVP message; carried by PATH and RESV messages. Session Attribute: It specifies the holding priority and setup priority; carried by PATH. Session: It can carry a null IP protocol number; carried by PATH message. Filter_Spec: It can carry a tunnel identifier to enable ER_LSP identification; carried by RESV message.
Fast Reroute (FRR)

Fast Reroute (also called as MPLS TE Protection) is the MPLS TE ability to steer traffic away from the IGP-derived shortest path helps mitigate packet loss associated with link or node failures in the network. In an event path failed the headend reroutes calculating a new path for an LSP after its existing path goes down. However, during the time required to perform this basic reroute, there can be significant traffic loss; the packet loss is potentially worse than with regular IP routing if you are autorouting over the TE tunnel. This is because it is firstly needed to signal a new TE LSP through RSVP and run SPF for destinations that need to be routed over the tunnel. It is desirable to be able to deal with a link or node failure in a way that has less loss than the basic headend LSP reroute. Normally, when a link or node fails, this failure is signalled to the headends that had LSPs going through the failed link or node. The headends affected attempt to find new paths across the network for these tunnels. Local protection is the term used when the backup or protected tunnel is built to cover only a segment of the primary LSP. Local protection requires the backup LSP to be presignalled.
July 10
Advanced Service
20
In local protection, the backup LSP is routed around a failed link (in link protection) or node (in node protection), and primary LSPs that would have gone through that failed link or node are instead encapsulated in the backup LSP. Note: In a MPLS-TE tunnel configuration when there are multiple path-option statements under tunnel configuration, and a link/node failure causes headend to pick the next path option in the list; this action is not considered a protection. The reason is no backup resources are pre-computed or signalled before failure. Configuring multiple path options is merely a way to influence basic LSP rerouting. Unless the backup resources are signalled before any failure, there can be no fast protection. Link failure is catered for using N-Hop backup tunnels, a backup tunnel that terminates on the router that is the next-hop from the router that is attached to the protected link. Node failure is catered for using NN-Hop (Next-Next-Hop) backup tunnels, which are tunnels that terminates on the routers next-next-hop. NN-Hop backup tunnels are preferred for protection over NHop tunnels if multiple backup tunnels exist on a protected interface. A point of Local Repair (PLR) is the point at which the failure is rerouted around and is also the head-end of a backup tunnel. A Merge Point (MP) is where the tail of the backup tunnel terminates. A MP is 1-Hop away for Link Protection and 2-Hop away for Node Protection. (See Figure 6, Figure 7 and Figure 8 as examples). Figure 6 - Primary Tunnel Path Head End
PE4 P2 P1
P3
PE6
Middle Point Points
P30
Tail End
PE5
P31
P32
PE7
The path showed in Blue arrow indicates the primary tunnel path from PE4 toward PE7. PE4 is the Head End. PE7 is the Tail End. P2, P3, and P32 are the Middle Points.
Figure 7 - Backup Tunnel - Node Protection

P1
Next-Next -Hop
P3 PE6
PE4
P2
P30
PE5
P31
P32
PE7
The path showed in Red arrow indicates the backup tunnel which protects P2 failure. P3 is the Merge point between primary and backup tunnel (for this case).
July 10
Advanced Service
21
Figure 8 - Backup Tunnel - Link Protection Link Protected Next-Hop

P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
The path showed in Green arrow indicates the backup tunnel which protects link failure between PE4 and P2. P2 is the Merge point between primary and backup tunnel (for this case).
Auto Tunnel Mesh and Backup

MPLS Traffic Engineering AutoTunnel Mesh Group allows a network administrator to configure traffic engineer (TE) label-switched paths (LSPs) by using a few command-line interface (CLI) commands. In a network topology where edge TE label switch routers (LSRs) are connected by core LSRs, the mesh group feature automatically constructs a mesh of TE LSPs among the PE routers.
Benefits of Autotunnel Mesh Group

Minimise the initial configuration of the network. It is configured one template interface per mesh and it will be propagated to all mesh tunnel interfaces, as needed. Minimise future configurations resulting from network growth. The feature eliminates the need to reconfigure each existing TE LSR to establish a full mesh of TE LSPs whenever a new PE router is added to the network. Enable existing routers to set up TE LSPs to new PE routers. Enable the construction of a mesh of TE LSPs among the PE routers automatically.
July 10
Advanced Service
22
AToM Introduction
There is an ever-increasing demand for the transport of Layer-2 and Layer 3 over a common backbone. Any Transport over MPLS (AToM) allows an MPLS network to provide end-to-end transport for Layer 2 frames and cells. It provides support for Ethernet, PPP, HDCL, Frame Relay and ATM.
Why implement AToM?

Initially, VPNs were built using leased lines. Later, service providers offered Layer 2 VPNs that were based on point-to-point data link layer connectivity, using ATM or Frame Relay virtual circuits. Customers built their own Layer 3 networks to accommodate IP traffic. To maintaining separate networks for Layer 2 VPNs and Internet traffic is difficult and costly. So service providers want a single IP-based network to provide both Layer 2 and Layer 3 services. AToM benefits service providers that offer Layer 2 connectivity to customers with traditional offerings such as ATM, Frame Relay, and serial or PPP services. Additionally, it serves providers who are specializing in Ethernet connectivity in metropolitan areas. Services for Layer 2 VPNs also appeal to the enterprise customers of service providers customers who may already run many of these networks and want just point-to-point connectivity. The upgrade from a real Layer 2 ATM or Frame-Relay-based network to an MPLS-based network that provides the ATM or Frame Relay services by using AToM is transparent to customers. Unlike the Layer 3 IP-based VPNs using MPLS, the service provider does not participate in the Layer 3 routing of the customer. The service provider provides Layer 2 connectivity only.
Transport Types
AToM enables the following types of Layer 2 frames and cells to be directed across an MPLS backbone: Ethernet and Ethernet VLAN. ATM Adaptation Layer 5 (AAL5) and ATM Cell Relay. Frame Relay: PVC-to-PVC mode (frame-relay switching has to be enabled) and port-to-port mode (uses encapsulation HDCL). PPP. HDLC.
MTU issues
Unlike IP, most Layer 2 protocols do NOT allow fragmentation of frames. This fact has two implications: AToM transport of Frame Relay, Ethernet, and AAL5 DOES NOT allow packets to be fragmented and reassembled. All intermediate links between the ingress PE router and the egress PE router must be able to carry the largest Layer 2 frame that has been received, including the imposed label stack and the 4-byte control word3 (if it is used). The ingress PE interface and the egress PE interface must have the same MTU value.
The control word is an optional 32bits fields. It is divided into four fields. The two of these field are used depend on which Layer 2 is encapsulated.
July 10
Advanced Service
23
How AToM works?

AToM is used to forward Layer 2 frames. Frames are received on an ingress interface by the ingress PE router. At this point, the frame is a raw Layer 2 frame. The ingress PE router encapsulates it into MPLS and tunnels it across the backbone to the egress PE router. The egress PE router decapsulates the packet and reproduces the raw Layer 2 frame on the egress interface.
Label exchanging
Figure 9 - AToM - Label exchanging
VC 17 21
22
23 pop
The IGP and LDP in combination are used to create an LSP from ingress PE router to egress PE router. The Figure 9 shows the label assignment and advertisement. The egress PE router advertises the pop level for its own loopback address. The backbone router that it closest to it advertises label value 23. The next router advertises value 22, and the last label advertisement shown is value 21. An LSP from ingress router to egress route is now established. The egress PE router now allocates a local label to be the VC label for the specific circuit in this example. It selects the label value 17 for this. The VC label is advertised to the ingress PE router using the directed LDP session between them. The ingress PE router now forms a label stack. The topmost label, the tunnel label, has the value 21 and is used to guide the packets to the egress PE router. The second label, the VC label, has the value 17 and is used by the egress PE router to propagate the packet out on the correct interface.
July 10
Advanced Service
24
Frame Forwarding
The ingress PE receives a Frame Relay frame on DLCI 101 on the incoming interface (Figure 10). The DLCI is mapped to the AToM tunnel across the backbone. The Frame Relay frame is therefore encapsulated into MPLS using the label stack with label 21 as the topmost level and label 17 as the second label. The packet is then forwarded along the LSP. The topmost label is used for label swapping in the next hop. The top label is changed to the value 22. In the next hop, label swapping results in label 23 being the top label. In the router just before the egress router, the incoming label value 23 indicates pop. That label therefore performs penultimate hop popping (PHP). The topmost label is removed, and the packet is propagated to the egress PE router with the label value 17, the VC label, which is now the only label left.
Figure 10 - AToM - frame forwarding
17 DLCI 101 17 21
17 22 17 23 17 17
DLCI 202
When the PE router receives the packet with label value 17, that label value instructs the PE router to deencapsulate the packet and send it out on the associated Frame Relay DCLI. In this case the DLCI value is 202. The Frame Relay frame is now reconstructed and transmitted.
July 10
Advanced Service
25
TM
Part 2: Troubleshooting Methodology
Essential MPLS/VPN configs

MPLS LDP configuration
In all routers in the core network the following tasks should be performed as the first thing: Turn on CEF. Enable LDP protocol (either globally or per interface configuration mode). Enable MPLS in all interfaces facing core (PE-P, and P-P).
VRF configuration
Only on PEs routers: Create a VRF name. Assign RD to the VRF. Specify export and import RT Assign interface to VRF
MP-BGP
On RR routers: Configure globally the MP-BGP neighbours (all PEs). Active MP-BGP neighbours under address-family VPNv4. Configure MP-BGP parameters (community propagation, route-reflector, )
On PE routers: Configure globally the MP-BGP neighbours (Route-reflector). Active MP-BGP neighbours under address-family VPNv4. Configure MP-BGP parameters (community propagation, filtering, )
PE-CE routing
On PEs routers: Configuring PE-CE routing selecting VRF routing context. If BGP is not the protocol in used between PE-CE, you should enable redistribution in both direction between PE-CE routing protocol and BGP (under address family context in both routing protocols).
July 10
Advanced Service
27
Essential TE configs
MPLS TE tunnel configuration
In all routers in the core network the following tasks should be performed before enabling MPLS-TE: Turn on MPLS tunnels. Turn on CEF. Turn on IS-IS or OSPF.
In all routers in the core network the following tasks should be performed to enable MPLS TE: Configuring a Device to Support Tunnels. Configuring and Interface to Support RSVP-based Tunnel Signalling and IGP flooding. Configuring IS-IS for MPLS TE.
At Head-end tunnel the following tasks should be performed to create and use the MPLS TE tunnel: Configuring an MPLS TE Tunnel. In case of Auto-tunnel an ACL should be created listing all IP destinations (Remote PEs). Configuring an MPLS TE Tunnel to be used by an IGP.
MPLS TE FRR configuration

In all routers in the core network the following tasks should be performed to pre-compute the backup tunnels. Enable MPLS-TE backup tunnel support. In case of static interface tunnel configuration a backup interface should be created and a trigger should be configured on physical interface in order to activate the interface tunnel backup.
At Head-end tunnel the following task should be performed in order to enable FRR feature: In interface tunnel (or auto-template) enable fast-reroute feature.
July 10
Advanced Service
28
Essential AToM configs

On PE
The PE routers must have a /32 address assigned to their loopbacks. MPLS must be enabled in the core. Make sure MTU is large enough in the core. Enable layer 2 frame transport in both endpoint PE routers. Make sure MTU is same on both endpoint interfaces.
July 10
Advanced Service
29
TM
Part 3: Some MPLS Commands
ip cef mpls label protocol ldp no tag-switching ip propagate-ttl forwarded
tag-switching tdp router-id loopback0
IP cef must be enabled for the router to be able to build the label database. It enables ldp to be used as a default label protocol on all interfaces which have mpls enabled. (Optional) By default, the mpls ip propagate-ttl command is enabled and the IP TTL value is copied to the MPLS TTL field during label imposition. Disabling TTL propagation of forwarded packets allows the structure of the MPLS network to be hidden from customers, but not the provider. (Optional) It specifies a preferred interface for determining the LSP router-id. When executed without the force keyword, the mpls ldp router-id command modifies the method for determining the LDP router ID by causing selection of the IP address of the specified interface argument (provided that the interface is operational) the next time it is necessary to select an LDP router ID. The effect of the command is delayed until the next time it is necessary to select an LDP router ID, which is typically the next time the interface whose address is the current LDP router ID is shut down or the address itself is not configured. Interface configuration mode It enables mpls on interface applying the label protocol enabled in global configuration mode in it is not explicit specified under interface configuration mode. It creates a VRF. It creates a local virtual routing and forwarding tables a VRF. It creates a BGP extended community. This specifies a set of prefixes should be imported in remote PEs. It specifies a set of prefixes based on extended community value should be imported to local VRF database. (Optional) It extends the criteria of prefixes, based on route-map configuration, which should have extra route-target communities to be imported in remote PEs. (Optional) It refines the selection on prefixes should be imported to local VRF based on route-map configuration. The prefixes should attend the routetarget import criteria and import-map <route-map> criteria to be imported. The import map command does not replace the need for a route-target import in the VRF configuration. You use the import map command to further filter prefixes that match a route-target import statement in that VRF. (Optional) It limits the number of prefixes imported to local VRF. 31
interface <physical interface> tag-switching ip
ip vrf <vrf-name> rd <AS>:<number> route-target export <AS>:<value> route-target import <AS>:<value> export-map <route-map>
import-map <route-map>
maximum route <max> <warning threshold>
July 10
Advanced Service
interface <physical interface> ip vrf forwarding <vrf-name>p
ip address <address> <mask>
Interface configuration mode It enables mpls on interface applying the label protocol enabled in global configuration mode in it is not explicit specified under interface configuration mode. When an interface is assigned to a vrf the IP address configuration is removed. So, the ip address has to be re-configured after the ip vrf forwarding command performed. Create/enter BGP/MP-BGP processes It enables the comparison of MED for paths from neighbours in different autonomous systems. IPv4 address family routing information is advertised by default for each BGP routing session configured with the neighbour remote-as command, unless you first configure the no bgp default ipv4-unicast command before configuring the neighbour remote-as command. It enables logging of BGP neighbor status changes (up or down) and resets for troubleshooting network connectivity problems and measuring network stability. By default, Cisco IOS software does not enforce the deterministic comparison of the MED variable between all paths received from the same AS. In order to get the same result of the selection algorithm independently of the order the updates are received, this command should be enabled. By default, Cisco assigns a value of 0 to routes which didnt have MED attribute configured. In BGP algorithms when compares MED, the lower value is the best. To avoid missing MED to be considered the best path, we should enable this command to assigns the highest value. There is an issue here: some IOS releases use different values (CSCef34800). - 31S assigns a value of 4294967294 (IOS running in PEs) - 12.3 assigns a value of 4294967295 (IOS running in RRs) The first value defines the keepalive and the second value the hold-down timers. This is negotiating per TCP session; the timers to be used as a reference in BGP session will be the lowest configured between two BGP peers. It creates a peer-group (neighbour configuration template) It assigns the neighbours AS for neighbours assigned to this peer-group. It enables a MD-5 password It defined the IP source address in all BGP packet created by local router. It assigns a BGP neighbour to a peer-group template.
MP-BGP configuration route bgp 25135 bgp always-compared-med no bgp default ipv4-unicast
bgp log-neighbor-changes
bgp deterministic-med
bgp bestpath med missing-as-worst
timers bgp 10 30
neighbor neighbor neighbor neighbor neighbor
<peer-group-name> peer-group <peer-group-name> remote-as <AS> <peer-group-name> password <pwd> <peer-group-name> update-source loopback 0 <neighbor-ip> peer-group <peer-group-name>
July 10
Advanced Service
32
address-family vpnv4
neighbor <peer-group-name> activate neighbor <peer-group-name> send-community both neighbor <peer-group-name> advertisement-interval 0
neighbor <peer-group-name> route-reflector-client
neighbor <neighbor-ip> peer-group <peer-group-name> PE-CE configuration ip route vrf <vrf-name> <network> <mask> <exit-interface> <next-hop> router ospf <id> vrf <vrf-name> redistribute bgp 25135 subnets network <range> <wildcard> area <area-id> ... router bgp 25135 address-family ip vrf neighbor <ip-address> neighbor <ip-address> neighbor <ip-address> neighbor <ip-address>
It defines the MP-BGP session. All commands related to MP-BGP session should be configured under this address-family. The BGP global is related only for TCP session. It activate the BGP session. It enables the local router to send the standard community and extended community (RT, SOO, OSPF information, and so on). By the default IOS software waits between 30 seconds for eBGP peering to sending BGP routing updates. For iBGP peering waits between 5 seconds to sending BGP routing. This command should be performed only in Route-reflectors in order to reflect all iBGP prefixes learn to other iBGP neighbours. This avoids the need of full mesh configuration. It assigns a BGP neighbour to a peer-group template. It defines a static route in a vrf context. It defines an OSPF configuration in a vrf context. You should redistribute BGP prefixes in order to local CE learns remote prefixes. Do NOT forget the keyword subnets, otherwise the subnetworks will not be redistributed, only classfull prefixes (such as 10.0.0.0/8). It defines a BGP configuration in a vrf context.
<vrf-name> remote-as <as> update-source <interface> route-map <name> [in|out] filter-list <as-path-acl-#> [in|out]
neighbor <ip-address> prefix-list <name> [in|out] neighbor <ip-address> allowas-in <#>
redistribute [static|connected] redistribute ospf <id> vrf<name> match internal external1 external2 default-information originate
It defines an incoming or outgoing filter based on route-map configuration. It defines an incoming or outgoing filter based on as-path access-list configuration. It defines an incoming or outgoing filter based on prefix-list It allows the neighbour to readvertise prefixes containing duplicate AS numbers (information in AS-PATH attribute). The value specifies the number of times to allow the readvertisement. It is recommended in hub-spoken scenario. It redistributes the vrf prefixes into MP-BGP vrf database. It allows redistributing a default-route in routing table onto BGP database.
July 10
Advanced Service
33
maximum-path import 8
It specifies the number of redundant paths that can be configured as back up multipaths per a VRF prefix. A VRF will import only one path (the best path) per prefix from the source VRF table, unless the prefix is exported with a different route-target. If the best path goes down, the destination will not be reachable until the next import event occurs, and then a new best path will be imported into the VRF table. The import event runs every 15 seconds by default. The import keyword allows to a VRF table to accept multiple redundant paths in addition to the best path. This feature should be used when there are multiple paths with identical next hops available to ensure optimal convergence times. A typical application of this configuration option is to configure redundant paths in a network that has multiple route reflectors for redundancy. P.S.: Note Configuring redundant paths with the import keyword can increase CPU and memory utilization significantly, especially in a network where there are many prefixes to learn and a large number of configured VRFs. It is recommended that this feature is only configured as necessary and that the minimum number of redundant paths is configured.
ip as-path access-list <#> [permit|deny] <regular-expression> ... ip prefix-list <name> [permit|deny]<prefix>/<len>{ge<value>}{le<value>} ...
It defines a set of rules/selection based on BGP as-path attribute information. It defines a set of selection based on IP prefixes. Where: Len defines the bit-count to be compared against <prefix> value (similar to wildcard in access-list). If neither ge nor le keywords are defined, len also specifies the prefix mask. ge and le keywords defines the range of the mask. Ge specifies the minimum and le the maximum value for the mask. If ge is defined and le not, the maximum value is 32. If le is defined and ge not, the len defines the minimum value. It defines a set of rules/selection based on many values/attributes.
route-map <name> [permit|deny] <seq> match ... set ...
July 10
Advanced Service
34
mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 3600
no mpls traffic-eng auto-bw timers frequency 0
mpls traffic-eng reoptimize events link-up no mpls traffic-eng topology holddown sigerr 0
It enables MPLS traffic engineer tunnel on a device. (Optional) It controls the frequency with which tunnels with established LSPs are checked for better LSP. 3600 seconds is the default value. A value of 0 disables reoptimisation. (Optional) To control the frequency at which tunnels with established LSPs are checked for better LSPs, use this commands. A value of 0 disables reoptimisation. The default value is 3600 seconds (1 hour). (Optional) It turns on automatic reoptimisation of MPLS- TE when certain events occur, such as when an interface becomes operational. (P Routers only) When this feature is disabled, tunnel path calculations will ignore a link on which there is a traffic engineering error until either 10 seconds have elapsed or a topology update is received from the IGP. A router that is at the headend for TE tunnels might receive a RSVP No Route error message for an existing tunnel or for one being signalled due to the failure of a link the tunnel traverses before the router receives a topology update from the IGP routing protocol announcing that the link is down. In such a case, the headend router ignores the link in subsequent tunnel path calculations to avoid generating paths that include the link and are likely to fail when signalled. It enables autotunnel mesh group globally. (Optional) It configures a range of mesh primary tunnel interface numbers. Valid values are from 1 to 65535. It enables the capability of automatically building NHOP and NNHOP backup tunnels. (Optional) It enables IP processing without an explicit address. (Optional) It configures how frequently a timer will scan backup autotunnels and remove tunnels that are not being used. By default the timer scans backup autotunnels and removes tunnels that are not being used is every 3600 seconds (60 minutes). (Optional) It configures the range of mesh secondary tunnel interface numbers. Valid values are from 1 to 65535.
mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel min 1 max 999 mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface loopback 0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 3600
mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000
July 10
Advanced Service
35
interface <physical interface> mpls traffic-eng tunnels ip rsvp bandwidth 155000 155000
Interface configuration mode It enables MPLS traffic engineer on this interface. It enables RSVP for IP on an interface and specify amount of bandwidth to be reserved. The first value represents the total of bandwidth can be allocated by RSVP for this interface. The second value represents the max amount of bandwidth per flow (per tunnel) which can be allocated. ISIS configuration mode It enable this router creates level-2 adjacency only (backbone). It configures a router to generate and accept only new-style TLVs (To enable to propagate TE information). It specifies the traffic engineering router identifier for the node to be the IP address associated with interface loopback0. It turns on MPLS traffic engineering for ISIS level-2 (backbone area). (Optional) It configures the minimum amount of time that a RSVP configured router waits for an ACK message before retransmitting the same message. The default value is 1000 ms (1.0 sec). If an ACK is not received for a state, the first retransmit occurs after the initial retransmit interval. If no ACK is received after the first retransmit, a second retransmit occurs. The message continues to be retransmitted, with the gap between successive retransmits being twice the previous interval, until an ACK is received. Then the message drops into normal refresh schedule if it needs to be refreshed (Path and Resv messages), or is processed (Error or Tear messages). If no ACK is received after five retransmits, the message is discarded as required. (Optional) It configures the maximum amount of time that a RSVP configured router holds on to an ACK message before sending it. (Optional) It enables RSVP refresh reduction. RSVP refresh reduction (RFC2961) is a set of extensions to reduce the messaging load imposed by RSVP and to help it scale to support larger numbers of flows. Refresh reduction requires the cooperation of the neighbour to operate; for this purpose, the neighbour must also support the standard. If the router detects that a directly connected neighbour is not supporting the refresh reduction standard, refresh reduction will not be used on this link irrespective of this command. 36
router isis is-type level-2-only metric-style wide mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 ip rsvp signalling initial-retransmit delay 760
ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction
July 10
Advanced Service
interface Auto-Template1 ip unnumbered Loopback0 tunnel destination access-list 41
tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 4 4
tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng record-route tunnel mpls traffic-eng fast-reroute tunnel mpls traffic-eng auto-bw collect-bw
tunnel mpls traffic-eng interface down delay 0
It creates a template interface. The interface number could be from the value of 1 to 25. It enables IP processing on an interface without assigning an explicit IP address to the interface. It specifies the access-list that the template interface uses for obtaining the mesh tunnel interface destination address (Remote PEs loopback one primary tunnel per destination IP address). The value argument is the number of the access-list. It sets the MPLS TE encapsulation mode for the tunnel interface. It specifies to send data traffic to this tunnel since the IP destination is the IP of Tail End or beyond of it. It configures the setup and reservation priority for an MPLS TE tunnel. The first value is the setup-priority; it is the priority used when an LSP is signalled for this tunnel and determines which existing tunnels can be preempted any LSP with a non-0 priority. The second value is the hold-priority, it is the priority associated with an LSP for this tunnel and determines if it should be pre-empted by other LSPs that are being signalled. Valid values are from 0 to 7, where a lower number indicates a higher priority. To configure bandwidth required for an MPLS traffic engineering tunnel. The default bandwidth required is 0. It configures a path option for an MPLS TE tunnel. The dynamic keyword specifies that the path of the LSP is dynamically calculated. Instead of dynamic keyword, the explicit keyword can be defined to specify an IP explicit path. The value 1 means the path-number argument which defines among others which value path should be used for this particular interface. The lower value is consider first to define the path. (Optional) If it is enabled on the headend LSR, the interface addresses for the LSP are included in the RRO object of the resv message. It enables an MPLS TE tunnel to use an established backup tunnel if there is a link or node failure. It configures a tunnel for automatic bandwidth adjustment and for control of the manner in which the bandwidth for a tunnel is adjusted. The collect-bw keyword collects output rate information for the tunnel, but does not adjust the tunnels bandwidth. It forces a tunnel to go down as soon as the headend router detects that the label-switched path (LSP) is down. 37
July 10
Advanced Service
AToM interface atm <slot/port>.<sub-interface> point-to-point pvc <vpi>/<vci> l2transport encapsulation aal0 xconnect <peer-router-ip address> <vcid> encapsulation mpls
It creates a sub-interface It defines a PVC identification for this ATM circuit Defined the type of AAL layer on ATM, for this particular case uses AAL0 It defines the AToM circuit when the <vcid> has to be same as configured on remote PE.
July 10
Advanced Service
38
A Simplistic Topology to be used as an example for the Troubleshooting

Figure 11 - Topology used in lab for capturing output
172.17.7.83 6509-1
s1/0 s2/0
. .
Loopback 0
Interfaces 1st host of sub-network /30 Links which do not have ISIS metric specified are using the default value (metric = 10)
10
30 .4 / .31 40 .
s2/0
172.17.0.4 PE4
s1/0 s0/0
30 0/ 4. .2 19 2. 17 s3/0
...
172.17.0.2 P2
s2/0 s2/0 s0/0
0/ 2. .1 19 2. 17
s0/0 s1/0
30 s2/0 s1/0
. ...
172.16.18.0/30 s0/0
172.17.0.8 RR1
s0/0
172.17.0.1 P1
s3/0
.1 72
0 /3 .0 13 9.
172.17.8.51
s0/0
172.17.0.3
0
s1/0
/3 .0 23 9. 1 2. 17
. .
P3
s2/0 s2/0
2. 17
30 0/ 6. .3 16
s0/0
172.17.0.6 s2/0 PE6

s1/0
s3/0
. .
6509-3
s1/0 s2/0
10.33.31.4/30
0 1. .3 40 . 10
0 /3
0 /3 .0 0 45 64 . 19 = 2. ic 17 etr M
0 /3 .0 31 000 . 19 1 2. = 17 tric e M
30 0/ 0. .3 000 19 1 2. = 17 tric e M s1/0
172.17.0.9 RR2
s0/0
s2/0
. . .
172.17.0.30 P30
172.19.131.0/30
s0/0 172.19.29.8/30
30 0/ 2. 00 .3 10 19 = 2. ic 17 etr M
0 /3 .0 32 1 s3/0 6. .1 72 1
s0/0 s1/0
30 0/ 7. 0 .6 64 16 = 2. ic 17 etr M
. 10
.3 33
30 0/ 1.
s2/0 s1/0 s0/0
s1/0 s0/0
172.17.0.5 PE5
.8 53 9. .1 2 17
0 /3
s3/0 172.17.0.31 s1/0
. .
P31
172.16.130.0/30
172.17.0.32 s3/0 P32
.0 37 .1 19 2. 17
0 /3
s1/0 s0/0
172.17.0.7 PE7
s2/0
30 8/ 1. .3 3 .3 10
s0/0 s1/0
172.17.7.84 6509-2
10.40.31.8/30
172.17.8.52 6509-4
July 10
Advanced Service
39
TM
Part 4: List of Show Commands
Troubleshooting Summary
Two troubleshooting domains: Control Plane Label Distribution (LDP/TDP/RSVP/BGP labels) Label Information Base (LIB)
Forwarding Plane FIB-CEF for unlabeled packet (IP packets) LFIB-MPLS forwarding table for labelled packets
MPLS and MPLS/VPN Troubleshooting

MPLS/LPD checking
show cef interface brief show mpls interface | i (Interface|<interface>) show mpls ldp discovery show mpls ldp neighbor show mpls ldp bindings show mpls forwarding vrf <vrf-name> show ip cef vrf <vrf-name>
VRF checking
show ip vrf show ip vrf interface show run | i ip vrf {<vrf-name>}|^ rd |route-target|^ import|^ export show route-map <route-map-name> show access-list [<#>|<acl-named>] show ip prefix-list <name> show ip as-path-access-list <#> show ip community-list <#> show ip extcommunity-list <#>
CE-PE routing checking

show ip protocol vrf <vrf-name> show ip route vrf <vrf-name> sh run | b address-family ipv4 vrf <vrf-name> show ip route vrf <vrf-name> [static|connected] show ip bgp vrf <vrf-name> summary show ip bgp vrf <vrf-name> neighbor <ip> show ip bgp vrf <vrf-name> July 10
show ip bgp vrf <vrf-name> <ip-prefix> show ip bgp vrf <vrf-name> neighbor <ip> advertised-routes show ip bgp vrf <vrf-name> neighbor <ip> routes show ip ospf int brief show ip ospf neighbor show ip ospf database show ip ospf database router <ospf-router-id>
MP-BGP checking
show ip bgp vpn all summary show ip bgp vpn all label show ip bgp vpn all <prefix> show ip bgp vpn vrf <vrf-name> show ip bgp vpn rd <route-distinguisher> show ip bgp vpn vrf <vrf-name> <ip-prefix> show ip bgp vpn rd <route-distinguisher> <ip-prefix> show ip bgp vpn all dampening show ip bgp vpn all dampening [flat-stat|<prefix>] show ip bgp vrf all neighbor <PE/RR ip address> advertised-routes show ip bgp vrf all neighbor <PE/RR ip address> route sh run | i router bgp | address-family ipv4 vrf|redistribute|neighbor show route-map <route-map-name> show access-list [<#>|<acl-named>] show ip prefix-list <name> show ip as-path-access-list <#> show ip community-list <#>
Path verification
! On PEs ping mpls ipv4 <ip address> /<mask in bit count> trace mpls ipv4 <ip address> /<mask in bit count> ping vrf <vrf-name> <ip address> trace vrf <vrf-name> <ip address>
! On CEs and ping mpls ipv4 <ip address> /<mask in bit count> trace mpls ipv4 <ip address> /<mask in bit count>
July 10
MPLS/TE and FRR Troubleshooting

Data Plane verification
1. Identify the destination
show ip route vrf <vrf-name> <ip-address-of-remote-CE> show ip route <ip-address-of-remote-PE> show int <tunnel #> | i rate|BW trace mpls traffic tunnel <#>
2.
Checking labels in Data Plane

show ip cef vrf <vrf-name> <ip-address-of-remote-CE> show ip cef <ip-address-of-remote-PE>
3.
Comparing labels with Control Plane information

show ip rsvp reservation detail filter destination <ip-address-of-PE> show ip bgp vpn vrf <vrf-name> <ip-address-of-remote-CE>
Control Plane verification

1. Checking the status of Interface tunnel
show mpls traffic-eng auto-tunnel mesh | i <ip-address> show mpls traffic-eng auto-tunnel mesh | i <tunnel #> show ip int bri | i Tunnel
2.
Checking if CEF is enabled in all Core routers (Ps and PEs).

show mpls traffic-eng tunnels <tunnel #> | i Explicit show ip int bri | i <ip-address> show ip interface <interface> | i switching
3.
Checking if MPLS, LDP and MPLS-TE are enabled in all Core routers.
sh mpls int | i (Interface|<interface>)
4.
Checking if MPLS traffic-eng and MPLS Traffic-eng auto-tunnel are enabled in all Core routers (Ps and PEs).
show mpls traffic-eng tunnels brief
5.
Check if ISIS is enabled on traffic-eng in all Core routers (Ps and PEs). Level-2 is enabled on Traffic-eng. Metric wide enabled in Level-2 area. All interfaces are enabled in Level-2 area.
sh clns protocol | i metrics sh clns interface <interface> sh isis mpls traffic-eng tunnel sh isis mpls traffic-eng adjacency-log July 10
sh isis topology sh isis database <PE-hostname>.00-00 verbose sh isis mpls traffic-eng advertisements
6.
Check if RSVP is enabled on all interfaces facing Core routers (Ps and PEs). Check if the amount of Bandwidth enable on RSVP (Global and per flow) is enough for all TE Tunnels request.
sh ip rsvp interface [<interface>] sh ip rsvp neighbor sh ip rsvp installed [<interface>] sh ip rsvp installed detail [<interface>] | b Destination is <ip address> sh ip rsvp reservation detail filter destination <ip address> sh ip rsvp reser detail filter dst <tunnel #> [source <ip address>] sh ip rsvp host [receivers|senders] sh ip rsvp reservation
7.
Check Head-End of the Tunnel the auto-template interface (Only in Head-End). The Access-list selecting all remotes PE should be provided. The autoroute announce should be enable. The path-option should be valid.
sh mpls traffic-eng auto-tunnel mesh sh ip access <acl #> sh mpls traffic-eng tunnel <tunnel #> sh mpls traff topo igp-id isis <system-id>.00 | b <isis-neigh>.00 sh mpls traffic-eng topology path <tunnel #> sh mpls traffic-eng topology path destination <ip-address> sh mpls traffic-eng tunnels role [all|head|middle|remote|tail] sh mpls traffic-eng tunnels accounting sh mpls traffic-eng link-management bandwidth-allocation [<interface>] sh mpls traffic-eng link-management [admission-control|adverstisements] sh mpls traffic-eng link-management [igp-neighbors| int <interface>]
8.
Check Fast-ReRoute. Check what is the backup tunnel create for a particular primary tunnel. Check RSVP reservation. Check interface tunnel details.
sh ip rsvp fast-reroute [bw-protect] sh ip rsvp fast [detail] filter [destination <ip>] [source <ip>] sh mpls traffic-eng tunnels <primary-tunnel> protection sh mpls traffic-eng tunnels <backup-tunnel> sh mpls traffic-eng fast-reroute database
In this next section will be presented the output commands and highlighting how to verify each item mentioned above.
July 10
AToM Troubleshooting
show mpls l2transport vc show mpls l2transport vc detail show mpls l2transport summary
July 10
Troubleshooting commands
In this section will be present the output commands. These outputs were extracted from the lab topology present in previous section. This will be the guide line what we should expect in normal operation.
MPLS and MPLS/VPN

PE-4# show cef interface brief Interface Serial0/0 Serial1/0 Serial2/0 Null0 Loopback0 Loopback1 Auto-Template1 OSPF_SL0 Tunnel1 Tunnel2 Tunnel3 Tunnel60000 Tunnel60001 Tunnel60002 IP-Address 172.19.24.2 172.19.45.1 10.40.31.5 unassigned 172.17.0.4 4.4.4.4 unassigned unassigned unassigned unassigned unassigned unassigned unassigned unassigned Status up up up up up up up down up up up up up up Switching CEF CEF CEF no CEF CEF CEF CEF CEF CEF CEF
The first thing we have to check on MPLS network is if CEF is enabled in all interfaces facing core.
PE-4 #show mpls interf Interface Serial0/0 Serial1/0 IP Yes (ldp) Yes (ldp) Tunnel Yes Yes Operational Yes Yes
Secondly we have to check if the right label protocol is enabled in all interfaces facing core. It most likely should be ldp protocol.
PE-4# sh mpl ldp discovery Local LDP Identifier: 172.17.0.4:0 Discovery Sources: Interfaces: Serial0/0 (ldp): xmit/recv LDP Id: 172.17.0.2:0 Serial1/0 (ldp): xmit/recv LDP Id: 172.17.0.5:0
:0 means per platform allocation. (recommended mode of label allocation in frame-mode).
It identifies neighbouring discover per interface.
July 10
PE-4# show mpl ldp neigh Peer LDP Ident: 172.17.0.5:0; Local LDP Ident 172.17.0.4:0 TCP connection: 172.17.0.5.54266 - 172.17.0.4.646 State: Oper; Msgs sent/rcvd: 4067/4059; Downstream Up time: 2d10h LDP discovery sources: Serial1/0, Src IP addr: 172.19.45.2 Addresses bound to peer LDP Ident: 172.19.53.10 172.17.0.5 172.19.45.2 Peer LDP Ident: 172.17.0.2:0; Local LDP Ident 172.17.0.4:0 TCP connection: 172.17.0.2.646 - 172.17.0.4.42241 State: Oper; Msgs sent/rcvd: 4054/4069; Downstream Up time: 2d10h LDP discovery sources: Serial0/0, Src IP addr: 172.19.24.1 Addresses bound to peer LDP Ident: 172.19.12.2 172.19.24.1 172.17.0.2 172.19.23.1 172.19.31.1
Neighbours Prefixes (all interfaces in global routing table).
It shows TCP connection status between neighbors.

PE-4# sh mpl ldp bindings tib entry: 172.16.18.0/30, rev 40 local binding: tag: 30 remote binding: tsr: 172.17.0.2:0, tag: 28 remote binding: tsr: 172.17.0.5:0, tag: 40 tib entry: 172.17.0.2/32, rev 8 local binding: tag: 16
This defines either 172.17.0.2 neighbour is the destionation of 172.17.0.2/32 prefix, or this neighbour is in MPLS border, beyond it it is an IP network only (edge LSR).
remote binding: tsr: 172.17.0.2:0, tag: imp-null remote binding: tsr: 172.17.0.5:0, tag: 26 tib entry: 172.17.0.4/32, rev 4 local binding: tag: imp-null remote binding: tsr: 172.17.0.5:0, tag: 16 remote binding: tsr: 172.17.0.2:0, tag: 25 tib entry: 172.19.45.0/30, rev 5 local binding: tag: imp-null remote binding: tsr: 172.17.0.5:0, tag: imp-null remote binding: tsr: 172.17.0.2:0, tag: 26 . . . [output omitted]
172.17.0.4/32 is a Loopback 0 IP address, local ip address prefix, so PE-4 is sending a POP label flag to its neighbours.
Label to be 172.19.45,0/30 is a serial imposed which connects PE-4 to address 172.17.0.5 neighbor (PE-5), so it is a local ip address prefix to PE-4 and PE-5. Then, both are sending POP label flag to their neighbours.
It shows LIB (Label control plane database).
In the next page we will analyse in detail a global prefix in LIB, FIB and LFIB databases.
July 10
In frame-mode, labels are allocated independently, i.e. it is based on prefixes in global routing table. These labels are advertised to all LDP neighbours. RIB has to be checked per prefix to identify the best path to populate LFIB. (It is similar to what happens with RIP prefixes per example; not all paths learnt going to FIB, only the best information.)
PE-4# sh mpl ldp bind 172.16.18.0 30 tib entry: 172.16.18.0/30, rev 40 local binding: tag: 30 remote binding: tsr: 172.17.0.2:0, tag: 28 remote binding: tsr: 172.17.0.5:0, tag: 40
It shows the LIB (label control plane database).

PE-4# sh ip route 172.17.0.2 Routing entry for 172.17.0.2/32 Known via "isis", distance 115, metric 10, type level-2 Redistributing via isis Last update from 172.19.24.1 on Serial0/0, 2d11h ago Routing Descriptor Blocks: * 172.19.24.1, from 172.17.0.2, via Serial0/0 Route metric is 10, traffic share count is 1
Each neighbour advertises their own labels. In this case PE4 received two advertisements for 172.16.18.0/30 prefix.
Checking RIB and/or FIB this is the best path to reach 172.17.18.0/30
To check 172.17.0.2 and 182.19.24.1 are prefixes from neighbour which discovered in s0/0 interface.
PE-4# sh ip route 172.16.18.0 Routing entry for 172.16.18.0/30 Known via "isis", distance 115, metric 30, type level-2 Redistributing via isis Last update from 172.19.24.1 on Serial0/0, 2d11h ago Routing Descriptor Blocks: * 172.19.24.1, from 172.17.0.1, via Serial0/0 Route metric is 30, traffic share count is 1
These labels should match with the information provided in LIB, as showed above.
It shows the RIB information (IP routing database).

PE-4# sh mpl forwarding-table 172.16.18.0 Local tag 30 Outgoing tag or VC 28 Prefix or Tunnel Id 172.16.18.0/30 Bytes tag switched 0 Outgoing interface Se0/0 point2point Next Hop
It shows the LFIB (label data plane database).

PE-4# sh ip cef 172.16.18.0 det 172.16.18.0/30, version 29, epoch 0, cached adjacency to Serial0/0 0 packets, 0 bytes tag information set, all rewrites owned local tag: 30 fast tag rewrite with Se0/0, point2point, tags imposed {28} via 172.19.24.1, Serial0/0, 0 dependencies next hop 172.19.24.1, Serial0/0 valid cached adjacency tag rewrite with Se0/0, point2point, tags imposed {28}
Label to be imposed in label data packet going to serial 0/0 interface.
July 10
PE-4# sh mpl forwarding-table Local tag 16 17 . . . 26 35 . . . 43 44 45 46 47 48 49 . . . Aggregate 26 29 38 56 57 0 4.4.4.4/32[V] 172.16.132.0/30 172.16.130.0/30 172.17.0.30/32 172.19.29.80/30 172.17.0.9/32 l2ckt(100) 0 0 0 0 0 0 161019 Se0/0 Se0/0 Se0/0 Se0/0 Se0/0 none point2point point2point point2point point2point point2point point2point 31 172.17.0.32/32 0 0 Se0/0 Tu2 point2point point2point Untagged[T] 172.16.67.0/30 Outgoing tag or VC Pop tag Pop tag Prefix or Tunnel Id 172.17.0.2/32 172.19.12.0/30 Bytes tag switched 0 0 Outgoing interface Se0/0 Se0/0 point2point point2point Next Hop
Show mpls forwarding command outgoing label explanation Pop tag Remove the topmost label Untagged Send as a standard IP packet Aggregate Remove the label and do a FIB lookup (in general it is a vpn prefix, also indicated as [V] after the ipv4 prefix) 0 Explicit null (by default Cisco uses implicit null, to enable explicit null you have to use the mpls ldp explicit-null command in global configuration mode. This command is useful in MPLS QoS scenarios to implement short pipe mode architecture, i.e. the QoS implemented in Service Provides does not affect the QoS implemented on Customer network.).
July 10
Administrative AD Distance (AD).
In the next two pages we will analyse in detail two VRF prefixes in LIB, FIB and LFIB databases.
PE-4# sh ip route vrf VPN [output omitted]
VRF prefixes leart via remote PE. (via MP-iBGP AD=200).
AD
B O
5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 [200/100] via 172.17.0.5, 13:42:19 172.17.0.0/32 is subnetted, 4 subnets 172.17.8.84 [110/97] via 10.40.31.6, 02:36:04, Serial2/0 [output omitted] PE-4# sh ip bgp vpn vrf VPN label Network 4.4.4.4/32 5.5.5.5/32 Next Hop 0.0.0.0 172.17.0.5 172.17.0.5 [output omitted] 172.17.8.84/32 172.17.0.5 172.17.0.5 10.40.31.6 52/58 52/58 52/nolabel In label/Out label 47/aggregate(VPN) nolabel/47 nolabel/47 Route Distinguisher: 25135:133001804 (VPN)
VRF prefixes leart via local CE. (via CE-PE routing, in this case OSPF). If it were learnt via eBGP the AD would be 20.
Label learnt via MP-BGP, from MP-BGP neighbour. Label allocated locally and advertise to all MP-BGP, neighbours.
Path #1
Path #2 Path #3
Remember BGP is a distance vector protocol, only selects the best path per prefix to advertise to neighbour. Beside by default, it populates the FIB/LFIB using the best path only, unless maximum-path is being applied.
PE-4# sh ip bgp vpn vrf VPN 172.17.8.84 BGP routing table entry for 25135:133001804:172.17.8.84/32, version 637111 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (3 available, best #3, table VPN) Flag: 0x800 Advertised to update-groups:
Path #1
1 Local, imported path from 25135:133001805:172.17.8.84/32 172.17.0.5 (metric 620) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 49, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:5.5.5.5:512 Originator: 172.17.0.5, Cluster list: 0.0.0.1,
Path #2
mpls labels in/out 52/58 Local, imported path from 25135:133001805:172.17.8.84/32 172.17.0.5 (metric 620) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 49, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:5.5.5.5:512 Originator: 172.17.0.5, Cluster list: 0.0.0.1, mpls labels in/out 52/58 Local 10.40.31.6 (via VPN) from 0.0.0.0 (172.17.0.4) Origin incomplete,metric 97,localpref 100,weight 32768,valid, sourced, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:4.4.4.4:512, mpls labels in/out 52/nolabel
Path #3
Best Path. Path to be adverstised and to populate the FIB/LFIB
July 10
PE-4# sh ip cef vrf VPN 172.17.8.84 detail 172.17.8.84/32, version 14, epoch 0, cached adjacency to Serial2/0 0 packets, 0 bytes tag information set, all rewrites owned local tag: 52 via 10.40.31.6, Serial2/0, 0 dependencies next hop 10.40.31.6, Serial2/0 valid cached adjacency tag rewrite with Se2/0, point2point, tags imposed {} PE-4# sh ip bgp vpn vrf VPN 5.5.5.5 BGP routing table entry for 25135:133001804:5.5.5.5/32, version 471214 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med
Why it does not imposed labels?
Path #1
Paths: (2 available, best #1, table VPN) Not advertised to any peer Local, imported path from 25135:133001805:5.5.5.5/32 172.17.0.5 (metric 620) from 172.17.0.8 (172.17.0.8) Origin IGP, metric 100, localpref 100, valid, internal, best Extended Community: RT:25135:18 RT:212.183.144.1:18 Originator: 172.17.0.5, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local, imported path from 25135:133001805:5.5.5.5/32 172.17.0.5 (metric 620) from 172.17.0.9 (172.17.0.9) Origin IGP, metric 100, localpref 100, valid, internal Extended Community: RT:25135:18 RT:212.183.144.1:18 Originator: 172.17.0.5, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 PE-4# sh ip cef vrf VPN 5.5.5.5 detail 5.5.5.5/32, version 31, epoch 0, cached adjacency to Tunnel1 0 packets, 0 bytes tag information set, all rewrites owned local tag: VPN route head fast tag rewrite with Tu1, point2point, tags imposed {57 47} via 172.17.0.5, 0 dependencies, recursive next hop 172.17.0.5, Tunnel1 via 172.17.0.5/32 (Default) valid cached adjacency tag rewrite with Tu1, point2point, tags imposed {57 47}
Path #2
Best Path. Path to be adverstised and to populate the FIB/LFIB
Why it does imposed labels in this case?
VPN data packets go toward CEs which pass though out MPLS backbone will be imposed to labels. VPN data packets go toward CEs which goes to local CE will not have any labels imposed. How do we know which label is which? Checking the BGP database, above we can confirm that 47 is vrf label allocated by MP-BGP. Then 57 label is LDP or MPLS/TE label (This checking will be explained in detail in MPLS/TE section). However from this output we can confirm the Tunnel 1 interface is the outgoing interface, which can indicate a MPLS/TE label.
July 10
PE-4# sh ip vrf Name VPN Default RD 25135:133001804 Interfaces Lo1 Se2/0
It shows the vrf list created locally and what interfaces belong to vrf.
PE-4# sh ip vrf int Interface Protocol Lo1 Se2/0 IP-Address 4.4.4.4 10.40.31.5 VRF VPN VPN up up
It shows which vrf each interface belongs to.

PE-4# sh run | i ip vrf VPN|^ rd |^ route-target|^ import|^ export|ip vrf ip vrf VPN rd 25135:133001804 route-target export 25135:18 route-target export 212.183.144.1:18 route-target import 25135:18 route-target import 212.183.144.1:18
^ : means line which starts with once space following by route-target.
Using these filters, we can select only the IOS commands applied to vrf.
PE-4# sh route-map vpn route-map vpn, deny, sequence 10 Match clauses: ip address prefix-lists: vpn Set clauses: Policy routing matches: 0 packets, 0 bytes route-map vpn, permit, sequence 20 Match clauses: Set clauses: Policy routing matches: 0 packets, 0 bytes PE-4# show ip prefix-list vpn ip prefix-list vpn: 4 entries seq 5 permit 4.4.4.4/32 seq 10 permit 5.5.5.5/32 seq 20 permit 7.7.7.7/32 PE-4# sh ip as-path-access-list 100 AS path access list 100 permit ^25000 permit ^$ PE-4# sh ip extcommunity-list Extended community standard list 1 permit RT:1:1 permit RT:25135:133001804 July 10
It selects BGP prefixes which in as-path attribute value starts with the AS value 25000. (This means the next AS hop to forward the path). It selects BGP prefixes which in as-path attribute is empty (This means only prefixes created in local-AS).
It selects MP-BGP prefixes which RT value is 1:1 or 25135:133001804
PE-4# sh run | b address-family ipv4 vrf VPN address-family ipv4 vrf VPN redistribute ospf 1 vrf VPN maximum-paths import 4 no auto-summary no synchronization network 4.4.4.4 mask 255.255.255.255 route-map metric exit-address-family PE-4# show ip route vrf VPN static PE-4#show ip route vrf VPN connect 4.0.0.0/32 is subnetted, 1 subnets C C 4.4.4.4 is directly connected, Loopback1 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks 10.40.31.4/30 is directly connected, Serial2/0
PE-7# sh ip bgp vpn vrf VPN sum BGP router identifier 172.17.0.7, local AS number 25135 BGP table version is 637020, main routing table version 637020 15 network entries using 1995 bytes of memory 43 path entries using 2924 bytes of memory 25/23 BGP path/bestpath attribute entries using 3300 bytes of memory 3 BGP rrinfo entries using 72 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 5 BGP extended community entries using 264 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 8579 total bytes of memory BGP activity 37/4 prefixes, 100/21 paths, scan interval 15 secs Neighbor 10.33.31.10 V 4 AS MsgRcvd MsgSent 1 5537 7182 TblVer 636990 InQ OutQ Up/Down 0 0 15:22:00 State/PfxRcd 1
Any figures here means the BGP connection is being established. Active or Idle status means TCP connection issue.
PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 BGP neighbor is 10.33.31.10, vrf VPN, remote AS 1, external link BGP version 4, remote router ID 172.17.8.52 BGP state = Established, up for 15:22:21 Last read 00:00:00, last write 00:00:00, hold time is 30, keepalive interval is 10 seconds Configured hold time is 30, keepalive interval is 10 seconds Minimum holdtime from neighbor is 0 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received [output omitted]
BGP capability been negotiated during Open sent and confirmed state.
July 10
PE-4# sho ip bgp vpn all BGP table version is 656741, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i10.33.31.0/30 * i * i * i [output omitted] Route Distinguisher: 25135:133001805 *>i5.5.5.5/32 * i *>i10.40.31.0/30 * i [output omitted] PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 adv BGP table version is 640970, local router ID is 172.17.0.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 10.33.31.0/30 *> 10.33.31.4/30 *> 10.33.31.8/30 *>i10.40.31.0/30 *>i10.40.31.4/30 *>i10.40.31.8/30 *> 172.17.8.52/32 *>i172.17.8.84/32 Next Hop 10.33.31.10 10.33.31.10 0.0.0.0 172.17.0.5 172.17.0.4 172.17.0.5 10.33.31.10 172.17.0.5 Metric LocPrf Weight Path 96 144 0 96 0 0 49 49 100 100 100 100 32768 ? 32768 ? 32768 ? 0 ? 0 ? 0 ? 32768 ? 0 ? Route Distinguisher: 25135:133001807 (default for vrf VPN) 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 100 100 96 96 100 100 100 100 0 i 0 i 0 ? 0 ? Next Hop 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.7 Metric LocPrf Weight Path 96 96 96 96 100 100 100 100 0 ? 0 ? 0 ? 0 ?
Route Distinguisher: 25135:133001804 (default for vrf VPN)
RD created locally as there is a vrf assigned to it.
RD learnt from MPBGP neighbour as there is no vrf assigned to it.
Total of prefixes adverstised to this neighbour
Total number of prefixes 8 PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 route BGP table version is 640980, local router ID is 172.17.0.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 10.33.31.0/24 Next Hop 10.33.31.10 Metric LocPrf Weight Path 0 0 1 i Route Distinguisher: 25135:133001807 (default for vrf VPN)
Total number of prefixes 1
Total of prefixes learnt (and accept) from this neighbour.
July 10
CE-PE routing troubleshooting is the same way as traditional IP backbone. What has changed then? Only in PEs you have to add in the IOS show/debug commands the vrf information in almost all commands.
PE-4# sh ip ospf int bri Interface Se2/0 Sl0 PID 1 1 Area 0 0 IP Address/Mask 10.40.31.5/30 0.0.0.0/0 Cost 48 1 State Nbrs F/C P2P DOWN 1/1 0/0
PE-4# sh ip ospf neighbo Neighbor ID 172.17.8.83 Pri 0 State FULL/ Dead Time 00:00:38 Address 10.40.31.6 Interface Serial2/0
PE-4# sh ip ospf database
LSA 1 (router links), we should expect one LSA per router in an Area. The Link ID is the router-id. In this case there are 4 routers in Area 0
Link ID 4.4.4.4 5.5.5.5 172.17.8.83 172.17.8.84
OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 0) ADV Router 4.4.4.4 5.5.5.5 172.17.8.83 172.17.8.84 Age 1354 1991 34 1887 Seq#
In P2P link we should expect FULL state. In broadcast link, if the local router is neither a DR nor BDR it could be 2-way
Checksum Link count 2 2 5 5
0x80000074 0xA3C8 0x80000076 0xED6B 0x80000075 0xCF4 0x80000076 0x6C84
LSA 3 (summary Net links), we should expect one LSA per prefix which comes from another OSPF area. Link ID Link-ID is the IP prefix 10.33.31.3 Adv Router is the ABR. P.S.: Summary links DOES not 10.33.31.4 mean OSPF prefixes 10.33.31.8 summared.
10.33.31.8 172.17.8.51 172.17.8.51 172.17.8.52 172.17.8.52 10.33.31.4 10.33.31.3
Summary Net Link States (Area 0) ADV Router 4.4.4.4 5.5.5.5 4.4.4.4 5.5.5.5 4.4.4.4 5.5.5.5 4.4.4.4 5.5.5.5 4.4.4.4 5.5.5.5 Age 1098 726 1618 466 1618 466 1618 466 1618 466 Seq# Checksum
0x8000001D 0x15F4 0x8000001D 0xF60F 0x8000001D 0xBFD 0x80000073 0x406E 0x8000001D 0xE222 0x80000073 0x1892
LSA 2 (network links), we this example there is not network link in area 0. If we have, it would be one per broadcast link. The Link ID is the DRs router-id.
0x8000001D 0xC199 LSA 5 (AS External links), we 0x80000073 0xF60A should expect one LSA per
prefix which comes from 0x8000001D 0xB7A2 another IP routing process (via 0x80000073 0xEC13 redistribution command). Link-ID is the IP prefix Adv Router is the ASBR.
Checksum Tag 3489686063 3489686063
Type-5 AS External Link States Link ID 10.33.31.0 10.33.31.0 ADV Router 4.4.4.4 5.5.5.5 Age 1100 728 Seq#
0x8000001D 0xF42B 0x8000001D 0xD645
Link Count means the number of local links (local interfaces) the local router is advertising. One P2P interface is count as 2 local links.
July 10
PE-4# sh ip ospf database router 172.17.8.83 OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 0) LS age: 1080 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 172.17.8.83 Advertising Router: 172.17.8.83 LS Seq Number: 80000075 Checksum: 0xCF4 Length: 84 Number of Links: 5
Link type: There are 5 OSPF link types: - Stub Link - Broadcast Link - Point-to-Point Link - Virtual Link - Loopback Link All link type counts as one Link, except Point-to-Point links counts as two Links.
Link count #1
Link connected to: a Stub Network (Link ID) Network/subnet number: 172.17.8.83 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1
This is a loopback interface.
Link count #2
Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 172.17.8.84 (Link Data) Router Interface address: 10.40.31.1 Number of TOS metrics: 0 TOS 0 Metrics: 48 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.40.31.0 (Link Data) Network Mask: 255.255.255.252 Number of TOS metrics: 0 TOS 0 Metrics: 48
These two links are an a P2P interface interface.
Link count #3
Link count #4
Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 4.4.4.4 (Link Data) Router Interface address: 10.40.31.6 Number of TOS metrics: 0 TOS 0 Metrics: 48 Link connected to: a Stub Network (Link ID) Network/subnet number: 10.40.31.4 (Link Data) Network Mask: 255.255.255.252 Number of TOS metrics: 0 TOS 0 Metrics: 48
Link count #5
These two links are an a P2P interface. In OSPF interface the P2P interfaces (such as PPP and HDLC encapsulation) will be account as 2 links: one to represent the neighbours ip address and another for sub-network and mask.
The router-id of the router which generated this LSA-1 is 172.17.8.83. and three ip address interfaces advertised: 2 serial point-to-point links and 1 loopback interface.
July 10
What are new in MPLS/VPN troubleshooting comparing to traditional IP Routing are MP-iBGP exchanges. We have to check the two-way redistribution under address-family between CE-PE routing and MP-BGP beside the IP VRF configuration if it is exporting and importing the right RDs.
PE-4# sh ip bgp vpn all sum BGP router identifier 172.17.0.4, local AS number 25135 BGP table version is 673771, main routing table version 673771 34 network entries using 4522 bytes of memory 82 path entries using 5576 bytes of memory 24/23 BGP path/bestpath attribute entries using 3168 bytes of memory 3 BGP rrinfo entries using 72 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 5 BGP extended community entries using 264 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 13626 total bytes of memory BGP activity 43/9 prefixes, 142/60 paths, scan interval 15 secs Neighbor 172.17.0.8 172.17.0.9 V AS MsgRcvd MsgSent 248264 248263 77603 77602 TblVer 673771 673771
Total of VPNv4 prefixes received by this neighbour.
InQ OutQ Up/Down State/PfxRcd 0 0 0 2d17h 0 2d17h 19 19
4 25135 4 25135
Checking these 19 prefixes:

PE-4# sh ip bgp vpn all neigh 172.17.0.8 route BGP table version is 674441, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i5.5.5.5/32 *>i6.6.6.6/32 *>i7.7.7.7/32 *>i10.33.31.0/30 * i *>i10.33.31.0/24 *>i10.33.31.4/30 * i *>i10.33.31.8/30 * i * i10.40.31.0/30 * i10.40.31.4/30 * i10.40.31.8/30 *>i172.17.8.51/32 * i *>i172.17.8.52/32 * i * i172.17.8.83/32 * i172.17.8.84/32 July 10
Next Hop 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.6 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.6 172.17.0.5 172.17.0.5
Metric LocPrf Weight Path 100 100 100 96 96 0 0 144 0 144 96 144 0 49 97 49 97 97 49 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 0 i 0 i 0 i 0 ? 0 ? 0 1 i 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ? 0 ?
From those 19 prefixes learnt from this neighbour these are what were imported onto VRF VPN.
Route Distinguisher: 25135:133001805 *>i5.5.5.5/32 *>i10.40.31.0/30 *>i10.40.31.4/30 *>i10.40.31.8/30 *>i172.17.8.83/32 *>i172.17.8.84/32 *>i6.6.6.6/32 *>i10.33.31.0/30 *>i10.33.31.4/30 *>i10.33.31.8/30 *>i172.17.8.51/32 *>i172.17.8.52/32 *>i7.7.7.7/32 *>i10.33.31.0/30 *>i10.33.31.0/24 *>i10.33.31.4/30 *>i10.33.31.8/30 *>i172.17.8.51/32 *>i172.17.8.52/32 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 100 96 144 0 97 49 100 96 0 144 49 97 100 96 0 144 0 97 49 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 0 i 0 ? 0 ? 0 ? 0 ? 0 ? 0 i 0 ? 0 ? 0 ? 0 ? 0 ? 0 i 0 ? 0 1 i 0 ? 0 ? 0 ? 0 ?
Route Distinguisher: 25135:133001806
These are the 19 VPNv4 prefixes learnt from the MPBGP
So, what is in Route Distinguisher: 25135:133001804 (default for vrf VPN) database, highlighted in red text? It is based on import criteria (route-target import and import map command applied under ip vrf configuration).
PE-4# sh ip bgp vpn all neigh 172.17.0.8 advertised-routes BGP table version is 677933, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *> 4.4.4.4/32 *> 10.40.31.0/30 *> 10.40.31.4/30 *> 10.40.31.8/30 *> 172.17.8.83/32 *> 172.17.8.84/32 Next Hop 0.0.0.0 10.40.31.6 0.0.0.0 10.40.31.6 10.40.31.6 10.40.31.6 Metric LocPrf Weight Path 100 96 0 144 49 97 32768 i 32768 ? 32768 ? 32768 ? 32768 ? 32768 ?
Total of VPNv4 prefixes advertised to this neighbour.
Remember, BGP advertises ONLY the best path per each prefix. In case of the best path prefix been learnt via iBGP neighbour it will NOT be advertised to other iBGP neighbour (AS split-horizon rule), except in Route-reflector implementation. Only eBGP and local prefixes as best path will be advertised to iBGP neighbour.
July 10
Lets check if it neighbour is receiving and advertising the same set of prefixes. It should be the same if there arent filters applied inbound direction (neighbour filter | prefix-list | route-map commands).
RR1# sh ip bgp vpn all n 172.17.0.4 adv BGP table version is 227134, local router ID is 172.17.0.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network *>i4.4.4.4/32 *>i10.40.31.0/30 *>i10.40.31.4/30 *>i10.40.31.8/30 *>i172.17.8.83/32 *>i172.17.8.84/32 *>i5.5.5.5/32 *>i10.40.31.0/30 *>i10.40.31.4/30 *>i10.40.31.8/30 *>i172.17.8.83/32 *>i172.17.8.84/32 *>i6.6.6.6/32 *>i10.33.31.0/30 Network *>i10.33.31.4/30 *>i10.33.31.8/30 *>i172.17.8.51/32 *>i172.17.8.52/32 *>i7.7.7.7/32 *>i10.33.31.0/30 *>i10.33.31.0/24 *>i10.33.31.4/30 *>i10.33.31.8/30 *>i172.17.8.51/32 *>i172.17.8.52/32 Next Hop 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.5 172.17.0.6 172.17.0.6 Next Hop 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 172.17.0.7 Metric LocPrf Weight Path 100 96 0 144 49 97 100 96 144 0 97 49 100 96 0 144 49 97 100 96 0 144 0 97 49 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 0 i 0 ? 0 ? 0 ? 0 ? 0 ? 0 i 0 ? 0 ? 0 ? 0 ? 0 ? 0 i 0 ? 0 ? 0 ? 0 ? 0 ? 0 i 0 ? 0 1 i 0 ? 0 ? 0 ? 0 ?
Metric LocPrf Weight Path
These are the same 19 VPNv4 prefixes which PE-4 learnt from RR1 (see output on previous page).
So, why 25 VPNv4 prefixes and not 19 VPNv4 prefixes (as seen 2 pages before PE-4# sh ip bgp vpn all output)? The way the peer-group is configured in the RR, the RR creates only one BGP update packet and replaces the IP head (destination IP address) to send this same BGP payload information to all its neighbours which belongs to this peer-group. So, its up to neighbour ignore their own updates (in case of PE-4 it is highlighted here in red text).
July 10
RR1# sh ip bgp vpn all n 172.17.0.4 route BGP table version is 226954, local router ID is 172.17.0.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Route Distinguisher: 25135:133001804 *>i4.4.4.4/32 172.17.0.4 *>i10.40.31.0/30 172.17.0.4 *>i10.40.31.4/30 172.17.0.4 *>i10.40.31.8/30 172.17.0.4 *>i172.17.8.83/32 172.17.0.4 *>i172.17.8.84/32 172.17.0.4 Total number of prefixes 6 Metric LocPrf Weight Path 100 96 0 144 49 97 100 100 100 100 100 100 0 0 0 0 0 0 i ? ? ? ? ?
Total of VPNv4 prefixes received from this neighbour.
Now, let analyse the last topic, BGP import prefixes. There are two steps: Import VPNv4 prefixes to BGP vrf database based on import RT. From BGP vrf database select the best path of IPv4 prefix to FIB vrf database. (Once the VPNv4 is imported to BGP vrf database the RD information is removed).
By default it is imported one only path per VPNv4 prefix onto BGP vrf and only one IPv4 path per prefix onto FIB vrf database. It can be defined as maximum-paths import 8 in same address-family vrfs. This means it can be imported onto BGP vrf database up to 8 paths per VPNv4 prefix. Each PE advertises VPNv4 prefixes using unique RD and there are four route-reflectors to reflect the best VPNv4 prefixes to all remote PEs. Then, the maximum number of VPNv4 prefixes can be imported are up to 4 prefixes (one VPNv4 path per route-reflector). Remember, BGP peer advertises only the best path per VPNv4 prefix independently the maximum-path command. In this lab we have only two route-reflectors, so it can be imported up two VPNv4 prefixes onto BGP vrf database. The next output shows the full bgp database and an explanation where the prefixes come from on BGP vrf database.
PE-4# sh ip bgp vpn all BGP table version is 694263, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 25135:133001804 (default for vrf VPN) *> 4.4.4.4/32 0.0.0.0 100 32768 i *>i5.5.5.5/32 172.17.0.5 100 100 0 i This prefix was * i 172.17.0.5 100 100 0 i *>i6.6.6.6/32 172.17.0.6 100 100 0 i learn via RR2 and * i 172.17.0.6 100 100 0 i had a RD value 172.17.0.7 100 100 0 i 25135:133001806 *>i7.7.7.7/32 * i 172.17.0.7 100 100 0 i *>i10.33.31.0/30 172.17.0.6 96 100 0 ? * i 172.17.0.6 96 100 0 ? * i 172.17.0.7 96 100 0 ? * i 172.17.0.7 96 100 0 ? *>i10.33.31.0/24 172.17.0.7 0 100 0 1 i This prefix was * i 172.17.0.7 0 100 0 1 i learn via RR2 and *>i10.33.31.4/30 172.17.0.6 0 100 0 ? had a RD value * i 172.17.0.6 0 100 0 ? 25135:133001807 * i 172.17.0.7 144 100 0 ? * i 172.17.0.7 144 100 0 ? July 10
This prefix was learn via RR1 and had a RD value

25135:133001806
This prefix was learn via RR1 and had a RD value

25135:133001807
*>i10.33.31.8/30 172.17.0.7 * i 172.17.0.7 * i 172.17.0.6 * i 172.17.0.6 *> 10.40.31.0/30 10.40.31.6 * i 172.17.0.5 * i 172.17.0.5 *> 10.40.31.4/30 0.0.0.0 * i 172.17.0.5 * i 172.17.0.5 * i10.40.31.8/30 172.17.0.5 * i 172.17.0.5 *> 10.40.31.6 *>i172.17.8.51/32 172.17.0.6 * i 172.17.0.6 * i 172.17.0.7 * i 172.17.0.7 * i172.17.8.52/32 172.17.0.7 *>i 172.17.0.7 * i 172.17.0.6 * i 172.17.0.6 *> 172.17.8.83/32 10.40.31.6 * i 172.17.0.5 * i 172.17.0.5 The blue are Textblue text are * i172.17.8.84/32 172.17.0.5 the prefixes prefixes * i 172.17.0.5 10.40.31.6 advertised by RR1 *> Route Distinguisher: 25135:133001805 *>i5.5.5.5/32 172.17.0.5 * i 172.17.0.5 *>i10.40.31.0/30 172.17.0.5 * i 172.17.0.5 *>i10.40.31.4/30 172.17.0.5 * i 172.17.0.5 *>i10.40.31.8/30 172.17.0.5 * i 172.17.0.5 *>i172.17.8.83/32 172.17.0.5 * i 172.17.0.5 *>i172.17.8.84/32 172.17.0.5 * i 172.17.0.5 Route Distinguisher: 25135:133001806 *>i6.6.6.6/32 172.17.0.6 * i 172.17.0.6 *>i10.33.31.0/30 172.17.0.6 * i 172.17.0.6 *>i10.33.31.4/30 172.17.0.6 * i 172.17.0.6 *>i10.33.31.8/30 172.17.0.6 * i 172.17.0.6 *>i172.17.8.51/32 172.17.0.6 * i 172.17.0.6 *>i172.17.8.52/32 172.17.0.6 * i 172.17.0.6 Route Distinguisher: 25135:133001807 * i7.7.7.7/32 172.17.0.7 The green text are *>i 172.17.0.7 the prefixes * i10.33.31.0/30 172.17.0.7 advertised by RR2 *>i 172.17.0.7 *>i10.33.31.0/24 172.17.0.7 * i 172.17.0.7 * i10.33.31.4/30 172.17.0.7 *>i 172.17.0.7 * i10.33.31.8/30 172.17.0.7 *>i 172.17.0.7 * i172.17.8.51/32 172.17.0.7 *>i 172.17.0.7 * i172.17.8.52/32 172.17.0.7 *>i 172.17.0.7 July 10
0 0 144 144 96 96 96 0 144 144 0 0 144 49 49 97 97 49 49 97 97 49 97 97 49 49 97 100 100 96 96 144 144 0 0 97 97 49 49 100 100 96 96 0 0 144 144 49 49 97 97 100 100 96 96 0 0 144 144 0 0 97 97 49 49
100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100
0 0 0 0 32768 0 0 32768 0 0 0 0 32768 0 0 0 0 0 0 0 0 32768 0 0 0 0 32768 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i i ? ? ? ? ? ? ? ? ? ? i i ? ? ? ? ? ? ? ? ? ? i i ? ? 1 i 1 i ? ? ? ? ? ? ? ?
This Prefixes are from PE5s VPN vrf. They were exported with RT 25135:18 value.
Where other prefixes in vrf VPN come from? They are generated locally (in PE-4) or they come from CEPE routing. If it is a non-BGP protocol it should be redistributed onto BGP. The local prefixes can be identified by the next-hop value, it should be 0.0.0.0. The CE-PE prefixes are identified by the next-hop information, which is OSPF neighbour ip address (10.40.31.6). It follows the OSPF prefixes:
PE-4# sh ip route vrf VPN ospf Routing Table: VPN 172.17.0.0/32 is subnetted, 4 subnets O O O O 172.17.8.84 [110/97] via 10.40.31.6, 06:20:14, Serial2/0 172.17.8.83 [110/49] via 10.40.31.6, 06:20:14, Serial2/0 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks 10.40.31.8/30 [110/144] via 10.40.31.6, 06:20:14, Serial2/0 10.40.31.0/30 [110/96] via 10.40.31.6, 06:20:14, Serial2/0
PE-4# sh ip bgp vpn all 10.33.31.0/30 BGP routing table entry for 25135:133001804:10.33.31.0/30, version 706505 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (4 available, best #1, table VPN) Flag: 0x800 Not advertised to any peer Local, imported path from 25135:133001806:10.33.31.0/30 172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best
Finally, this appointed out what is the path will be used on FIB vrf table.
Due to maximumpath import command we have here two paths imported for the same VPNv4 prefix
25135:133001806 :10.33.31.0/30
Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local, imported path from 25135:133001806:10.33.31.0/30 172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local, imported path from 25135:133001807:10.33.31.0/30 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200
RT value, reason why these prefixes were imported onto BGP vrf VPN table.
2nd set of the 2nd VPNv4 VPN prefixes prefix. The blue text was learnt via routerreflector 1 (172.17.0.8) and the green text was learnt via router-reflector 2 (172.17.0.9)
RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48 Local, imported path from 25135:133001807:10.33.31.0/30 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48
July 10
BGP routing table entry for 25135:133001806:10.33.31.0/30, version 706457 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #1, no table) Flag: 0x800 Not advertised to any peer Local 172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local 172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 BGP routing table entry for 25135:133001807:10.33.31.0/30, version 706467 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #2, no table) Flag: 0x800 Not advertised to any peer Local 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48 Local 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 96, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/48 PE-4# sh ip route vrf VPN 10.33.31.0 Routing entry for 10.33.31.0/30 Known via "bgp 25135", distance 200, metric 96, type internal
BGP next-hop (remote PE)
Redistributing via ospf 1 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.6 20:32:11 ago Routing Descriptor Blocks: * 172.17.0.6 (Default-IP-Routing-Table), from 172.17.0.8, 20:32:11 ago Route metric is 96, traffic share count is 1 AS Hops 0, BGP network version 0
BGP neighbour which adversited this prefix (RR1).
July 10
MPLS/TE and FRR

Identify the destination
Step 1.
From a source PE identify the remote PE

PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "bgp 25135", distance 200, metric 49, type internal Redistributing via ospf 1 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 1d23h ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 1d23h ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0
It shows what the destination PE is (BGP next-hop) based on an IP address generated from a Remote CE.
PE-4# sh ip route 172.17.0.7 Routing entry for 172.17.0.7/32 Known via "isis", distance 115, metric 670, type level-2 Redistributing via isis Last update from 172.17.0.7 on Tunnel3, 23:12:02 ago Routing Descriptor Blocks: * 172.17.0.7, from 172.17.0.7, via Tunnel3 Route metric is 670, traffic share count is 1
The second look up in routing table is to identify what the route is to reach the BGP next-hop (remote PE).
PE-4# sh int tun 3 | i rate|BW MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec
Step 2.
Checking the label stack in Data plane Database

PE-4# sh ip cef vrf VPN 172.17.8.52 172.17.8.52/32, version 22, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, all rewrites owned local tag: VPN route head fast tag rewrite with Tu3, point2point, tags imposed {58 50} via 172.17.0.7, 0 dependencies, recursive next hop 172.17.0.7, Tunnel3 via 172.17.0.7/32 (Default) valid cached adjacency tag rewrite with Tu3, point2point, tags imposed {58 50}
Label in the Top of Label Stack - MPLS/TE label Leart via RSVP
Label in the Bottom of Label Stack MPLS/VPN laabel Leart via MP-BGP
July 10
This packet will use two labels to cross the MPLS network, as shows above. This example is a VPN service using a MPLS/TE backbone, so it is needed at least two labels: one for VPN and another for MPLS/TE. How do we identify the labels? Which one is which?
PE-4# sh ip cef 172.17.0.7 172.17.0.7/32, version 102, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, all rewrites owned local tag: 22 fast tag rewrite with Tu3, point2point, tags imposed {58} via 172.17.0.7, Tunnel3, 4 dependencies next hop 172.17.0.7, Tunnel3 valid cached adjacency tag rewrite with Tu3, point2point, tags imposed {58}
RSVP Label, learnt via RSVP neighbor
With one of these two commands (above - in Control Plane, below in Data Plane) you can verify that 58 is the label for MPLS/TE.
Step 3.
Checking the labels in Control plane Database

PE-4# sh ip rsvp reservation detail filter desti 172.17.0.7 Reservation: Tun Dest: 172.17.0.7 Tun ID: 3 Ext Tun ID: 172.17.0.4 Tun Sender: 172.17.0.4 Label: 58 (outgoing) . . . [output omitted] PE-4# sh ip bgp vpn vrf VPN 172.17.8.52 BGP routing table entry for 25135:133001804:172.17.8.52/32, version 509952 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med In MP-BGP database, you Paths: (4 available, best #1, table VPN) Flag: 0x800 Not advertised to any peer Local, imported path from 25135:133001807:172.17.8.52/32 172.17.0.7 (metric 670) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 49, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/50 Local, imported path from 25135:133001807:172.17.8.52/32 172.17.0.7 (metric 670) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 49, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/50 . . . [output omitted] LSP ID: 6053
Next Hop: 172.19.24.1 on Serial0/0
RSVP Label, learnt via RSVP neighbor
have to look for what the preferential path is. It will be always identify with the keyword best
MPLS/VPN Label, learnt via remote PE flooded via MP-BGP neighbour (routereflector)
July 10
Is the path taking the right route?

Step 1.
Checking Interface Tunnel status

PE-4# sh mpl traffic-eng auto-tunnel mesh Auto-Template1: Using access-list 41 to clone the following tunnel interfaces: Destination ----------172.17.0.5 172.17.0.6 172.17.0.7 Interface --------Tunnel1 Tunnel2 Tunnel3
Mesh tunnel interface numbers: min 1 max 999
It shows the primary tunnels created and identifies the tail-end for each primary tunnel created.
PE-4# sh mpl traffic-eng auto-tunnel mesh 172.17.0.7 Tunnel3 | i Tunnel3 | i 172.17.0.7
PE-4# sh mpl traffic-eng auto-tunnel mesh 172.17.0.7 PE-4# sh ip int bri Interface Protocol Serial0/0 Serial1/0 Serial2/0 Auto-Template1 Loopback0 Loopback1 Tunnel1 Tunnel2 Tunnel3 Tunnel60000 Tunnel60001 Tunnel60002 IP-Address 172.19.24.2 172.19.45.1 10.40.31.5 172.17.0.4 172.17.0.4 4.4.4.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 Tunnel3
OK? Method Status YES NVRAM YES NVRAM YES NVRAM YES unset YES NVRAM YES NVRAM YES unset YES unset YES unset YES unset YES unset YES unset up up up up up up up up up up up up up up up up up up up up up up up up
Tunnel 1, Tunnel2 and Tunnel3 are primary tunnels. Tunnel60000, Tunnel60001 and Tunne60002 are backup tunnels.
July 10
PE-4# sh ip int bri | i Tunnel Tunnel1 Tunnel2 Tunnel3 Tunnel60000 Tunnel60001 Tunnel60002 Tunnel60003 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 YES unset YES unset YES unset YES unset YES unset YES unset YES unset up up up up up up up up up up up up up up
Step 2.
Checking if CEF is enabled on a particular physical interface

PE-4# sh mpl traffic-eng tu tu3 | i Explicit Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 PE-4# sh ip int bri | i 172.19.24.2 Serial0/0 172.19.24.2 YES NVRAM up up
These two commands help you to identify the local physical exit interface for this interface Tunnel. The first command you identify the next ip address (next hop 4). In the second command, based on this ip address, you can identify what the local physical interface is.
PE-4# sh ip int s0/0 | i switching IP fast switching is enabled IP fast switching on the same interface is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF Fast switching turbo vector IP multicast fast switching is enabled IP multicast distributed fast switching is disabled
Check if CEF is enabled on a physical interface.
Step 3.
Checking LDP and MPLS-TE are enabled on interfaces

PE-4# sh mpl int Interface Serial0/0 Serial1/0 IP Yes (ldp) Yes (ldp) Tunnel Yes Yes Operational Yes Yes
Both interfaces facing Core P routers are operational in both MPLS (LDP) and MPLS-TE.
PE-4# sh mpl int | i (Interface|Serial0/0) Interface Serial0/0 IP Yes (ldp) Tunnel Yes Operational Yes
Remember all subnet-network in the core (between Ps, PEs and P-PEs) are /30, then knowing the neighbour ip address, you will know the local ip address.
July 10
Checking if MPLS traffic-eng and MPLS Traffic-eng auto-tunnel are enabled in all PEs and Ps
Step 4.
PE-4# sh mpl traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: RSVP Process: Forwarding: auto-tunnel: backup Enabled mesh Enabled (4 ), id-range:60000-64000 (3 ), id-range:1-999 every 3600 seconds, next in 2546 seconds Not Running every 3600 seconds, next in 2643 seconds every 300 seconds, next in 184 seconds DESTINATION 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.5 172.17.0.2 UP IF DOWN IF Se1/0 Se0/0 Se0/0 Se0/0 Se1/0 up/up up/up up/up up/up up/up onehop Disabled (0 ), id-range:65336-65435 running running enabled
Periodic reoptimization: Periodic FRR Promotion: Periodic auto-tunnel: backup notinuse scan: Periodic auto-bw collection: TUNNEL NAME STATE/PROT PE-4_t1 PE-4_t2 PE-4_t3 PE-4_t60000 PE-4_t60001 . . . [ output omitted ]
Displayed 7 (of 7) heads, 18 (of 18) midpoints, 7 (of 7) tails
It shows MPLS-TE parameters.
Checking if MPLS traffic-eng and MPLS Traffic-eng auto-tunnel are enabled in all PEs and Ps
Step 5.
PE-4# sh clns int serial0/0 Serial0/0 is up, line protocol is up Checksums enabled, MTU 1500, Encapsulation HDLC ERPDUs enabled, min. interval 10 msec. CLNS fast switching enabled CLNS SSE switching disabled DEC compatibility mode OFF for this interface Next ESH/ISH in 1 seconds Routing Protocol: IS-IS Circuit Type: level-1-2 Interface number 0x1, local circuit ID 0x101 Neighbor System-ID: P2 Level-2 Metric: 10, Priority: 64, Circuit ID: PE-4.00 Level-2 IPv6 Metric: 10 Number of active level-2 adjacencies: 1, if state UP Next IS-IS Hello in 1 seconds if state UP
It verifies if a particular interface has ISIS enabled showing ISIS parameters.

July 10
PE-4# sh clns protocol | i metrics Generate narrow metrics: none Accept narrow metrics: Generate wide metrics: Accept wide metrics: none level-1-2 level-1-2
It verifies the metric style in use per ISIS level.

PE-4#sh isis mpls traffic-eng adjacency-log IS-IS MPLS TE log When 3d05h 03:55:38 Neighbor ID PE-5.00 P2.00 IP Address 172.19.45.2 172.19.24.1 Interface Status Level Se1/0 Se0/0 Up Up level-2 level-2
It verifies interfaces enabled in ISIS and ISIS neighbourship (MPLS-TE perspective) created through these interfaces.
PE-4# sh isis mpls traffic-eng tunnel System Id PE-5.00 PE-6.00 PE-7.00 Tunnel Name Tunnel1 Tunnel2 Tunnel3 BW Metric 20000000 20000000 20000000 Nexthop 172.17.0.5 172.17.0.6 172.17.0.7 Metric Mode
It shows the Head-End tunnels (primary tunnels).

PE-4# sh isis mpls traffic-eng downstream-tree PE-7 Level-2 System PE-7.00 with metric 630
It shows the total cost to reach this ISIS TE neighbour

PE-4#sh isis top IS-IS paths to level-2 routers System Id P1 P2 P3 PE-4 PE-5 PE-6 PE-7 RR1 RR2 P30 P31 P32 Metric 20 10 20 -620 30 630 30 630 620 610 620 PE-5 PE-6 PE-7 P2 P2 P2 P2 P2 Tu1 Tu2 Tu3 Se0/0 Se0/0 Se0/0 Se0/0 Se0/0 *MPLS TE-Tunnel* *MPLS TE-Tunnel* *MPLS TE-Tunnel* *HDLC* *HDLC* *HDLC* *HDLC* *HDLC* Next-Hop P2 P2 P2 Interface Se0/0 Se0/0 Se0/0 SNPA *HDLC* *HDLC* *HDLC*
July 10
PE-4# sh isis data PE-4.00-00 verbo IS-IS Level-2 LSP PE-4.00-00 LSPID PE-4.00-00 Auth: NLPID: Hostname: PE-4 Router ID: IP Address: Metric: 10 172.17.0.4 172.17.0.4 IS-Extended P2.00 Area Address: 10 0xCC LSP Seq Num * 0x00000018 Length: 17 LSP Checksum 0x9B99 LSP Holdtime 64183 ATT/P/OL 0/0/0
Affinity: 0x00000000 Interface IP Address: 172.19.24.2 Neighbor IP Address: 172.19.24.1 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Global Pool BW Unreserved: [0]: [2]: [4]: [6]: 155000 kbits/sec, [1]: 155000 kbits/sec, [3]: 154998 kbits/sec, [5]: 154998 kbits/sec, [7]: 155000 kbits/sec 155000 kbits/sec 154998 kbits/sec 154998 kbits/sec
These figures show the amount of Bandwidth available after reservation for this priority and lower. Because of tunnel mpls traffic-eng auto-bw collectbw command applied under interface tunnel configuration, Instead of reserving the maximum bandwidth (100Kbits) it is reserved the amount of the traffic rate being utilised per interface tunnel.
PS.: high number means low priority.
Metric: 640
IS-Extended PE-5.00
Affinity: 0x00000000 Interface IP Address: 172.19.45.1 Neighbor IP Address: 172.19.45.2 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Global Pool BW Unreserved: [0]: [2]: [4]: [6]: Metric: 0 Metric: 10 Metric: 640 155000 kbits/sec, [1]: 155000 kbits/sec, [3]: 155000 kbits/sec, [5]: 155000 kbits/sec, [7]: IP 172.17.0.4/32 IP 172.19.24.0/30 IP 172.19.45.0/30 155000 kbits/sec 155000 kbits/sec 155000 kbits/sec 155000 kbits/sec
PE-4#sh isis mpl traffic-eng advertisements System ID: PE-4.00 Router ID: 172.17.0.4 Link Count: 2 Link[1] Neighbor System ID: P2.00 (P2P link) Interface IP address: 172.19.24.2 Neighbor IP Address: 172.19.24.1 Admin. Weight te: 10 igp: 10 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Reservable Sub Pool BW: 0 kbits/sec Global Pool BW unreserved: July 10
[0]: 155000 kbits/sec, [1]: 155000 kbits/sec [2]: 155000 kbits/sec, [3]: 155000 kbits/sec [4]: 154998 kbits/sec, [5]: 154998 kbits/sec [6]: 154998 kbits/sec, [7]: 154998 kbits/sec Sub Pool BW unreserved: [0]: 0 kbits/sec, [1]: 0 kbits/sec [2]: 0 kbits/sec, [3]: 0 kbits/sec [4]: 0 kbits/sec, [5]: 0 kbits/sec [6]: 0 kbits/sec, [7]: 0 kbits/sec Affinity Bits: 0x00000000 Link[2] Neighbor System ID: PE-5.00 (P2P link) Interface IP address: 172.19.45.1 Neighbor IP Address: 172.19.45.2 Admin. Weight te: 640 igp: 640 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec . . . [output omitted]
These figures show the amount of Bandwidth available after reservation for this priority and lower. Because of tunnel mpls traffic-eng auto-bw collectbw command applied under interface tunnel configuration, Instead of reserving the maximum bandwidth (100Kbits) it is reserved the amount of the traffic rate being utilised per interface tunnel.
PS.: high number means low priority.
ISIS-LSP related to TE parameters generated locally.

PE-4# sh isis mpl traffic-eng advertisements System ID: PE-4.00 Router ID: 172.17.0.4 Link Count: 2 Link[1] Neighbor System ID: P2.00 (P2P link) Interface IP address: 172.19.24.2 Neighbor IP Address: 172.19.24.1 Admin. Weight te: 10 igp: 10 Physical BW: 2048 kbits/sec Reservable Global Pool BW: 155000 kbits/sec Reservable Sub Pool BW: 0 kbits/sec Global Pool BW unreserved: [0]: 155000 kbits/sec, [1]: 155000 kbits/sec [2]: 155000 kbits/sec, [3]: 155000 kbits/sec [4]: 154700 kbits/sec, [5]: 154700 kbits/sec [6]: 154700 kbits/sec, [7]: 154700 kbits/sec Sub Pool BW unreserved: [0]: 0 kbits/sec, [1]: 0 kbits/sec [2]: 0 kbits/sec, [3]: 0 kbits/sec [4]: 0 kbits/sec, [5]: 0 kbits/sec [6]: 0 kbits/sec, [7]: 0 kbits/sec Affinity Bits: 0x00000000 . . . [output omitted]
These figures show the amount of Bandwidth available after reservation for this priority and lower. Results without tunnel mpls traffic-eng auto-bw collectbw command
July 10
Step 6.
Checking RSVP status

PE-4# sh ip rsvp int interface Se0/0 Se1/0 Tu60000 Tu60001 Tu60002 Tu60003 Tu60004 rsvp ena ena ena ena ena ena ena allocated 300K 0 0 0 0 0 0 i/f max 155M 155M 0 0 0 0 0 flow max sub max 155M 155M 0 0 0 0 0 0 0 0 0 0 0 0
This value (bandwidth to be considered in resource reservation ip rsvp bandwidth interface command) should be always higher than the bandwidth configured on interface tunnel otherwise the reservation will fail for this physical interface.
Both interfaces facing Core P routers are operational for RSVP. Interface S0/0 shows there is 200K of bandwidth allocated, as all tunnels are requesting 100k of bandwidth, we can say there are three tunnels using this resource.
PE-4# sh ip rsvp interface serial 0/0 interface Se0/0 rsvp ena allocated 300K i/f max 155M flow max sub max 155M 0
PE-4# sh ip rsvp neighbor 172.19.24.1 172.19.45.2 RSVP RSVP
It displays RSVP neighbour-ship created.

PE-4# sh ip rsvp installed RSVP: Serial0/0 BPS 0 1K 0 0 0 0 To 172.17.0.2 172.17.0.5 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.31 From 172.17.0.5 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 Protoc DPort 0 0 0 0 0 0 60003 1 60000 2 3 60001 Sport 1 478 8950 6911 6103 8948
Here we can identify which tunnels are using the physical resource. Figures due to tunnel mpls traffic-eng auto-bw collect-bw tunnel interface command is applied.
RSVP: Serial1/0 has no installed reservations RSVP: Tunnel60000 has no installed reservations . . . [ output omitted ] PE-4# sh ip rsvp installed RSVP: Serial0/0 BPS 0 0 0 0 100K 0 0 100K To 172.17.0.2 172.17.0.3 172.17.0.3 172.17.0.5 172.17.0.6 172.17.0.6 172.17.0.6 172.17.0.7 From 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.4 172.17.0.4 172.17.0.7 172.17.0.32 172.17.0.4 Protoc DPort 0 0 0 0 0 0 0 0 60001 60000 60001 60000 2 60000 60003 3 Sport 7514 7514 7517 168 2518 7523 4687 7463
Here we can identify which tunnels are using the physical resource. Case when tunnel mpls traffic-eng auto-bw collect-bw tunnel interface command is NOT applied.
. . . [ output omitted ]
It shows RSVP allocation per interface, per tunnel.
July 10
PE-4# sh ip rsvp installed | i (RSVP|100K) RSVP: Serial0/0 100K 100K 100K 172.17.0.6 172.17.0.7 172.17.0.5 172.17.0.4 172.17.0.4 172.17.0.4 0 0 0 2 3 1 2518 7463 9437
RSVP: Serial1/0 RSVP: Tunnel60000 has no installed reservations RSVP: Tunnel60001 has no installed reservations RSVP: Tunnel60002 has no installed reservations RSVP: Tunnel60003 has no installed reservations PE-4# sh ip rsvp installed detail serial 0/0 | b Destination is 172.17.0.7 RSVP Reservation. Destination is 172.17.0.7. Source is 172.17.0.4, Protocol is 0 , Destination port is 3, Source port is 7168 Traffic Control ID handle: 0600044C Created: 18:46:21 UTC Sat Mar 17 2007 Admitted flowspec: Reserved bandwidth: 100K bits/sec, Maximum burst: 1K bytes, Peak rate: 100K bits/sec Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes Resource provider for this flow: None Conversation supports 1 reservations [0x100044D] Data given reserved service: 0 packets (0 bytes) Data given best-effort service: 0 packets (0 bytes) Reserved traffic classified for 1949 seconds Long-term average bitrate (bits/sec): 0 reserved, 0 best-effort Policy: INSTALL. Policy source(s): MPLS/TE Outstanding query. . . . [ output omitted ]
It shows all RSVP reservation information for a particular physical interface, starting from the MPLS TE tunnel which the IP destination is 172.17.0.7.
PE-4# sh ip rsvp reservation detail filter desti 172.17.0.7 Reservation: Tun Dest: 172.17.0.7 Tun ID: 3 Ext Tun ID: 172.17.0.4 Tun Sender: 172.17.0.4 Label: 58 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 05000410. Created: 15:54:47 UTC Sat Mar 17 2007 Average Bitrate is 100K bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.17.0.2/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 58 172.19.23.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 58 172.17.0.3/32, Flags:0x29 (Local Prot Avail/to NNHOP, Node-id) July 10
LSP ID: 6107
Label subobject: Flags 0x1, C-Type 1, Label 55 172.19.32.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) Label subobject: Flags 0x1, C-Type 1, Label 55 172.17.0.32/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 52 172.19.137.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 52 172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 172.19.137.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE PE-4# sh ip rsvp reservation detail filter dst-port 3 source 172.17.0.4 Reservation: Tun Dest: 172.17.0.7 Tun ID: 3 Ext Tun ID: 172.17.0.4 Tun Sender: 172.17.0.4 Label: 58 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 05000410. Created: 15:54:47 UTC Sat Mar 17 2007 Average Bitrate is 100K bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.17.0.2/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 58 172.19.23.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 58 172.17.0.3/32, Flags:0x29 (Local Prot Avail/to NNHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 55 172.19.32.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) Label subobject: Flags 0x1, C-Type 1, Label 55 172.17.0.32/32, Flags:0x21 (Local Prot Avail/to NHOP, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 52 172.19.137.1/32, Flags:0x1 (Local Prot Avail/to NHOP) Label subobject: Flags 0x1, C-Type 1, Label 52 172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 172.19.137.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE LSP ID: 6107
In these last two commands, you can chase the label from the source to the destination. This LSP labels should be the same as showed in show mpls traffic tunnel <tunnel #> command.
July 10
PE-4# sh ip rsvp host receivers To 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 From 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.2 172.17.0.5 172.17.0.3 172.17.0.31 Pro DPort Sport Next Hop 0 0 0 0 0 0 0 1 1 1 5507 7913 4927 none none none none none none none I/F none none none none none none none Fi Serv BPS SE LOAD 4K SE LOAD 0 SE LOAD 0 SE LOAD 0 SE LOAD 0 SE LOAD 0 SE LOAD 0
Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel 60000 7495 60000 7515 60001 7496 60003 4670 Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel
List of Tunnels where PE4 is a tail End

PE-4# sh ip rsvp host senders To 172.17.0.2 172.17.0.3 172.17.0.5 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.31 From 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 Pro DPort Sport Prev Hop 0 0 0 0 0 0 0 60001 167 60002 167 1 9437 none none none none none none none I/F none none none none none none none BPS 0 0 100K 0 100K 100K 0
Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel 60000 168 2 3 2518 7463 Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel Mode(s): Host LSP-Tunnel 60003 85 Mode(s): Host LSP-Tunnel
List of Tunnels where PE4 is a Head End.

PE-4# sh ip rsvp reservation To 172.17.0.2 172.17.0.2 172.17.0.3 172.17.0.3 172.17.0.3 172.17.0.4 172.17.0.4 172.17.0.4 From 172.17.0.4 172.17.0.6 172.17.0.6 172.17.0.7 172.17.0.4 172.17.0.5 172.17.0.6 172.17.0.7 Pro DPort Sport Next Hop 0 0 0 0 0 0 0 0 60001 167 60001 7514 60000 7514 60001 7517 60002 167 1 1 1 5507 7913 4927 172.19.45.2 172.19.24.1 172.19.24.1 172.19.24.1 172.19.45.2 none none none I/F Se1/0 Se0/0 Se0/0 Se0/0 Se1/0 none none none Fi Serv BPS SE LOAD 0 SE LOAD 0 SE LOAD 0 SE LOAD 0 SE LOAD 0 SE LOAD 4K SE LOAD 0 SE LOAD 0
It shows the Reservation Requests from Downstream.
July 10
PE-4# sh ip rsvp counters interface s1/0 Serial1/0 Path PathError PathTear ResvConf Ack Hello IntegrityRespon I_AM_DSBM Recv 51 2 47 0 17893 0 0 0 Xmit 48 0 56 0 17881 0 0 0 Resv ResvError ResvTear RTearConf Srefresh IntegrityChalle DSBM_WILLING Errors Recv 94 0 26 0 17782 0 0 0 Xmit 96 13 27 0 17784 0 0 0
PE-4# sh ip rsvp counters summary All Interfaces Path PathError PathTear ResvConf Ack Hello IntegrityRespon I_AM_DSBM Error Distribution Authentication Other Recv Msg Queues RSVP Hello (per-I/F) Awaiting Authentication Recv 100 10 105 0 35794 0 0 0 Recv 0 0 0 0 0 Current Xmit 98 0 114 0 35795 0 0 0 Xmit 0 0 Max 8 0 0 Resv ResvError ResvTear RTearConf Srefresh IntegrityChalle DSBM_WILLING Errors Recv 188 0 44 0 35579 0 0 0 Xmit 192 25 36 0 35579 0 0 0
If the network is stable these figures shouldnt increment.
Step 7.
Checking Head End status

PE-4# sh mpl traffic-eng auto-tunnel mesh Auto-Template1: Using access-list 41 to clone the following tunnel interfaces: Destination ----------172.17.0.5 172.17.0.6 172.17.0.7 Interface --------Tunnel1 Tunnel2 Tunnel3
Mesh tunnel interface numbers: min 1 max 999
Verify ACL number which area applied in auto-template.

PE-4# sh ip access 41 Standard IP access list 41 permit 172.17.0.5 (1 match) permit 172.17.0.7 (1 match) permit 172.17.0.6 (1 match)
Verify ACL configuration. Make sure all destinations are listed in this ACL.
July 10
First check: Check if this is the destination you want to analyse.

PE-4# sh mpl traffic-eng tunnels tunnel 1
Second check: Check the status (up up).
Name: PE-4_t1 Status: Admin: up Oper: up
(Tunnel1) Destination: 172.17.0.5 Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 1040) Config Parameters: Bandwidth: 100 AutoRoute: enabled kbps (Global) Priority: 4 4 Metric Type: TE (default) LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/82153) 2 Bandwidth Requested: 100
Affinity: 0x0/0xFFFF
Third check: Check if the path is valid.
Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled InLabel : OutLabel : Serial0/0, 51 FRR OutLabel : Tunnel60002, 59 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.5, Tun_Id 1, Tun_Instance 9719 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.12.1 172.19.30.2 172.16.130.2 172.19.53.10 172.17.0.5 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(51) 172.17.0.1(59) 172.17.0.30(55) 172.17.0.31(43) 172.17.0.5(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 640 (TE) Explicit Route: 172.19.45.2 172.17.0.5 History: Tunnel: Time since created: 1 hours, 9 minutes Time since path change: 1 hours, 9 minutes Number of LSP IDs (Tun_Instances) used: 2 Current LSP: Uptime: 1 hours, 9 minutes LockDown: disabled
Last check: Verbatim: disabled Check outLabel to track the LSP (also the FRR information such as Interface number and label.
Fourth check: Check if this is expected path (confirm checking the topology).
Fifth check: LSP labels end-to-end.
Additional check: Check how long this tunnel is operational and the last path changed.
It shows if the tunnel is operational, if it is protected, the backup tunnel interface, the path selected dynamically. Also the LSP label a long the path (from the source to destination). Note the priority for primary tunnel is 4 4, as it is configured. The priority of backup tunnel is 7 7 (lowest priority). Another difference between primary and backup tunnels is the bandwidth request (100kbps for primary tunnels as configured, and 0kbps for backup tunnels).
July 10
PE-4# sh mpls traf topo igp-id isis 0000.0000.0004.00 | b 0000.0000.0002.00 link[0]: Point-to-Point, Nbr IGP Id: 0000.0000.0002.00, nbr_node_id:3, gen:39 frag_id 0, Intf Address:172.19.24.2, Nbr Intf Address:172.19.24.1 TE metric:10, IGP metric:10, attribute_flags:0x0 SRLGs: None physical_bw: 2048 (kbps), max_reservable_bw_global: 155000 (kbps) max_reservable_bw_sub: 0 (kbps) Global Pool Total Allocated BW (kbps) --------------bw[0]: bw[1]: bw[2]: bw[3]: bw[4]: bw[5]: bw[6]: bw[7]: . . . [ output omitted ] 0 0 0 0 300 0 0 0 Reservable BW (kbps) ----------155000 155000 155000 155000 154700 154700 154700 154700 Sub Pool Reservable BW (kbps) ---------0
Bandwidth available after 0 reservation for this priority and lower. 0

0 PS.: high number means low priority. 0 0 0 0
It shows the bandwidth reservation per interface, per priority.

PE-4# show mpls traffic-eng topology path tunnel 2 Query Parameters: Destination: 172.17.0.7 Bandwidth: 100 Priorities: 4 (setup), 4 (hold) Affinity: 0x0 (value), 0xFFFF (mask) Query Results: Min Bandwidth Along Path: 154800 (kbps) Max Bandwidth Along Path: 154900 (kbps) Hop Hop Hop Hop Hop 0: 172.19.45.1 1: 172.19.53.10 2: 172.19.131.1 3: 172.19.137.1 4: 172.17.0.7 : affinity 00000000, bandwidth 154900 (kbps) : affinity 00000000, bandwidth 154800 (kbps) : affinity 00000000, bandwidth 154800 (kbps) : affinity 00000000, bandwidth 154800 (kbps)
It shows the path to reach the Tail end. In this case PE4 PE5 P31 P32 PE7
PE-4# sh mpl traffic-eng topology path destination 172.17.0.7 Query Parameters: Destination: 172.17.0.7 Bandwidth: 0
Priorities: 0 (setup), 0 (hold)

Affinity: 0x0 (value), 0xFFFFFFFF (mask) Query Results: Min Bandwidth Along Path: 155000 (kbps) Max Bandwidth Along Path: 155000 (kbps)
Hop Hop Hop Hop

July 10
0: 172.19.24.2 1: 172.19.23.1 2: 172.16.36.1 3: 172.16.67.1
: affinity 00000000, bandwidth 155000 (kbps) : affinity 00000000, bandwidth 155000 (kbps) : affinity 00000000, bandwidth 155000 (kbps) : affinity 00000000, bandwidth 155000 (kbps)
Hop 4: 172.17.0.7
PE-4# show mpls traffic-eng autoroute MPLS TE autorouting enabled destination 0000.0000.0005.00, area isis Tunnel1 (flags: Announce) destination 0000.0000.0006.00, area isis Tunnel3 (flags: Announce) destination 0000.0000.0007.00, area isis Tunnel2 (flags: Announce) level-2, has 1 tunnels (load balancing metric 20000000, nexthop 172.17.0.7) level-2, has 1 tunnels (load balancing metric 20000000, nexthop 172.17.0.6) level-2, has 1 tunnels (load balancing metric 20000000, nexthop 172.17.0.5)
It shows tunnels that are announced to IGP, including interface, destination, and bandwidth. It refers primary tunnels.
PE-4# sh mpl traffic-eng tunnels statistics Tunnel1 (Destination 172.17.0.5; Name PE-4_t1) Management statistics: Path: 0 no path, 0 path no longer valid, 0 missing ip exp path 2 path changes 0 loose path reoptimizations, triggered by PathErrors State: Opens: 1 transitions, 0 admin down, 0 oper down 2 succeeded, 0 timed out, 0 bad path spec 0 other aborts Errors: 0 no b/w, 0 no route, 0 admin 0 bad exp route, 0 rec route loop, 0 frr activated 0 other Tunnel2 (Destination 172.17.0.7; Name PE-4_t2) Management statistics: Path: 0 no path, 0 path no longer valid, 0 missing ip exp path 1 path changes 0 loose path reoptimizations, triggered by PathErrors State: Opens: 1 transitions, 0 admin down, 0 oper down 1 succeeded, 0 timed out, 0 bad path spec 0 other aborts Errors: 0 no b/w, 0 no route, 0 admin 0 bad exp route, 0 rec route loop, 0 frr activated . . . [ output omitted ] 172.17.0.5 60004 (Destination 172.17.0.32; Name PE-5_t60004) 172.17.0.6 60003 (Destination 172.17.0.2; Name PE-6_t60003) 172.17.0.6 60002 (Destination 172.17.0.3; Name PE-6_t60002) 172.17.0.6 2 (Destination 172.17.0.4; Name PE-6_t2) 172.17.0.6 60000 (Destination 172.17.0.7; Name PE-6_t60000) 172.17.0.6 60001 (Destination 172.17.0.32; Name PE-6_t60001) 172.17.0.7 60003 (Destination 172.17.0.3; Name PE-7_t60003) 172.17.0.7 1 (Destination 172.17.0.4; Name PE-7_t1) . . . [ output omitted ] July 10
Signalling statistics:
Signalling statistics:
PE-4# sh mpl traffic-eng tunnels role tail LSP Tunnel P2_t60000 is signalled, connection is up InLabel : Serial1/0, implicit-null OutLabel :
RSVP Signalling Info: Src 172.17.0.2, Dst 172.17.0.4, Tun_Id 60000, Tun_Instance 52 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: Record Route: NONE NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits LSP Tunnel P3_t60001 is signalled, connection is up InLabel : Serial1/0, implicit-null OutLabel :
RSVP Signalling Info: Src 172.17.0.3, Dst 172.17.0.4, Tun_Id 60001, Tun_Instance 52 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: Record Route: NONE NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits . . . [ output omitted ] PE-4# sh mpl traffic-eng tunnels accounting Tunnel1 (Destination 172.17.0.5; Name PE-4_t1) 5 minute output rate 2 kbits/sec, 1 packets/sec Tunnel2 (Destination 172.17.0.7; Name PE-4_t2) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel3 (Destination 172.17.0.6; Name PE-4_t3) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60000 (Destination 172.17.0.2; Name PE-4_t60000) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60001 (Destination 172.17.0.3; Name PE-4_t60001) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60002 (Destination 172.17.0.1; Name PE-4_t60002) 5 minute output rate 0 kbits/sec, 0 packets/sec Tunnel60003 (Destination 172.17.0.5; Name PE-4_t60003) 5 minute output rate 0 kbits/sec, 0 packets/sec Totals for 7 Tunnels 5 minute output rate 2 kbits/sec, 1 packets/sec
July 10
PE-4# sh mpl traffic-eng link-management bandwidth-allocation serial 1/0 System Information:: Links Count: Bandwidth Hold Time: Link ID:: Link Status: SRLGs: Physical Bandwidth: Max Res Global BW: Max Res Sub BW: BW Descriptors: MPLS TE Link State: Inbound Admission: Outbound Admission: Admin. Weight: IGP Neighbor Count: Up Thresholds: (default) Down Thresholds: (default) KEEP PRIORITY 0 1 2 3 4 5 6 7 KEEP PRIORITY 0 None 2048 kbits/sec 155000 kbits/sec (reserved: 0% in, 0% out) 0 kbits/sec (reserved: 100% in, 100% out) 1 MPLS TE on, RSVP on, admin-up, flooded allow-all allow-if-room 640 (IGP) 1 2 max. 15 seconds
It displays how many interfaces are enabled on RSVP.
Se1/0 (172.19.45.1)
It shows the threshold when a new LSP will be generated and flooded to whole backbone area.
15 30 45 60 75 80 85 90 95 96 97 98 99 100 100 99 98 97 96 95 90 85 80 75 60 45 30 15
Downstream Global Pool Bandwidth Information (kbits/sec): BW HELD 0 0 0 0 0 0 0 0 BW HELD 0 BW TOTAL HELD 0 0 0 0 0 0 0 0 BW TOTAL HELD 0 BW LOCKED 0 0 0 0 100 0 0 0 BW LOCKED 0 BW TOTAL LOCKED 0 0 0 0 100 100 100 100 BW TOTAL LOCKED 0 G means global pool. R means bandwidth is reserved. H means bandwidth is temporarily being held for a path message.
Downstream Sub Pool Bandwidth Information (kbits/sec):
Total of the tunnels this router is aware of. T
. . . [ output omitted ] PE-4# sh mpl traffic-eng link-management admission-control System Information:: Tunnels Count: Tunnels Selected: TUNNEL ID 172.17.0.1 60001_78 172.17.0.3 60001_52 36 36 UP IF Se0/0 Se1/0 Se0/0 Se0/0 DOWN IF Se1/0 Se1/0 Se1/0 Se1/0 Se0/0 7/7 7/7 7/7 7/7 4/4 4/4
Upstream interface Downstream interface

PRIORITY STATE Resv Admitted Resv Admitted Resv Admitted Resv Admitted Resv Admitted Resv Admitted
BW (kbps) 0 0 0 0 100 100 G G G G RG RG
Tunnel id: <Headend IP address> + <tunnel #>_<id>.
172.17.0.3 60002_58 172.17.0.3 60003_58 172.17.0.4 1_9721 172.17.0.4 2_1367
Backup tunnel does not allocate bandwidth. Only the primary tunnel interface requests bandwidth.
July 10
PE-4# sh mpl traffic-eng link-management advertisements Flooding Status: Configured Areas: IGP Area[1] ID:: isis System Information:: Flooding Protocol: Header Information:: IGP System ID: MPLS TE Router ID: Flooded Links: Link ID:: 0 Point-to-Point 172.19.24.2 ID 0000.0000.0002.00, IP 172.19.24.1 10 10 None 2048 kbits/sec 155000 kbits/sec 0 kbits/sec Global Pool ----------Reservable Bandwidth[0]: Reservable Bandwidth[1]: Reservable Bandwidth[2]: Reservable Bandwidth[3]: Reservable Bandwidth[4]: Reservable Bandwidth[5]: Reservable Bandwidth[6]: Reservable Bandwidth[7]: Attribute Flags: Link ID:: 1 Point-to-Point 172.19.45.1 ID 0000.0000.0005.00, IP 172.19.45.2 640 640 None 2048 kbits/sec 155000 kbits/sec 0 kbits/sec Link Subnet Type: Link IP Address: IGP Neighbor: TE metric: IGP metric: SRLGs: Physical Bandwidth: Res. Global BW: Res. Sub BW: Downstream:: . . . [ output omitted ] 0x00000000 155000 155000 155000 155000 154800 154800 154800 154800 Link Subnet Type: Link IP Address: IGP Neighbor: TE metric: IGP metric: SRLGs: Physical Bandwidth: Res. Global BW: Res. Sub BW: Downstream:: Sub Pool ---------0 kbits/sec 0 kbits/sec 0 kbits/sec 0 kbits/sec 0 kbits/sec 0 kbits/sec 0 kbits/sec 0 kbits/sec 0000.0000.0004.00 172.17.0.4 2 ISIS ready 1 level-2
These figures should match with show mpls traffic-eng topology igp-id isis <system-id>.00 command output.
July 10
PE-4# sh mpl traffic-eng link-management igp-neighbors Link ID:: Link ID:: Se0/0 0000.0000.0002.00 (area: isis 0000.0000.0005.00 (area: isis level-2, IP: 172.19.24.1) level-2, IP: 172.19.45.2) Se1/0 Neighbor ID: Neighbor ID:
It shows MPLS-TE ISIS neighbours.

PE-4# sh mpl traffic-eng link-management statistics System Information:: LSP Admission Statistics: Path: Resv: Link ID:: 85 setup requests, 85 admits, 0 rejects, 0 setup errors 43 tear requests, 0 preempts, 0 tear errors 90 setup requests, 90 admits, 0 rejects, 0 setup errors 33 tear requests, 0 preempts, 0 tear errors Se0/0 (172.19.24.2) 34 setup requests, 34 admits, 0 rejects, 0 setup errors 16 tear requests, 0 preempts, 0 tear errors Up Resv: Down Path: Down Resv: Link ID:: 30 setup requests, 30 admits, 0 rejects, 0 setup errors 18 tear requests, 0 preempts, 0 tear errors 32 setup requests, 32 admits, 0 rejects, 0 setup errors 18 tear requests, 0 preempts, 0 tear errors 46 setup requests, 46 admits, 0 rejects, 0 setup errors 12 tear requests, 0 preempts, 0 tear errors Se1/0 (172.19.45.1) 31 setup requests, 31 admits, 0 rejects, 0 setup errors 14 tear requests, 0 preempts, 0 tear errors . . . [ output omitted ] PE-4# sh mpl traffic-eng link-management interfaces s0/0 System Information:: Links Count: Link ID:: Link Status: SRLGs: Physical Bandwidth: Max Res Global BW: Max Res Sub BW: MPLS TE Link State: Inbound Admission: Outbound Admission: Admin. Weight: IGP Neighbor Count: IGP Neighbor: IGP Area[1]: isis None 2048 kbits/sec 155000 kbits/sec (reserved: 0% in, 0% out) 0 kbits/sec (reserved: 100% in, 100% out) MPLS TE on, RSVP on, admin-up, flooded allow-all allow-if-room 10 (IGP) 1 ID 0000.0000.0002.00, IP 172.19.24.1 (Up) level-2: flooded 2 Se0/0 (172.19.24.2) Link Admission Statistics: Up Path: Link Admission Statistics: Up Path:
Flooding Status for each configured area [1]:
July 10
Step 8.
FAST REROUTE CHECKING

PE-4# sh ip rsv fast-reroute Primary Protect Tunnel I/F -----------PE-4_t1 Se0/0 PE-4_t2 Se0/0
If the state is active means the primary tunnel is down and the backup is being used.
BW BPS:Type -------100K:G 100K:G Backup Tunnel:Label ------------Tu60003:56 Tu60002:41
N-Nhop means Link protection.
State -----Ready Ready
Level ----any-unl any-unl
Type -----N-Nhop N-Nhop
PE-4_t3
Se0/0 100K:G
Tu60002:42
Ready any-unl N-Nhop
PE-4# sh ip rsvp fast bw-protect Primary Protect BW Tunnel I/F BPS:Type ------------ --------
Backup Tunnel:Label State BW-P ------------- ------ -----
Type ------
PE-4_t1 Se0/0 100K:G Tu60003:56 Ready OFF PE-4_t2 Se0/0 100K:G Tu60002:41 Ready OFF PE-4_t3 Se0/0 100K:G Tu60002:42 Ready OFF This output shows the status of backup bandwidth protection.
N-Nhop N-Nhop N-Nhop
PE-4# sh mpl traffic-eng tunnels tunnel 3 protection PE-4_t3 LSP Head, Tunnel3, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 7169 Fast Reroute Protection: Requested Outbound: FRR Ready
Backup Tu60002 to LSP nnhop

Tu60002: out i/f: Se1/0, label: 53 LSP signalling info: Original: out i/f: Se0/0, label: 44, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3
With FRR: out i/f: Tu60002, label: 42

LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None
It shows the backup tunnel interface which is protecting a primary tunnel interface.
PE-4# sh mpl traffic-eng tunnels backup PE-4_t60000
LSP Head, Tunnel60000, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.5, Instance 20
Fast Reroute Backup Provided:
Protected i/fs: Se1/0

Protected lsps: 0 Backup BW: any pool unlimited; inuse: 0 kbps PE-4_t60001
LSP Head, Tunnel60001, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.2, Instance 1
Fast Reroute Backup Provided: Protected i/fs: Se0/0 Protected lsps: 0 Backup BW: any pool unlimited; inuse: 0 kbps . . . [ output omitted ]
It shows the physical link which is protected by a specific backup tunnel.

July 10
PE-4# sh mpl traffic-eng tunnels tunnel 60002 Name: PE-4_t60002 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit __dynamic_tunnel60002 (Basis for Setup, path weight 1260) Config Parameters: Bandwidth: 0 AutoRoute: disabled kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF bw-based Metric Type: TE (default) LockDown: disabled Loadshare: 0 auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled (Tunnel60002) Destination: 172.17.0.3
InLabel
OutLabel : Serial1/0, 53 RSVP Signalling Info:
This is the Tail end of Backup tunnel. In this case it is P3. This is a node protection. In this case the node protected is P2.
Src 172.17.0.4, Dst 172.17.0.3, Tun_Id 60002, Tun_Instance 1 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.32.1 172.17.0.3 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 20 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3 History: Tunnel: Time since created: 3 hours, 1 minutes Time since path change: 3 hours, 1 minutes Number of LSP IDs (Tun_Instances) used: 1 Current LSP: Uptime: 3 hours, 1 minutes
Path of Backup Tunnel in case of failures (failure link between PE4 or node failure, P2 node)
Path when there is NO failure.
It shows the information of backup tunnel interface.
July 10
PE-4# sh ip rsv fast-reroute detail filter dest 172.17.0.7 source 172.17.0.4 PATH: Tun Dest: 172.17.0.7 Tun ID: 3 Ext Tun ID: 172.17.0.4 Tun Sender: 172.17.0.4 Path refreshes: sent: to NHOP 172.19.24.1 on Serial0/0 Session Attr: Setup Prio: 4, Holding Prio: 4 Flags: (0x7) Local Prot desired, Label Recording, SE Style Session Name: PE-4_t3 ERO: (incoming) 172.17.0.4 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.24.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.23.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.32.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.137.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.17.0.7 (Strict IPv4 Prefix, 8 bytes, /32) ERO: (outgoing) 172.19.24.1 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.23.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.32.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.19.137.2 (Strict IPv4 Prefix, 8 bytes, /32) 172.17.0.7 (Strict IPv4 Prefix, 8 bytes, /32) RRO: Empty Traffic params - Rate: 100K bits/sec, Max. burst: 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytes Fast-Reroute Backup info: Inbound FRR: Not active (label 42) LSP ID: 7169 Outbound FRR: Ready -- backup tunnel selected Backup Tunnel: Tu60002 Bkup Sender Template: Tun Sender: 172.19.45.1 Bkup FilerSpec: Tun Sender: 172.19.45.1, LSP ID: 7169 Path ID handle: 03000420. Incoming policy: Accepted. Policy source(s): MPLS/TE Status: Proxied Output on Serial0/0. Policy status: Forwarding. Handle: 0200041E Policy source(s): MPLS/T LSP ID: 7169
It shows if the backup tunnel is in used (if yes mean there is a physical link failure).
July 10
PE-4# sh mpl traffic-eng fast-reroute database Tunnel head end item frr information: Protected tunnel Tunnel3 Tunnel2 Tunnel1 Prefix item frr information: Prefix 172.17.0.6/32 172.17.0.7/32 172.16.67.0/30 6.6.6.6/32 7.7.7.7/32 172.17.8.51/32 172.17.8.52/32 10.33.31.0/30 10.33.31.4/30 10.33.31.8/30 172.17.0.5/32 5.5.5.5/32 Tunnel Tu2 Tu3 Tu2 vpn vpn vpn vpn vpn vpn vpn Tu1 vpn In-label Out intf/label 46 47 48 vpn vpn vpn vpn vpn vpn vpn 16 vpn Se0/0:Pop tag Se0/0:Pop tag Se0/0:Untagged Se0/0:25 Se0/0:25 Se0/0:29 Se0/0:30 Se0/0:26 Se0/0:27 Se0/0:28 Se0/0:Pop tag Se0/0:26 FRR intf/label Tu60002:41 Tu60002:42 Tu60002:41 Tu60002:41 Tu60002:42 Tu60002:41 Tu60002:42 Tu60002:41 Tu60002:41 Tu60002:42 Tu60003:56 Tu60003:56 Status ready ready ready ready ready ready ready ready ready ready ready ready In-label Out intf/label Tun hd Tun hd Tun hd Se0/0:Untagged Se0/0:Untagged Se0/0:Untagged FRR intf/label Tu60002:42 Tu60002:41 Tu60003:56 Status ready ready ready
LSP midpoint item frr information: LSP identifier In-label Out intf/label FRR intf/label Status
PE-4# sh mpl traffic-eng fast-reroute database detail PE-4#sh mpl traffic-eng fast-reroute database detail LFIB FRR Database Summary: Total Clusters: Total Groups: Total Items: 1 2 15
Link 2: Se0/0 (Up, 2 groups) Group 16: Se0/0->Tu60002 (Up, 12 members) Prefix 172.17.0.6/32, Tu2, ready Input label 46, Output label Se0/0:Pop tag, FRR label Tu60002:41 Prefix 172.17.0.7/32, Tu3, ready Input label 47, Output label Se0/0:Pop tag, FRR label Tu60002:42 Protected tunnel Tunnel3, ready Input label Tun hd, Output label Se0/0:Untagged, FRR label Tu60002:42 Protected tunnel Tunnel2, ready Input label Tun hd, Output label Se0/0:Untagged, FRR label Tu60002:41 Prefix 172.16.67.0/30, Tu2, ready Input label 48, Output label Se0/0:Untagged, FRR label Tu60002:41 Prefix 6.6.6.6/32, vpn, ready Input label vpn, Output label Se0/0:25, FRR label Tu60002:41 . . . [ output omitted ]
July 10
AToM
PE-4# sh mpl l2transport binding 100 Destination Address: 172.17.0.7, Local Label: Cbit: 1, MTU: 1500, Remote Label: 50 Cbit: 1, MTU: 1500, VC Type: HDLC, GroupID: 0 Interface Desc: >>>> link to CE4 49 VC Type: HDLC, GroupID: 0 Interface Desc: >>>> link to CE1 VC ID: 100
VCCV Capabilities: Type 1, Type 2
It displays the status of vc-id 100.

PE-4# sh mpl l2transport binding 172.17.0.7 Destination Address: 172.17.0.7, Local Label: Cbit: 1, MTU: 1500, Remote Label: 50 Cbit: 1, MTU: 1500, VC Type: HDLC, GroupID: 0 Interface Desc: >>>> link to CE4 49 VC Type: HDLC, GroupID: 0 Interface Desc: >>>> link to CE1 VC ID: 100
VCCV Capabilities: Type 1, Type 2 PE-4# sh mpl l2transport summary Destination address: 172.17.0.7, total number of vc: 1 0 unknown, 1 up, 0 down, 0 admin down, 0 recovering 1 active vc on MPLS interface Tu3
It displays the statistics of layer 2 vpns. In this lab there is only one vc created between PE4 and PE7.
PE-4#sh mpl l2transport vc 100 detail Local interface: Se2/0 up, line protocol up, HDLC up Destination address: 172.17.0.7, VC ID: 100, VC status: up Preferred path: not configured Default path: active Next hop: point2point Output interface: Tu3, imposed label stack {43 50} Create time: 04:19:36, last status change time: 04:19:29 Signaling protocol: LDP, peer 172.17.0.7:0 up MPLS VC labels: local 49, remote 50 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: >>>> link to CE4 Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 3786, send 3368 byte totals: receive 301794, send 277477
packet drops:
July 10
receive 0, seq error 0, send 0
Tracing a LSP end to end

Firstly we will check will is the path taken from CE-1 to reach CE-4.
CE-1# trace 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52 1 10.40.31.5 20 msec 20 msec 24 msec 2 172.19.24.1 28 msec 36 msec 12 msec 3 172.19.31.2 28 msec 20 msec 32 msec 4 172.19.131.2 20 msec 20 msec 20 msec 5 10.33.31.9 20 msec 20 msec 20 msec 6 10.33.31.10 20 msec * 20 msec
This path is: CE-1 PE4 P2 P31 P32 PE7 CE-4 Lets check this from PE4. PE-4# trace vrf VPN 10.33.31.10 Type escape sequence to abort. Tracing the route to 10.33.31.10
LDP or RSVP label for LSP tunnel from PE4- to PE7.
VPN label (learn via MP-BGP
1 172.19.24.1 [MPLS: Labels 43/49 Exp 0] 40 msec 40 msec 32 msec 2 172.19.31.2 [MPLS: Labels 40/49 Exp 0] 48 msec 40 msec 28 msec 3 172.19.131.2 [MPLS: Labels 37/49 Exp 0] 40 msec 36 msec 32 msec 4 172.19.137.2 [MPLS: Labels 49 Exp 0] 40 msec 36 msec 32 msec 5 10.33.31.9 44 msec 40 msec 40 msec
P1
CE1
PE4
P2
P3
PE6
IP
43 49 IP
P30
40 49 IP
PE5 P31 P32 PE7 CE4
37 49 IP
49 IP
IP
PE-4# sh ip cef vrf VPN 10.33.31.8 10.33.31.8/30, version 39, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, all rewrites owned local tag: VPN route head fast tag rewrite with Tu3, point2point, tags imposed {43 49} via 172.17.0.7, 0 dependencies, recursive next hop 172.17.0.7, Tunnel3 via 172.17.0.7/32 (Default) valid cached adjacency tag rewrite with Tu3, point2point, tags imposed {43 49}
LDP or RSVP label for LSP tunnel from PE4- to PE7.
VPN label (learn via MP-BGP
Lets check the VPN label. The subnetwork of 10.33.31.10 is 10.33.31.8/30.
July 10
PE-4# sh ip bgp vpn all labels | i 10.33.31.8 10.33.31.8/30 10.33.31.8/30 172.17.0.7 172.17.0.7 nolabel/49 nolabel/49
You can also with the following command:

PE-4# sh ip bgp vpn all 10.33.31.8 BGP routing table entry for 25135:133001804:10.33.31.8/30, version 894 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #1, table VPN) Not advertised to any peer Local, imported path from 25135:133001807:10.33.31.8/30 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/49 Local, imported path from 25135:133001807:10.33.31.8/30 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 0, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/49 BGP routing table entry for 25135:133001807:10.33.31.8/30, version 892 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #2, no table) Not advertised to any peer Local 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9) Origin incomplete, metric 0, localpref 100, valid, internal Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/49 Local 172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512 Originator: 172.17.0.7, Cluster list: 0.0.0.1, mpls labels in/out nolabel/49
Lets check the RSVP label or LDP label. The label which builds up a LSP tunnel from PE-4 to PE7. In this particular case the LSP is built up based on the VPNv4 next-hop, which is 172.17.0.7. You find this information on sh ip bgp vpn all labels | i 10.33.31.8 output command.
July 10
PE-4# sh ip cef 172.17.0.7 detail 172.17.0.7/32, version 41, epoch 0, cached adjacency to Tunnel3 0 packets, 0 bytes tag information set, shared, all rewrites owned local tag: 27 fast tag rewrite with Tu3, point2point, tags imposed {43} via 172.17.0.7, Tunnel3, 3 dependencies next hop 172.17.0.7, Tunnel3 valid cached adjacency tag rewrite with Tu3, point2point, tags imposed {43} This output says the exit interface is Tunnel3, which means the label learnt here is from RSVP.
PE-4# sh mpl traf tun tun 3 Name: PE-4_t3 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 630) Config Parameters: Bandwidth: 100 AutoRoute: enabled kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF bw-based Metric Type: TE (default) LockDown: disabled Loadshare: 100 auto-bw: (86400/63578) 0 Bandwidth Requested: 100 (Tunnel3) Destination: 172.17.0.7
Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled InLabel : OutLabel : Serial0/0, 43 FRR OutLabel : Tunnel60002, 40 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 5407 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.31.2 172.19.131.2 172.19.137.2 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(43) 172.19.31.1(43) 172.17.0.31(40) 172.19.131.1(40) 172.17.0.32(37) 172.19.137.1(37) 172.17.0.7(0) 172.19.137.2(0) [output ommitted] LockDown: disabled Verbatim: disabled
This is the RSVP label.
You can also get the RSVP label from the following command:
With this command you can also get the LSP tunnel from PE-4 to PE7. This set of label should match with the output shown in traceroute 2 page before.
July 10
PE-4# sh ip rsvp reservation detail filter destination 172.17.0.7 Reservation: Tun Dest: 172.17.0.7 Tun ID: 3 Ext Tun ID: 172.17.0.4 Tun Sender: 172.17.0.4 Label: 43 (outgoing) Reservation Style is Shared-Explicit, QoS Service is Controlled-Load Resv ID handle: 01000445. Created: 09:09:13 UTC Fri Jul 13 2007 Average Bitrate is 100K bits/sec, Maximum Burst is 1K bytes Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes RRO: 172.17.0.2/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 43 172.19.31.1/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 43 172.17.0.31/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 40 172.19.131.1/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 40 172.17.0.32/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 37 172.19.137.1/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 37 172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id) Label subobject: Flags 0x1, C-Type 1, Label 0 172.19.137.2/32, Flags:0x0 (No Local Protection) Label subobject: Flags 0x1, C-Type 1, Label 0 Status: Policy: Accepted. Policy source(s): MPLS/TE LSP ID: 5407
Lets go to the next router in this path, which is P2 (172.19.24.2). As P2 told to PE4 (via RSVP) to use label 43, then we will look up in LFIB an incoming label 43 (figure in the first column of the output).
P2# sh mpl forwarding-table | i 43 30 43 20 40 172.17.0.8/32 608143 Se0/0 Se2/0 point2point point2point 172.17.0.4 3 [5407] 484533
Label for incoming labelled packet Incoming label.
This is the outgoing label for this LSP. Which should match with the output in the trace command.
Lets to the same for the next hop, which is P31 (172.19.31.2).
P31# sh mpl forwarding-table | i 40 31 16 37 172.17.0.4/32 336408 Se2/0 Se1/0 point2point point2point 40 172.17.0.4 3 [5407] 486261
Outgoing label.
July 10
Because P32 is the PHP, we will have here a pop tag (explicit-null). Lets to the same for the next hop, which is P32 (172.19.131.2).
P32# 37 41 42 54 sh mpl forwarding-table | i 37 Pop tag 38 37 56 172.17.0.4 3 [5407] 463873 172.17.0.5 2 [3337] 0 172.17.0.7 1 [2002] 0 172.17.0.7 2 [9988] 73748 Se3/0 Se2/0 Se1/0 Se2/0 point2point point2point point2point point2point
Ad the last PE:

PE-7# sh ip bgp vpn all labels | i 10.33.31.8 10.33.31.8/30 0.0.0.0 49/aggregate(VPN)
PE-7# sh ip route vrf VPN 10.33.31.8 Routing entry for 10.33.31.8/30 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 25135 Advertised by bgp 25135 Routing Descriptor Blocks: * directly connected, via Serial2/0 Route metric is 0, traffic share count is 1
From here it will normal an IP packet without any labels. Conclusion: the LSP tunnel created from PE4 to PE7 is 43 40 37 explicit null. As this is using the Traffic engineer tunnel all these labels were learnt/propagated via RSVP.
July 10
TM
Part 5: Failure Scenarios
July 10
Troubleshooting Scenarios
Describe what would happen when the fault is fixed. As an example we will concentrate in only one primary tunnel which has as a Head End PE4 and tail End PE7.
Mis-configuration
ISIS metrics
Step 1.
Identify the primary tunnel

PE-4# sh mpls traffic-eng auto-tunnel mesh | i 172.17.0.7 172.17.0.7 Tunnel3
Using as a filter the destination IP address, it provides only the output we are interested to check.
Step 2.
Identify the status of the primary tunnel

PE-4# sh mpl traffic-eng tunnels tu 3 | i Path Admin: up RSVP Path Info: Shortest Unconstrained Path Info: Path Weight: 670 (TE) Oper: up Path: valid Signalling: connected Active Path Option Parameters:
Step 3.
Identify the path used in the primary tunnel

PE-4# sh mpl traffic-eng tunnels tu 3 | b Explicit Route Explicit Route: 172.19.24.1 172.19.23.2 172.16.36.2 172.16.67.2 172.17.0.7 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(48) 172.17.0.3(50) 172.17.0.6(40) 172.17.0.7(0) . . . [ output omitted ]
July 10
Checking in the diagram if this route is the expect path: PE4 P2 P3 PE6 PE7. Head End
P1
Middle Point Points
PE4
P2
P3
PE6
P30
Tail End
PE5
P31
P32
PE7
Step 4.
Identify the backup tunnels

PE-4# sh mpl traffic-eng tunnels | i Src 172.17.0.4, Dst 172.17.0.3, Src 172.17.0.4, Dst 172.17.0.3, Tun_Id 60002, Tun_Instance 167
This output shows the backup tunnel interface in use to protect (P2) NNHOP.
PE-4# sh mpl traffic-eng tunnels | i Src 172.17.0.4, Dst 172.17.0.2, Src 172.17.0.4, Dst 172.17.0.2, Tun_Id 60001, Tun_Instance 167
This output shows the backup tunnel interface in use to protect the link between PE4 and P2. NHOP.
PE-4# sh mpl traffic-eng tunnels tunnel 3 protection PE-4_t3 LSP Head, Tunnel3, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 7463 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu60002 to LSP nnhop Tu60002: out i/f: Se1/0, label: 57 LSP signalling info: Original: out i/f: Se0/0, label: 48, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60002, label: 50 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None
This is a node protection (NNHOP). The node protected here is P2 (as the next hop is P3). Look in the previous output to understand why P2 is the node protected.
This backup tunnel is a node protection (nnhop).

PE-4# sh mpl traffic-eng tunnels tunnel 60002 | i Path|Explicit Route Admin: up RSVP Path Info: Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2 Shortest Unconstrained Path Info: Path Weight: 20 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3 Oper: up Path: valid Signalling: connected Active Path Option Parameters:
July 10
Verify the Path used for this backup tunnel: PE4 PE5 P31 P32 PE7 PE6. Node Protected for this tunnel PE-4 T60002
PE4 P2
P1
Next-Next -Hop
P3 PE6
P30
PE5
P31
P32
PE7
Is this path expected? Why the cSPF algorithm chose this path? Lets check the ISIS metric for this path.
PE-4# sh cln int | i Serial|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: PE-4.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 640, Priority: 64, Circuit ID: PE-4.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up PE-5# sh cln int | i (line protocol|Metric) Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: PE-5.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 640, Priority: 64, Circuit ID: PE-5.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up Auto-Template1 is up, line protocol is up Loopback0 is up, line protocol is up Loopback1 is up, line protocol is up Tunnel1 is up, line protocol is up Tunnel2 is up, line protocol is up Tunnel3 is up, line protocol is up Tunnel60000 is up, line protocol is up Tunnel60001 is up, line protocol is up Tunnel60002 is up, line protocol is up Tunnel60003 is up, line protocol is up P31# sh cln int | i line protocol|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P31.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P31.01 Level-2 IPv6 Metric: 10 July 10
Serial2/0 is up, line protocol is up Level-2 Metric: 1000, Priority: 64, Circuit ID: P31.02 Level-2 IPv6 Metric: 10 Serial3/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P31.03 Level-2 IPv6 Metric: 10 Serial4/0 is up, line protocol is down Level-2 Metric: 10, Priority: 64, Circuit ID: P31.04 Level-2 IPv6 Metric: 10 Loopback0 is up, line protocol is up Tunnel60000 is up, line protocol is up Tunnel60001 is up, line protocol is up Tunnel60002 is up, line protocol is up Tunnel60003 is up, line protocol is up P32#sh cln int | i line protocol|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P32.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P32.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up Level-2 Metric: 1000, Priority: 64, Circuit ID: P32.02 Level-2 IPv6 Metric: 10 Serial3/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: P32.03 Level-2 IPv6 Metric: 10 Serial4/0 is up, line protocol is down Loopback0 is up, line protocol is up Tunnel60000 is up, line protocol is up . . . [ output omitted ] PE-7# sh cln int | i line protocol|Metric Serial0/0 is up, line protocol is up Level-2 Metric: 10, Priority: 64, Circuit ID: PE-7.00 Level-2 IPv6 Metric: 10 Serial1/0 is up, line protocol is up Level-2 Metric: 640, Priority: 64, Circuit ID: PE-7.01 Level-2 IPv6 Metric: 10 Serial2/0 is up, line protocol is up Auto-Template1 is up, line protocol is up Loopback0 is up, line protocol is up Loopback1 is up, line protocol is up Tunnel1 is up, line protocol is up . . . [ output omitted ]
As you can see this is the shortest path to reach P3 in case P2 failures.
July 10
Step 5.
Identify the backup tunnels, link protect between P2 and P3

P2# sh mpls traffic-eng tunnels backup | i Tunnel|Se1/0 LSP Head, Tunnel60000, Admin: up, Oper: up LSP Head, Tunnel60001, Admin: up, Oper: up LSP Head, Tunnel60002, Admin: up, Oper: up Protected i/fs: Se1/0 LSP Head, Tunnel60003, Admin: up, Oper: up Protected i/fs: Se1/0
Serial1/0 interface is the link between P2 and P3. This output shows two backup tunnel for Serial 1/0 interface. Next command will clarify the type of these backup tunnels (NHOP or NNHOP),
P2# sh mpl traffic-eng tunnels tun 60003 backup P2_t60003 LSP Head, Tunnel60003, Admin: up, Oper: up Src 172.17.0.2, Dest 172.17.0.6, Instance 7498 Fast Reroute Backup Provided: Protected i/fs: Se1/0 Protected lsps: 2 Backup BW: any pool unlimited; inuse: 200 kbps P2# sh mpl traffic-eng tunnels tun 60002 backup P2_t60002 LSP Head, Tunnel60002, Admin: up, Oper: up Src 172.17.0.2, Dest 172.17.0.3, Instance 1 Fast Reroute Backup Provided: Protected i/fs: Se1/0 Protected lsps: 0 Backup BW: any pool unlimited; inuse: 0 kbps
Do the same for the rest of the hops to identify the backup tunnels (link and node protection) along the path from PE4 toward PE7.
Step 6.
After changing the ISIS metrics between rings from 1000 to 600 (among Ps only)
PE-4# sh mpl traffic auto-tunn mesh | i 172.17.0.7 172.17.0.7 Tunnel3
This output confirm primary tunnel which is being used to reach 172.17.0.7.
PE-4# sh mpl traffic-eng tunnels tunnel 3 | b Explicit Route Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 Record Route: NONE Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(65) 172.17.0.3(55) 172.17.0.32(67) 172.17.0.7(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 . . . [ output omitted ]
July 10
Checking in the diagram in this route the expect path: PE4 P2 P3 P32 PE7. Head End
P1
PE4
P2
P3
PE6
Middle Point Points
P30
Tail End
PE5
P31
P32
PE7
PE-4# sh mpl traffic-eng tunnels tu3 protect PE-4_t3 LSP Head, Tunnel3, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 7483 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu60002 to LSP nnhop Tu60002: out i/f: Se1/0, label: 46 LSP signalling info: Original: out i/f: Se0/0, label: 65, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60002, label: 55 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None PE-4# sh mpl traffic tunnel tu60002 | b Explicit Route Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.32.1 172.17.0.3 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits . . . [ output omitted ]
This tunnel is a Node protection.
Checking in the diagram in this route the expect path: PE4 PE5 P31 P32 P3. Node Protected for this tunnel PE-4 T60002
PE4 P2 P1
Next-Next -Hop
P3 PE6
P30
PE5
P31
P32
PE7
July 10
PE-4# sh mpl traffic-eng tunnels backup | i Tunnel|172.17.0.2 LSP Head, Tunnel60000, Admin: up, Oper: up LSP Head, Tunnel60001, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.2, Instance 186 LSP Head, Tunnel60002, Admin: up, Oper: up LSP Head, Tunnel60003, Admin: up, Oper: up LSP Head, Tunnel60004, Admin: up, Oper: up
This filter on the command shows straight way what is the backup tunnel for the link between PE4 and P2. To identify you should have Destination IP address P2s loopback, which means NHOP tunnel.
PE-4# sh mpl traffic tunnel tu60001 | b Explicit Route Explicit Route: 172.19.45.2 172.19.53.9 172.19.31.1 172.17.0.2 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 10 (TE) Explicit Route: 172.19.24.1 172.17.0.2 . . . [ output omitted ]
Checking in the diagram in this route the expect path: PE4 PE5 P31 P2. Link Protected Next-Hop
P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
July 10
RSVP bandwidth
PE-4# sh ip int bri Interface Protocol Serial0/0 Serial1/0 Serial2/0 Auto-Template1 Loopback0 Loopback1 Tunnel1 Tunnel2 Tunnel3 Tunnel60000 Tunnel60001 Tunnel60002 Tunnel60003 PE-4# sh mpl tra tu tu2 Name: PE-4_t2 Status: IP-Address 172.19.24.2 172.19.45.1 10.40.31.5 172.17.0.4 172.17.0.4 4.4.4.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 OK? Method Status YES NVRAM YES NVRAM YES NVRAM YES unset YES NVRAM YES NVRAM YES unset YES unset YES unset YES unset YES unset YES unset YES unset up up up up up up up up up up up up up up up up up up up up down up up up up up
(Tunnel2) Destination: 172.17.0.6
Admin: up
Oper: down Path: valid
Signalling: RSVP signalling proceeding
path option 1, type dynamic (Basis for Setup, path weight 40) Status changed Config Parameters: after reducing Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF bandwidth Metric Type: TE (default) availablility in AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based the path. auto-bw: (86400/46462) 0 Bandwidth Requested: 100 Before, P2 was Active Path Option Parameters: allocating State: dynamic path option 1 is active bandwidth for BandwidthOverride: disabled LockDown: disabled Verbatim: disabled tunnels: two RSVP Signalling Info: PE4-PE7 and Src 172.17.0.4, Dst 172.17.0.6, Tun_Id 2, Tun_Instance 6753 PE4-PE7. Shortest Unconstrained Path Info: Now P2 has Path Weight: 30 (TE) capacity only for Explicit Route: 172.19.24.1 172.19.23.2 172.16.36.2 172.17.0.6 one tunnel. So, one of the History: tunnels went Tunnel: down. Time since created: 13 hours, 29 minutes Time since path change: 1 minutes, 18 seconds Number of LSP IDs (Tun_Instances) used: 29 Current LSP: Setup Time: 3 minutes, 41 seconds remaining Prior LSP: ID: path option 1 [6752] Removal Trigger: path error
July 10
We can manually force the router recalculates all constraint path. We DO NOT recommend using this command in life network, especially in critical hours. This makes all primary tunnels go down for a couple a minutes.
PE-4# clear mpls traffic-eng auto-tunnel mesh PE-4# sh ip int bri Interface Protocol Serial0/0 Serial1/0 Serial2/0 Auto-Template1 Loopback0 Loopback1 Tunnel1 Tunnel2 Tunnel3 Tunnel60000 Tunnel60001 Tunnel60002 Tunnel60003 IP-Address 172.19.24.2 172.19.45.1 10.40.31.5 172.17.0.4 172.17.0.4 4.4.4.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 OK? Method Status YES NVRAM YES NVRAM YES NVRAM YES unset YES NVRAM YES NVRAM YES unset YES unset YES unset YES unset YES unset YES unset YES unset up up up up up up up up up up up up up up up up up up up up up down up up up up
After a couple of seconds the Tunnel 3 is still down. Lets check the tunnel status.
PE-4# sh mpl tra tu t3 Name: PE-4_t3 Status:
(Tunnel3) Destination: 172.17.0.7
Admin: up
Oper: down Path: valid
Signalling: RSVP signalling proceeding
path option 1, type dynamic (Basis for Setup, path weight 670) It is trying to Config Parameters: find a Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF path of this tunnel. Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86384) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2198 Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 11 seconds Number of LSP IDs (Tun_Instances) used: 1 Current LSP: Setup Time: 4 minutes, 48 seconds remaining
After a minute later the Tunnel 3 is up.
July 10
PE-4# sh mpl tra tu t3 Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 680) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/67664) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : Serial1/0, 55 FRR OutLabel : Tunnel60004, 52 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2204 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.9 172.16.130.1 172.16.132.2 172.19.137.2 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(55) 172.19.53.10(55) 172.17.0.31(52) 172.16.130.2(52) 172.17.0.30(50) 172.16.132.1(50) 172.17.0.32(48) 172.19.137.1(48) 172.17.0.7(0) 172.19.137.2(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 5 hours, 13 minutes Time since path change: 6 seconds Number of LSP IDs (Tun_Instances) used: 7 Current LSP: Uptime: 6 seconds Selection: reoptimization Prior LSP: ID: path option 1 [2198] Removal Trigger: path error
Checking the next path: PE4 PE5 P31 P30 P32 P7

P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
July 10
Lets check the RSVP status in P2 and P31.

P2# sh ip rsvp int interface rsvp Se0/0 ena Se1/0 ena Se2/0 ena Se3/0 ena Tu60000 ena Tu60001 ena Tu60002 ena Tu60003 ena Tu60004 ena Tu60005 ena Tu60006 ena allocated 0 100K 100K 300K 0 0 0 0 0 0 0 i/f max 0 100K 100K 155M 0 0 0 0 0 0 0 flow max sub max 0 0 100K 0 100K 0 155M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
S0/0 does NOT have bandwidth for RSVP reservation. S1/0 and S2/0 have full filled all bandwidth capacity for RSVP. So, there is not a bandwidth capacity available for RSVP reservation when tunnel 3 has requested. S0/0 connects to P1 which does not have RSVP enabled. S1/0 connects to P3 and has 100k bandwidth allocated. S2/0 connects to P31 and has 100k bandwidth allocated.
P2# sh ip rsvp installed RSVP: Serial0/0 has no installed reservations RSVP: Serial1/0 BPS To From Protoc 0 172.17.0.3 172.17.0.1 0 0 172.17.0.3 172.17.0.31 0 100K 172.17.0.6 172.17.0.4 0 0 172.17.0.7 172.17.0.31 0 0 172.17.0.32 172.17.0.5 0 RSVP: Serial2/0 BPS To From Protoc 0 172.17.0.4 172.17.0.2 0 100K 172.17.0.5 172.17.0.6 0 0 172.17.0.5 172.17.0.4 0 0 172.17.0.5 172.17.0.2 0 0 172.17.0.6 172.17.0.2 0 0 172.17.0.31 172.17.0.5 0 0 172.17.0.31 172.17.0.4 0 0 172.17.0.31 172.17.0.7 0 0 172.17.0.32 172.17.0.2 0 RSVP: Serial3/0 BPS To From Protoc 100K 172.17.0.4 172.17.0.5 0 100K 172.17.0.4 172.17.0.6 0 100K 172.17.0.4 172.17.0.7 0 0 172.17.0.4 172.17.0.5 0 0 172.17.0.5 172.17.0.31 0 . . . [ output omitted ] P31# sh ip rsvp int interface rsvp allocated Se0/0 ena 300K Se1/0 ena 0 Se2/0 ena 200K Se3/0 ena 200K . . . [ output omitted ]
DPort 60000 60005 2 60004 60004 DPort 60000 3 60000 60001 60003 60002 60004 60004 60006 DPort 1 2 2 60000 60000
Sport 1 1 8822 1 1 Sport 1 9469 20 1 2249 1 1 1 2141 Sport 3666 514 5455 27 1
i/f max 155M 0 155M 155M
flow max sub max 155M 0 0 0 155M 0 155M 0
Then, S0/0 interface which connects to P30 is the best option. RSVP is not enabled in S1/0 interface which connects to P32.
P31 has the same limitation, S1/0 interface has not RSVP enable. After correct the RSVP in P2 and P31. Only after the optimization timer has expired, an new path was estabilished. The new Path is PE4 P2 P3 P32 PE7
July 10
PE-4# sh mpls traff tu tu3 Name: PE-4_t3 (Tunnel3) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 630) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/64526) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : Serial0/0, 50 FRR OutLabel : Tunnel60002, 42 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2206 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(50) 172.19.23.1(50) 172.17.0.3(42) 172.19.32.1(42) 172.17.0.32(50) 172.19.137.1(50) 172.17.0.7(0) 172.19.137.2(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 630 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 6 hours, 5 minutes Time since path change: 1 minutes, 38 seconds Number of LSP IDs (Tun_Instances) used: 11 Current LSP: Uptime: 1 minutes, 41 seconds Selection: reoptimization Prior LSP: ID: path option 1 [2204] Removal Trigger: reoptimization completed
P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
July 10
ISIS disabled for TE

PE-4# sh mpl tra tu tu3 Name: PE-4_t3 (Tunnel3) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 670) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/63952) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : OutLabel : Serial1/0, 53 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 3, Tun_Instance 2217 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(53) 172.19.53.10(53) 172.17.0.31(41) 172.19.131.1(41) 172.17.0.32(53) 172.19.137.1(53) 172.17.0.7(0) 172.19.137.2(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 670 (TE) Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2 172.17.0.7 History: Tunnel: Time since created: 6 hours, 15 minutes Look at this time, the Time since path change: 54 seconds unconstrained Path Number of LSP IDs (Tun_Instances) used: 21 Info does NOT show Current LSP: the path we would Uptime: 57 seconds expect either. This Selection: reoptimization could be a sign at least Prior LSP: one of the routers in ID: path option 1 [2206] the BEST path has not Removal Trigger: re-route path verification failed ISIS enabled for TE.
Again, the Tunnel 3 is not using the best path we would expect.
July 10
Lets check the status in P2.

P2# sh ip rsvp int interface rsvp Se0/0 ena Se1/0 ena Se2/0 ena Se3/0 ena Tu60000 ena Tu60001 ena Tu60002 ena Tu60003 ena Tu60004 ena Tu60005 ena Tu60006 ena allocated 0 0 0 0 0 0 0 0 0 0 0 i/f max 155M 155M 155M 155M 0 0 0 0 0 0 0 flow max sub max 155M 0 155M 0 155M 0 155M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
P2# sh isis mpls traffic-eng advertisements System ID: P2.00 Router ID: 172.17.0.2 Link Count: 0
There is not constraint link, and then ISIS is not enabled for MPLS/TE in backbone area (level-2 links). Re-enable ISIS level-2 for MPLS/TE the tunnel 3 path will be changed after the next reoptimisation.
MPLS TE is disabled
Another reason interface tunnel 3 is not using P2 as a path could be MPLS/TE is not enabled in P2. In case you should get the following outputs.
P2# sh mpl int Interface Serial0/0 Serial1/0 Serial2/0 Serial3/0 IP Yes Yes Yes Yes Tunnel Yes Yes Yes Yes Operational Yes Yes Yes Yes
(ldp) (ldp) (ldp) (ldp)
This command do not show if MPLS/TE is enabled or not.
This message indicates
that mpls traffic-eng P2# sh mpl traffic-eng tunnels summary global command is not Signalling Summary: enabled in this router. LSP Tunnels Process: not running, disabled RSVP Process: running Forwarding: enabled Head: 7 interfaces, 0 active signalling attempts, 0 established 22 activations, 22 deactivations Midpoints: 0, Tails: 0 auto-tunnel: backup Enabled (7 ), id-range:60000-64000 onehop Disabled (0 ), id-range:65336-65435 mesh Enabled (0 ), id-range:1-999 . . . [ output omitted ] As MPLS traffic-eng is not enabled globally, the ISIS will NOT be to create the constraint links.
P2# sh isis mpl traffic-eng advertisements System ID: P2.00 Router ID: 172.17.0.2 Link Count: 0
July 10
Some MPLS and MPLS/VPN issues

CEF disabled Labels will be not allocated
Symptoms: CE traffic will be droped when reach P router as it will be not labelled and P will not have any information about CE prefixes. You will be enabled to see all ldp outputs including LIB, but you will not see anything in LFIB due to it needs CEF enabled.
PE-4# sh mpl ldp bindings tib entry: 172.16.18.0/30, rev 64 remote binding: tsr: 172.17.0.2:0, remote binding: tsr: 172.17.0.5:0, tib entry: 172.16.36.0/30, rev 65 remote binding: tsr: 172.17.0.2:0, remote binding: tsr: 172.17.0.5:0, tib entry: 172.16.67.0/30, rev 66 remote binding: tsr: 172.17.0.5:0, remote binding: tsr: 172.17.0.2:0, tib entry: 172.17.0.3/32, rev 71 remote binding: tsr: 172.17.0.2:0, . . . [ output omitted ]
tag: 28 tag: 40 tag: 18 tag: 38 tag: 41 tag: 38 tag: 16
PE-4# sh mpl forwarding-table Tag switching is not operational. CEF or tag switching has not been enabled. Local Outgoing Prefix Bytes tag tag tag or VC or Tunnel Id switched PE-4# sh cef int CEF not running
Outgoing interface
Next Hop
Issues with LDP adjacency

Possible cause: LDP-id is not been propagated via IGP, if LDP-id is configured to use loopback address. Neighbor does not have LDP enabled. ACL applied on interface which denies LDP packets (LDP uses TCP and UDP).
PE-4# sh mpl int Interface Serial0/0 Serial1/0 IP Yes (ldp) Yes (ldp) Tunnel Yes Yes Operational Yes Yes
PE-4# sh mpl ldp discovery Local LDP Identifier: 172.17.0.4:0 Discovery Sources: Interfaces: Serial0/0 (ldp): xmit/recv LDP Id: 172.17.0.2:0 Serial1/0 (ldp): xmit July 10
No LDP received on Serial 1/0 interface
CE prefixes are in FIB vrf but not in BGP vrf database

Possible cause: CE-PE routing prefixes are not redistributed under BGP address-family vrf.
PE-4# sh ip route vrf VPN ospf Routing Table: VPN 172.17.0.0/32 is subnetted, 4 subnets 172.17.8.84 [110/97] via 10.40.31.6, 00:00:09, Serial2/0 172.17.8.83 [110/49] via 10.40.31.6, 00:00:09, Serial2/0 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks O 10.40.31.0/30 [110/96] via 10.40.31.6, 00:00:09, Serial2/0 PE-4# PE-4# sh ip bgp vpn vrf VPN 172.17.8.84 % Network not in table PE-4# PE-4# sh ip bgp vpn vrf VPN 172.17.8.83 % Network not in table PE-4# PE-4# sh ip bgp vpn vrf VPN 10.40.31.0 % Network not in table O O
Remote CE prefixes are not received

Symptoms: Prefixes maybe in Generic BGP database, however they are not in BGP vrf database. Possible cause: The vrf is not importing the right RT.
PE-4# sh ip route vrf VPN Routing Table: VPN Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR Gateway of last resort is not set 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 is directly connected, Loopback1 172.17.0.0/32 is subnetted, 2 subnets 172.17.8.84 [110/97] via 10.40.31.6, 00:04:26, Serial2/0 172.17.8.83 [110/49] via 10.40.31.6, 00:04:26, Serial2/0 10.0.0.0/30 is subnetted, 2 subnets 10.40.31.4 is directly connected, Serial2/0 10.40.31.0 [110/96] via 10.40.31.6, 00:04:26, Serial2/0
C O O C O
July 10
PE-4# sh ip bgp vpn vrf VPN BGP table version is 527, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 25135:133001804 (default for vrf VPN) *> 4.4.4.4/32 0.0.0.0 100 32768 i *> 10.40.31.0/30 10.40.31.6 96 32768 ? *> 10.40.31.4/30 0.0.0.0 0 32768 ? *> 172.17.8.83/32 10.40.31.6 49 32768 ? *> 172.17.8.84/32 10.40.31.6 97 32768 ? PE-4# sh ip bgp vpn all BGP table version is 886, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Route Distinguisher: 0:0 *> 4.4.4.4/32 0.0.0.0 *>i5.5.5.5/32 172.17.0.5 *>i6.6.6.6/32 172.17.0.6 *>i7.7.7.7/32 172.17.0.7 *>i10.33.31.0/30 172.17.0.6 * i 172.17.0.7 *>i10.33.31.0/24 172.17.0.7 *>i10.33.31.4/30 172.17.0.6 * i 172.17.0.7 . . . [ output omitted ] Metric LocPrf Weight Path 100 100 100 100 96 96 0 0 144 32768 0 0 0 0 0 0 0 0 i i i i ? ? 1 i ? ?
100 100 100 100 100 100 100 100
PE-4# sh run | i ip vrf|^ route-target import|^ import-map ip vrf IMCH Neither route-target import ip vrf VPN nor import-map ip vrf rrr route-target import 212.183.144.1:18 Because there is at least a vrf importing ip vrf forwarding VPN 212.182.144.1:18 route-target, we can see these ip vrf forwarding VPN PE-4# sh ip bgp vpn all 10.33.31.0 BGP routing table entry for 25135:133001806:10.33.31.0/30, version 1227 Bestpath Modifiers: missing-med-worst, always-compare-med, deterministic-med Paths: (2 available, best #1, no table) Flag: 0x820 Not advertised to any peer Local 172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8) Origin incomplete, metric 96, localpref 100, valid, internal, best Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 Originator: 172.17.0.6, Cluster list: 0.0.0.1, mpls labels in/out nolabel/47 Local
prefixes on global bgp database otherwise the BGP process will drop these prefixes.
July 10
In case there is not any vrf importing this RT it will not be any VPNv4 prefixes BGP global database. In this lab we have only one VRF which is exporting and importing the same route-target: 212.183.144.1:18 and
25135:18. Without any import the BGP global database will be empty even those the RRs are advertising all VPNv4 prefixes. PE-4# sh run | i ip vrf VPN| route-target| e ip vrf forwarding ip vrf VPN route-target export 25135:18 route-target export 212.183.144.1:18 PE-4# sh ip bgp vpn all sum BGP router identifier 172.17.0.4, local AS number 25135 BGP table version is 4018, main routing table version 4018 5 network entries using 665 bytes of memory 5 path entries using 340 bytes of memory 11/5 BGP path/bestpath attribute entries using 1452 bytes of memory 1 BGP rrinfo entries using 24 bytes of memory 3 BGP extended community entries using 144 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 2625 total bytes of memory BGP activity 103/98 prefixes, 257/252 paths, scan interval 15 secs Neighbor State/PfxRcd 172.17.0.8 172.17.0.9 V AS MsgRcvd MsgSent 279840 279840 87206 87206 TblVer 4018 4018 InQ OutQ Up/Down 0 0 0 00:51:02 0 00:51:02 0 0
It did not accept any VPNv4 prefixes. Reasons: There isnt vrf import prefixes which RT value advertised by these neighbours. Or there is a inbound filter denying all prefixes, such as routemap, prefix-list assigned to these neighbours. Or RR is not adversiting prefixes to PE-4.
4 25135 4 25135
PE-4# sh ip bgp vpn all BGP table version is 4018, local router ID is 172.17.0.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 25135:133001804 (default for vrf VPN) *> 4.4.4.4/32 0.0.0.0 100 32768 i *> 10.40.31.0/30 10.40.31.6 96 32768 ? *> 10.40.31.4/30 0.0.0.0 0 32768 ? *> 172.17.8.83/32 10.40.31.6 49 32768 ? *> 172.17.8.84/32 10.40.31.6 97 32768 ?
Local prefixes only: learnt via local CE or genered via local BGP process (next-hop = 0.0.0.0)
RR1# sh ip bgp vpn all nei 172.17.0.4 adv BGP table version is 253918, local router ID is 172.17.0.8 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Route Distinguisher: 25135:133001804 *>i4.4.4.4/32 172.17.0.4 *>i10.40.31.0/30 172.17.0.4 *>i10.40.31.4/30 172.17.0.4 *>i172.17.8.83/32 172.17.0.4 . . . [ output omitted ] July 10
Metric LocPrf Weight Path 100 96 0 49 100 100 100 100 0 0 0 0 i ? ? ?
Route-reflector is not advertising VPNv4 prefixes

Possible cause: Local PE has inbound filtering denying all VPNv4 prefixes. Route-reflector does not have route-reflector-client assigned to the neighbour. Route-reflector is not learning VPNv4 prefixes from other remote PEs.
RR1# sh ip bgp vpn all sum BGP router identifier 172.17.0.8, local AS number 25135 BGP table version is 208, main routing table version 208 19 network entries using 2527 bytes of memory 19 path entries using 1292 bytes of memory 17/16 BGP path/bestpath attribute entries using 2244 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 4 BGP extended community entries using 204 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 6291 total bytes of memory BGP activity 97/78 prefixes, 110/91 paths, scan interval 15 secs Neighbor State/PfxRcd 172.17.0.4 172.17.0.5 172.17.0.6 172.17.0.7 172.17.0.9 RR1# V 4 4 4 4 4 AS MsgRcvd MsgSent 25135 25135 25135 25135 25135 78 87354 92716 92754 281058 278 280837 280837 280837 280857 TblVer 203 203 203 203 208 InQ OutQ Up/Down 0 0 0 0 0 0 0 0 0 0 00:01:46 00:01:47 00:01:45 00:01:49 00:00:15 5 1 6 7 0
Only 172.17.0.9 is configured as routereflector-client. However this neighbour is not adversiting any prefixes to RR1. All other neighbours now are normal iBGP.
RR1# sh ip bgp vpn all n 172.17.0.4 adv Total number of prefixes 0 PE-4# sh ip bgp vpn all sum BGP router identifier 172.17.0.4, local AS number 25135 BGP table version is 4018, main routing table version 4018 5 network entries using 665 bytes of memory 5 path entries using 340 bytes of memory 16/5 BGP path/bestpath attribute entries using 2112 bytes of memory 2 BGP rrinfo entries using 48 bytes of memory No prefixes 4 BGP extended community entries using 204 bytes of memory received/learnt/accept. 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 3369 total bytes of memory BGP activity 103/98 prefixes, 257/252 paths, scan interval 15 secs Neighbor State/PfxRcd 172.17.0.8 172.17.0.9 V AS MsgRcvd MsgSent 280902 281289 87435 87395 TblVer 4018 4018 InQ OutQ Up/Down 0 0 0 00:06:25 0 01:22:39 0 0
4 25135 4 25135
July 10
PE Node Failure
If the destination PE failure the primary tunnel can not be established, then this will affect the services MPLS/VPN and AToM. Status before PE-7 failures: Loopback 0 of CE-4
CE-1# sh ip route 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "ospf 1", distance 110, metric 108, type inter area Last update from 10.40.31.5 on Serial1/0, 00:25:58 ago Routing Descriptor Blocks: * 10.40.31.5, from 4.4.4.4, 00:25:58 ago, via Serial1/0 Route metric is 108, traffic share count is 1 CE-1# trace 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52
Link between PE7 and CE-4

1 2 3 4 5 6 10.40.31.5 20 msec 20 msec 20 msec 172.19.24.1 36 msec 20 msec 20 msec 172.19.23.2 16 msec 32 msec 20 msec 172.19.32.2 16 msec 20 msec 16 msec 10.33.31.9 20 msec 20 msec 20 msec 10.33.31.10 20 msec * 20 msec
PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 BGP next-hop: Known via "bgp 25135", distance 200, metric 49, type internal PE-7 Redistributing via ospf 1 and CE-4 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 00:00:11 ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 00:00:11 ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0
Status as soon as PE7 reloads.

PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 BGP next-hop: Known via "bgp 25135", distance 200, metric 97, type internal PE-6 Redistributing via ospf 1 and CE-4 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.6 00:01:21 ago Routing Descriptor Blocks: * 172.17.0.6 (Default-IP-Routing-Table), from 172.17.0.8, 00:01:21 ago Route metric is 97, traffic share count is 1 AS Hops 0, BGP network version 0
July 10
Tunnel which destines to PE7 is down.

PE-4# sh ip int bri Interface Protocol Serial0/0 Serial1/0 Serial2/0 Auto-Template1 Loopback0 Loopback1 Tunnel1 Tunnel2 Tunnel3 Tunnel60000 Tunnel60001 Tunnel60002 IP-Address 172.19.24.2 172.19.45.1 10.40.31.5 172.17.0.4 172.17.0.4 4.4.4.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 172.17.0.4 OK? Method Status YES YES YES YES YES YES YES YES YES YES YES YES NVRAM NVRAM NVRAM unset NVRAM NVRAM unset unset unset unset unset unset up up up up up up up up up up up up up up up up up up up up down up up up
CE-1# ping Protocol [ip]: Target IP address: 172.17.8.52 Repeat count [5]: 10000 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10000, 100-byte ICMP Echos to 172.17.8.52, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! . . . [ output omitted ] Success rate is 99 percent (9998/10000), round-trip min/avg/max = 8/22/440 ms
Two packets were lost. However in real lab scenario there is not packet loss.
CE-1# sh ip route 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "ospf 1", distance 110, metric 108, type inter area Last update from 10.40.31.5 on Serial1/0, 00:46:40 ago Routing Descriptor Blocks: * 10.40.31.5, from 4.4.4.4, 00:46:40 ago, via Serial1/0 Route metric is 108, traffic share count is 1
From CE-1 perspective, there is no change of on the prefix (metric and neighbour).
PE-CE Link Failure

This case is the same as PE Node failure affecting the services directly: MPLS/VPN and AToM.
July 10
RR Node Failure
This case of failure will not affect TE as the Destination tunnel IP addresses are learnt via ISIS. Status before RR failure:
PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "bgp 25135", distance 200, metric 49, type internal Redistributing via ospf 1 RR1 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 00:01:16 ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 00:01:16 ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0 PE-4# trace vrf VPN 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52 1 172.19.24.1 [MPLS: Labels 55/34 Exp 0] 48 2 172.19.23.2 [MPLS: Labels 53/34 Exp 0] 28 3 172.19.32.2 [MPLS: Labels 48/34 Exp 0] 32 4 10.33.31.9 [MPLS: Label 34 Exp 0] 28 msec 5 10.33.31.10 44 msec * 48 msec
msec 32 msec 28 msec 32 28 msec
msec 52 msec msec 48 msec msec 32 msec 32 msec
Status as soon as RR failure:

PE-4# traceroute vrf VPN 172.17.8.52 Type escape sequence to abort. Tracing the route to 172.17.8.52 1 172.19.24.1 [MPLS: Labels 55/34 Exp 0] 20 2 172.19.23.2 [MPLS: Labels 53/34 Exp 0] 28 3 172.19.32.2 [MPLS: Labels 48/34 Exp 0] 28 4 10.33.31.9 [MPLS: Label 34 Exp 0] 24 msec 5 10.33.31.10 20 msec * 28 msec
Path did not change after RR failure
msec 32 msec 28 msec 56 20 msec
msec 28 msec msec 20 msec msec 20 msec 44 msec
PE-4# sh ip route vrf VPN 172.17.8.52 Routing entry for 172.17.8.52/32 Known via "bgp 25135", distance 200, metric 49, type internal Redistributing via ospf 1 RR2 Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn Last update from 172.17.0.7 00:00:42 ago Routing Descriptor Blocks: * 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.9, 00:00:42 ago Route metric is 49, traffic share count is 1 AS Hops 0, BGP network version 0
RR is not in data path. Control plane database replaces the BGP prefixes using the backup information already in BGP vrf database (due to maximum-path import 8 command, prefixes learnt via other routereflector will be in BGP vrf database).
PE-4# ping vrf VPN Protocol [ip]: Target IP address: 172.17.8.52 Repeat count [5]: 10000 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10000, 100-byte ICMP Echos to 172.17.8.52, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! . . . [ output omitted ]
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 20/33/48 ms

July 10
The following failure scenarios were created based on lab topology as per Figure 12 in page 140.
Link Failure
Checking the status before failures:
PE4-PEXKS01#sh mpls traffic-en auto-tunnel mesh | i 172.17.0.7 172.17.0.7 Tunnel2
In this case, the primary tunnel from PE4 to PE7 is tunnel 2.

PE4-PEXKS01# sh mpl traffic-eng tun tun 2 Tunnel Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Operational Time source is NTP, 11:53:53.019 GMT Fri Mar 2 2007 and Path Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Valid Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/84510) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 82 Path: PE4 P2P3P32PE7 FRR OutLabel : Tunnel60006, 112 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3069 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(82) 172.19.23.1(82) Check these labels with trace mpls traffic-eng 172.17.0.3(112) 172.19.32.1(112) command. 172.17.0.32(112) 172.19.137.2(112) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 24 minutes Time since path change: 27 minutes, 56 seconds Number of LSP IDs (Tun_Instances) used: 2831 Current LSP: Uptime: 27 minutes, 56 seconds Prior LSP: ID: path option 1 [3062] Removal Trigger: path option updated
July 10
Verifying the data path:

PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M' success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 82 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 112 Exp: 0] 3 ms R 2 172.19.23.2 MRU 4470 [Labels: 112 Exp: 0] 4 ms R 3 172.19.32.2 MRU 4474 [implicit-null] 5 ms ! 4 172.19.137.1 2 ms
Check the labels are the same as describe in the output of previous command (show mpls traff tu tu2). Checking these labels in other routers along this path:
P2# sh mpl forw | i 82 66 40 172.17.0.53/32 9827251 Gi2/0/4 172.19.31.2 82 112 172.17.0.4 2 [3069] 92245 Gi3/0/0 172.19.23.2 84 82 172.17.0.31 60000 [5530] 0 Gi2/0/2 172.19.24.2 89 106 172.17.0.6 2 [6278] 28118225 Gi2/0/4 172.19.31.2
The labelled packet comes from PE4 which uses tunnel2 (PE4 primary tunnel toward to PE7) should use label 82. Then based on this information we are checking which label will be used to forward the packet to the next hop.
P3# sh mpl forw | i 112 49 45 10.59.27.112/30 0 112 112 172.17.0.4 2 [3069] 96047 P32> sh mpl forw | i 112 61 49 10.59.27.112/30 0 58 10.59.27.112/30 0 112 Pop tag 172.17.0.4 2 [3069] 106274 Gi3/0/0 Gi2/0/4 172.19.23.1 172.19.32.2
By coincidence in P3 the incoming label is the same as outgoing label.

Gi3/0 PO2/0 Gi3/2 172.19.32.1 point2point 172.19.137.1
Due to P32 is a Penultimate Hop Popping (PHP) from this point toward to PE7, the packet which belongs to PE4-tunnel 2 will not have MPLS/TE label.
PE4-PEXKS01# sh mpl traff tun tu 2 protection Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 11:58:21.219 GMT Fri Mar 2 2007 PE4-PEXKS01_t2 LSP Head, Tunnel2, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 3069 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu60006 to LSP nnhop Tu60006: out i/f: Gi3/3, label: 249 LSP signalling info: Tail-end for this backup tunnel (2 Original: out i/f: Gi3/2, label: 82, nhop: 172.19.24.1 hops way from nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 PE4) With FRR: out i/f: Tu60006, label: 112 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None
Tunnel 60006 is the backup tunnel for PE4-tunnel 2 in case of P2-node failure and also in case of link failure between PE4 and P2.
July 10
PE4-PEXKS01# sh mpl traf tu tu 60006 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 11:59:45.383 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t60006 (Tunnel60006) Destination: 172.17.0.3 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type explicit __dynamic_tunnel60006 (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based auto-bw: disabled Active Path Option Parameters: State: explicit path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/3, 249 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.3, Tun_Id 60006, Tun_Instance 1 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.32.1 172.17.0.3 Record Route: NONE Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits RSVP Resv Info: Record Route: NONE Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits Shortest Unconstrained Path Info: Path Weight: 680 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3 History: Tunnel: Time since created: 37 minutes, 37 seconds Time since path change: 37 minutes, 11 seconds Number of LSP IDs (Tun_Instances) used: 1 Current LSP: Uptime: 37 minutes, 11 seconds
Backup tunnel path: PE4 PE4 P31 P32 P3 Checking in the diagram in this route the expect path: PE4 PE5 P31 P32 P3. Node Protected for this tunnel PE-4 T60006
PE4 P2 P1
Next-Next -Hop
P3 PE6
P30
PE5
P31
P32
PE7
July 10
Link failure between P2 and PE4:
2nd checking: Status did NOT change!
PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 1%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 12:05:02.097 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF 4th checking: In back ground it is Metric Type: TE (default) being calculated the new path for path option 1 reoptimization in progress Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/83841) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
st
primary tunnel. This occurs due to the dynamic path configuration and reoptimaztion path Affinity: 0x0/0xFFFF being enabled.
1 checking: Backup InLabel : tunnel in used. Check OutLabel : GigabitEthernet3/2, 82 the trace mpls FRR OutLabel : Tunnel60006, 112 (in use) command output in the RSVP Signalling Info: next path. Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3069 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: 3rd checking: Check the Record Route: 172.17.0.2(82) 172.19.23.1(82) primary tunnel path did NOT 172.17.0.3(112) 172.19.32.1(112) change even though the link 172.17.0.32(112) 172.19.137.2(112) PE4 P2 is down. 172.17.0.7(0) 172.19.137.1(0) When the backup tunnel is in Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbitscan NOT check the used we Shortest Unconstrained Path Info: full path in only one show Path Weight: 1960 (TE) command. Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 36 minutes Time since path change: 39 minutes, 4 seconds Number of LSP IDs (Tun_Instances) used: 2853 Current LSP: Uptime: 39 minutes, 4 seconds Reopt. LSP: Uptime: 1 seconds Prior LSP: ID: path option 1 [3062] Removal Trigger: path option updated
July 10
PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds
The backupCodes: tunnel label is the top of label stack.
'!' '.' 'R' 'M'
success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
Type escape sequence to abort. 0 172.19.45.1 MRU 4466 [Labels: 249/112 Exp: 0/0] U 1 172.19.45.2 MRU 4470 [Labels: 117/112 Exp: 0/0] 5 ms U 2 172.19.53.10 MRU 4470 [Labels: 110/112 Exp: 0/0] 2 ms R 3 172.16.131.2 MRU 4474 [Labels: 112 Exp: 0] 3 ms R 4 172.19.32.1 MRU 4470 [Labels: 112 Exp: 0] 3 ms R 5 172.19.32.2 MRU 4474 [implicit-null] 4 ms ! 6 172.19.137.1 5 ms
These 4 112 value are the same. It is in the bottom of the label stack. It is being encapsulated into backup tunnel.
P3 node
The path is: PE4 PE5 P31 P32 P3 P32 PE7 Why the packet passed P32 P3 link twice?
P1
Next-Next -Hop
PE4 P2 P3 PE6
P30
PE5
P31
P32
PE7
The final destination of backup tunnel is P3. So, P3 is the rendezvous point between backup tunnel and the original path of primary tunnel after the failure. A couple of seconds later the primary tunnel has the new path.
The path is PE4 PE5 P31 P32 PE7. As you have checked, P3 is not longer a hop for the PE4-tunnel2. Lets check the new information of PE4-tunnel 2 information.
July 10
PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 12:06:33.772 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1960) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Tunnel NEVER Metric Type: TE (default) went down. AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/83749) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/3, 25 New path RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3148 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits New LSP labels RSVP Resv Info: Check with Record Route: 172.17.0.5(25) 172.19.53.9(25) previous 172.17.0.31(81) 172.16.131.1(81) command (trace 172.17.0.32(86) 172.19.137.2(86) mpls traffic172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits eng). Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Tunnel NEVER Time since created: 23 hours, 37 minutes went down. Time since path change: 1 minutes, 29 seconds These figures can prove only Number of LSP IDs (Tun_Instances) used: 2856 the path has Current LSP: changed. Uptime: 1 minutes, 32 seconds Selection: reoptimization Prior LSP: ID: path option 1 [3069]
Removal Trigger: re-route path error

P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
July 10
Link failure between P2 and P3

PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 12:27:15.007 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF In back ground it is being Metric Type: TE (default) calculated the new path for path option 1 reoptimization in progress primary tunnel. Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/82508) 1418 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 124 No information this FRR OutLabel : Tunnel60006, 108 backup tunnel being in RSVP Signalling Info: used. Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3158 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(124) 172.19.23.1(124) 172.17.0.3(108) 172.19.32.1(108) 172.17.0.32(96) 172.19.137.2(96) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 58 minutes Time since path change: 16 minutes, 59 seconds Number of LSP IDs (Tun_Instances) used: 2897 Current LSP: Uptime: 17 minutes, 2 seconds Selection: reoptimization Reopt. LSP: Setup Time: 4 minutes, 55 seconds remaining Prior LSP: ID: path option 1 [3148] Removal Trigger: reoptimization completed July 10
PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M' success, 'Q' - request not transmitted, timeout, 'U' - unreachable, The backup tunnel label downstream router but not target, is the top of label stack. malformed request
Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 124 Exp: 0] R 1 172.19.24.1 MRU 4466 [Labels: 84/96 Exp: 0/0] 4 ms U 2 172.19.31.2 MRU 4474 [Labels: 96 Exp: 0] 1 ms R 3 172.16.131.2 MRU 4474 [implicit-null] 2 ms ! 4 172.19.137.1 3 ms
P31 is PHP, so it is being removed the backup label of label stack.
The backup tunnel activated here is P3-node protection. The rendezvous point between primary and backup tunnels is P32. Why the packet didnt pass P32 P3 link twice?
P1
Node protected.
P3 PE6
PE4
P2
P30
PE5
P31
P32
PE7
The rendezvous point between primary and backup tunnels is P32. After the path re-calculation . . . Note the path is the same, however there is only one label per hop.
Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 91 Exp: R 1 172.19.24.1 MRU 4470 [Labels: 91 Exp: R 2 172.19.31.2 MRU 4470 [Labels: 94 Exp: R 3 172.16.131.2 MRU 4474 [implicit-null] ! 4 172.19.137.1 3 ms
P1
0] 0] 4 ms 0] 1 ms 2 ms
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
July 10
PE4-PEXKS01# sh mpl traff tun tu 2 Load for five secs: 0%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 12:28:08.869 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/82454) 1418 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 91 FRR OutLabel : Tunnel60007, 91 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3192 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(91) 172.19.31.1(91) 172.17.0.31(91) 172.16.131.1(91) New Path information 172.17.0.32(94) 172.19.137.2(94) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 23 hours, 59 minutes Time since path change: 35 seconds Number of LSP IDs (Tun_Instances) used: 2898 Current LSP: Uptime: 38 seconds Selection: reoptimization Prior LSP: ID: path option 1 [3158] Removal Trigger: re-route path error
July 10

Before link failure:
PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 141 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 142 Exp: 0] 4 ms R 2 172.19.23.2 MRU 4470 [Labels: 112 Exp: 0] 1 ms R 3 172.19.32.2 MRU 4474 [implicit-null] 2 ms ! 4 172.19.137.1 3 ms
PE4 P2 P3 P32 PE7 After link failure:

PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request Because P32 is the last Type escape sequence to abort. node to reach PE7 for the 0 172.19.24.2 MRU 4470 [Labels: 141 Exp: 0] primary tunnel, we do R 1 172.19.24.1 MRU 4470 [Labels: 142 Exp: 0] 4 ms NOT see two labels in R 2 172.19.23.2 MRU 4470 [Labels: 102 Exp: 0] 2 ms label stack. U 3 172.16.36.2 MRU 4474 [implicit-null] 3 ms ! 4 172.16.67.2 4 ms
P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
After reoptimisation:
PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' - success, 'Q' - request not transmitted, '.' - timeout, 'U' - unreachable, 'R' - downstream router but not target, 'M' - malformed request New Path PE4 P2 P31 P32 PE7 Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 100 Exp: 0] R 1 172.19.24.1 MRU 4470 [Labels: 97 Exp: 0] 1 ms R 2 172.19.31.2 MRU 4470 [Labels: 94 Exp: 0] 2 ms R 3 172.16.131.2 MRU 4474 [implicit-null] 3 ms ! 4 172.19.137.1 4 ms July 10
PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 1%/0%; one minute: 1%; five minutes: 1% Time source is NTP, 12:52:50.286 GMT Fri Mar 2 2007
Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86072) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : OutLabel : GigabitEthernet3/2, 141 FRR OutLabel : Tunnel60006, 142 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3240 RSVP Path Info: My Address: 172.17.0.4 LSP labels before link Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 failure. The same result 172.17.0.7 as the first trace mpls traffic-eng output in the Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100previous page. kbits RSVP Resv Info: Record Route: 172.17.0.2(141) 172.19.23.1(141) 172.17.0.3(142) 172.19.32.1(142) 172.17.0.32(112) 172.19.137.2(112) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 23 minutes Time since path change: 1 minutes, 49 seconds Number of LSP IDs (Tun_Instances) used: 2949 Current LSP: Uptime: 1 minutes, 49 seconds Prior LSP: ID: path option 1 [3238] Removal Trigger: path option updated
The primary tunnel details before link failure.
July 10
Output during new path calculation, meanwhile the backup tunnel is be used:
PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:07:29.591 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) path option 1 reoptimization in progress . . . [ output omitted ]
As soon as the new path was defined:

PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:07:51.831 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) path option 1, delayed clean in progress Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/85170) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 100 FRR OutLabel : Tunnel60007, 97 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3275 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 LSP labels new path Record Route: calculation due to link Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits The same result failure. RSVP Resv Info: as the third trace mpls Record Route: 172.17.0.2(100) 172.19.31.1(100) traffic-eng output in two 172.17.0.31(97) 172.16.131.1(97) page before. 172.17.0.32(94) 172.19.137.2(94) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 38 minutes Time since path change: 1 seconds Number of LSP IDs (Tun_Instances) used: 2980 Current LSP: Uptime: 4 seconds . . . [ output omitted ] July 10

Before link failure:
Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 106 Exp: R 1 172.19.24.1 MRU 4470 [Labels: 107 Exp: R 2 172.19.23.2 MRU 4470 [Labels: 124 Exp: R 3 172.19.32.2 MRU 4474 [implicit-null] 1 ! 4 172.19.137.1 2 ms
0] 0] 3 ms 0] 4 ms ms
Path: PE4 P2 P3 P32 PE7 After link failure meanwhile the backup tunnel is being used:
Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 106 Exp: R 1 172.19.24.1 MRU 4470 [Labels: 107 Exp: R 2 172.19.23.2 MRU 4470 [Labels: 124 Exp: R 3 172.19.32.2 MRU 4470 [Labels: 104 Exp: R 4 172.19.32.1 MRU 4470 [Labels: 129 Exp: U 5 172.16.36.2 MRU 4474 [implicit-null] 3 ! 6 172.16.67.2 4 ms
P1
0] 0] 0] 0] 0] ms
4 1 1 2
ms ms ms ms
Link P32 P3 twice. Because P32 is PHP for the primary tunnel, we do NOT see two labels in label stack.
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
July 10
P Node Failure
P2 failure
Information before failure:
PE4-PEXKS01# sh mpl traf tu tu 2 Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:17:25.224 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86097) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 63 FRR OutLabel : Tunnel60006, 90 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3294 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(63) 172.19.23.1(63) 172.17.0.3(90) 172.19.32.1(90) 172.17.0.32(98) 172.19.137.2(98) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 48 minutes Time since path change: 23 seconds Number of LSP IDs (Tun_Instances) used: 3001 Current LSP: Uptime: 23 seconds Prior LSP: ID: path option 1 [3288] Removal Trigger: path option updated
July 10
PE4-PEXKS01# sh mpl traf tu tu 2 protection Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:18:07.368 GMT Fri Mar 2 2007 PE4-PEXKS01_t2 LSP Head, Tunnel2, Admin: up, Oper: up Src 172.17.0.4, Dest 172.17.0.7, Instance 3294 Fast Reroute Protection: Requested Outbound: FRR Ready Backup Tu60006 to LSP nnhop Tu60006: out i/f: Gi3/3, label: 54 LSP signalling info: Original: out i/f: Gi3/2, label: 63, nhop: 172.19.24.1 nnhop: 172.17.0.3, nnhop rtr id: 172.17.0.3 With FRR: out i/f: Tu60006, label: 90 LSP bw: 100 kbps, Backup level: any-unlim, type: any pool Path Protection: None PE4-PEXKS01# trace mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M' success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
During P2 was reload we have the following result of traceroute, however the data traffic still was using the original path, as the line card didnt go down. This behaviour was checked with traffic generator. No packet loss. Due to this characteristic the backup tunnel was NOT used and before the line card went down, the primary tunnel had the new path.
Type escape sequence to abort. 0 172.19.24.2 MRU 4470 [Labels: 63 Exp: 0] . 1 * R 2 172.19.23.2 1 ms R 3 172.19.32.2 2 ms ! 4 172.19.137.1 3 ms
July 10
PE4-PEXKS01# sh mpl traf tu tu 2 Load for five secs: 1%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 13:19:10.232 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 0) Change in required resources detected: reroute pending Currently Signalled Parameters: Even 4 4 Data Plane Bandwidth: 100 kbps (Global) Priority: though in Affinity:the path can still be used; Control Plane received a signal to 0x0/0xFFFF recalculate a new path. In the next pages there Metric Type: TE (default) are some debug commands to identify this path option 1 reoptimization in progress Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/85992) 0 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
signal (ISIS flag; there is not RSVP flag for this pariticula case.
InLabel : tunnel is NOT in used. The data traffic is still using the OutLabel : GigabitEthernet3/2, 63 path via P2 as the line card did NOT go down yet. We can FRR OutLabel : Tunnel60006, 90 NOT identify this behaviour using trace mpls command. RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3294 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.2(63) 172.19.23.1(63) 172.17.0.3(90) 172.19.32.1(90) 172.17.0.32(98) 172.19.137.2(98) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 50 minutes Time since path change: 2 minutes, 8 seconds Number of LSP IDs (Tun_Instances) used: 3005 Current LSP: Uptime: 2 minutes, 8 seconds Reopt. LSP: Setup Time: 4 minutes, 57 seconds remaining Prior LSP: ID: path option 1 [3288] Removal Trigger: path option updated
Even though it is running the path calculation the backup
July 10
After path calculation:

P1
PE4
P2
P3
PE6
P30
PE5
P31
P32
PE7
PE4-PEXKS01# sh mpl traf tu tu 2 | b Explicit Route Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(26) 172.19.53.9(26) 172.17.0.31(97) 172.16.131.1(97) 172.17.0.32(104) 172.19.137.2(104) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 50 minutes Time since path change: 0 seconds Number of LSP IDs (Tun_Instances) used: 3005 Current LSP: Uptime: 3 seconds Selection: reoptimization Prior LSP: ID: path option 1 [3294] Removal Trigger: re-route path verification failed
July 10
PE4-PEXKS01# debug isis update-packets PE4-PEXKS01# debug isis mpls traffic-eng events PE4-PEXKS01# debug isis spf-triggers PE4-PEXKS01# debug isis mpls traffig-eng adver PE4-PEXKS01# 002614: Mar 2 18:08:37.094 GMT: %LDP-5-NBRCHG: LDP Neighbor 172.17.0.2:0 is DOWN (TCP connection closed by peer) 002615: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60000_3635: DOWN: path verification failed 002616: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60000: installed LSP nil for 60000_3635 (popt 1), path verification failed 002617: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60000: LSP path change nil for 60000_3635, path verification failed 002618: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60002_2075: DOWN: path verification failed 002619: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60002: installed LSP nil for 60002_2075 (popt 1), path verification failed 002620: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60002: LSP path change nil for 60002_2075, path verification failed 002621: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60003_2075: DOWN: path verification failed 002622: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60003: installed LSP nil for 60003_2075 (popt 1), path verification failed 002623: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60003: LSP path change nil for 60003_2075, path verification failed 002624: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 60005_884: DOWN: path verification failed 002625: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60005: installed LSP nil for 60005_884 (popt 1), path verification failed 002626: Mar 2 18:08:37.098 GMT: %MPLS_TE-5-TUN: Tun60005: LSP path change nil for 60005_884, path verification failed 002627: Mar 2 18:08:37.102 GMT: RT: isis's 172.17.0.7/32 (via 0.0.0.115) metric changed from distance/metric [-1408172025/1401] to [115/1960] 002628: Mar 2 18:08:37.102 GMT: RT: isis's 172.17.0.6/32 (via 0.0.0.115) metric changed from distance/metric [-1408172026/1320] to [115/2041] 002629: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.106/32 via 172.19.24.1, isis metric [115/1361] 002630: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.106/32 via 172.19.45.2, isis metric [115/1920] 002631: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.105/32 via 172.19.24.1, isis metric [115/1280] 002632: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.105/32 via 172.19.45.2, isis metric [115/2560] 002633: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.100/32 via 172.19.24.1, isis metric [115/1320] 002634: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.100/32 via 172.19.45.2, isis metric [115/2041] 002635: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.97/32 via 172.19.24.1, isis metric [115/1320] 002636: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.97/32 via 172.19.45.2, isis metric [115/2041] 002637: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.32/32 via 172.19.24.1, isis metric [115/761] 002638: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.32/32 via 172.19.45.2, isis metric [115/1320] 002639: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.31/32 via 172.19.24.1, isis metric [115/721] 002640: Mar 2 18:08:37.102 GMT: RT: add 172.17.0.31/32 via 172.19.45.2, isis metric [115/1280] 002641: Mar 2 18:08:37.102 GMT: RT: del 172.17.0.30/32 via 172.19.24.1, isis metric [115/761]
July 10
002642: Mar 2 18:08:37.102 GMT: metric [115/1320] 002643: Mar 2 18:08:37.102 GMT: metric [115/1761] 002644: Mar 2 18:08:37.102 GMT: metric [115/2320] 002645: Mar 2 18:08:37.102 GMT: metric [115/1680] 002646: Mar 2 18:08:37.106 GMT: metric [115/2401] 002647: Mar 2 18:08:37.106 GMT: metric [115/680] 002648: Mar 2 18:08:37.106 GMT: metric [115/1401] 002649: Mar 2 18:08:37.106 GMT: metric [115/640] 002650: Mar 2 18:08:37.106 GMT: 002651: Mar 2 18:08:37.106 GMT: metric [115/680] 002652: Mar 2 18:08:37.106 GMT: metric [115/1401] 002653: Mar 2 18:08:37.106 GMT: isis metric [115/791] 002654: Mar 2 18:08:37.106 GMT: isis metric [115/1512] 002655: Mar 2 18:08:37.106 GMT: metric [115/791] 002656: Mar 2 18:08:37.106 GMT: metric [115/1512] 002657: Mar 2 18:08:37.106 GMT: metric [115/791] 002658: Mar 2 18:08:37.106 GMT: metric [115/1512] 002659: Mar 2 18:08:37.106 GMT: metric [115/790] 002660: Mar 2 18:08:37.106 GMT: metric [115/1511] 002661: Mar 2 18:08:37.106 GMT: metric [115/740] 002662: Mar 2 18:08:37.106 GMT: metric [115/1611] 002663: Mar 2 18:08:37.106 GMT: metric [115/780] 002664: Mar 2 18:08:37.106 GMT: metric [115/1501] 002665: Mar 2 18:08:37.106 GMT: metric [115/790] 002666: Mar 2 18:08:37.106 GMT: metric [115/1511] 002667: Mar 2 18:08:37.106 GMT: metric [115/1960] PE4-PEXKS01# 002668: Mar 2 18:08:37.106 GMT: metric [115/2 600] 002669: Mar 2 18:08:37.106 GMT: metric [115/1320] 002670: Mar 2 18:08:37.106 GMT: 002671: Mar 2 18:08:38.114 GMT: 172.17.0.6 to 172.17.0.7 002672: Mar 2 18:08:38.114 GMT: 10.59.255.253 to 10.59.255.254 July 10
RT: add 172.17.0.30/32 via 172.19.45.2, isis RT: del 172.17.0.9/32 via 172.19.24.1, isis RT: add 172.17.0.9/32 via 172.19.45.2, isis RT: del 172.17.0.8/32 via 172.19.24.1, isis RT: add 172.17.0.8/32 via 172.19.45.2, isis RT: del 172.17.0.3/32 via 172.19.24.1, isis RT: add 172.17.0.3/32 via 172.19.45.2, isis RT: del 172.17.0.2/32 via 172.19.24.1, isis RT: delete subnet route to 172.17.0.2/32 RT: del 172.17.0.1/32 via 172.19.24.1, isis RT: add 172.17.0.1/32 via 172.19.45.2, isis RT: del 194.164.243.141/32 via 172.19.24.1, RT: add 194.164.243.141/32 via 172.19.45.2, RT: del 64.103.126.92/32 via 172.19.24.1, isis RT: add 64.103.126.92/32 via 172.19.45.2, isis RT: del 64.103.126.85/32 via 172.19.24.1, isis RT: add 64.103.126.85/32 via 172.19.45.2, isis RT: del 10.59.255.254/32 via 172.19.24.1, isis RT: add 10.59.255.254/32 via 172.19.45.2, isis RT: del 10.59.255.253/32 via 172.19.24.1, isis RT: add 10.59.255.253/32 via 172.19.45.2, isis RT: del 10.59.95.2/32 via 172.19.24.1, isis RT: add 10.59.95.2/32 via 172.19.45.2, isis RT: del 10.59.95.1/32 via 172.19.24.1, isis RT: add 10.59.95.1/32 via 172.19.45.2, isis RT: del 172.16.67.0/30 via 172.17.0.6, isis
RT: add 172.16.67.0/30 via 172.17.0.7, isis
RT: del 172.17.18.0/24 via 172.17.0.6, isis RT: RT(VOIP): 10.18.115.0/24 gateway changed from RT(VOIP): 10.220.132.0/23 gateway changed from
002673: Mar 2 18:08:38.114 GMT: RT(edn): 10.0.0.0/8 gateway changed from 172.17.0.6 to 172.17.0.7 002674: Mar 2 18:08:38.114 GMT: RT(6509_mgmt): 172.17.8.48/28 gateway changed from 172.17.0.6 to 172.17.0.7 002675: Mar 2 18:08:38.114 GMT: RT(6509_mgmt): 172.17.9.224/28 gateway changed from 172.17.0.6 to 172.17.0.7 002676: Mar 2 18:08:38.114 GMT: RT(CN5_BE): 10.18.119.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002677: Mar 2 18:08:38.114 GMT: RT(VPN): 10.18.118.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002678: Mar 2 18:08:38.114 GMT: RT(sigtran_blue): 10.18.116.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002679: Mar 2 18:08:38.114 GMT: RT(AX4000): 50.50.50.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002680: Mar 2 18:08:38.114 GMT: RT(AX4000): 50.50.51.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002681: Mar 2 18:08:38.114 GMT: RT(SmartBits): 30.30.30.0/24 gateway changed from 172.17.0.6 to 172.17.0.7 002682: Mar 2 18:08:38.114 GMT: RT(ospftest): 90.90.90.0/24 gateway changed from 172.17.0.6 to 172.17.0.7
Power-off P2 route
As soon as P2 is powered-off:
PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 3%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 18:52:31.458 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1401) Change in required resources detected: reroute pending Currently Signalled Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) path option 1 reoptimization in progress Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/86087) 6 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/2, 110 Backup tunnel in used. FRR OutLabel : Tunnel60006, 86 (in use) RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3952 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
July 10
172.17.0.2(110) 172.19.23.1(110) 172.17.0.3(86) 172.19.32.1(86) 172.17.0.32(78) 172.19.137.2(78) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1960 (TE) Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 6 hours, 23 minutes Time since path change: 1 minutes, 25 seconds Number of LSP IDs (Tun_Instances) used: 3662 Current LSP: Uptime: 1 minutes, 25 seconds Reopt. LSP: Setup Time: 4 minutes, 54 seconds remaining Prior LSP: ID: path option 1 [3915] Removal Trigger: path option updated
RSVP Resv Info: Record Route:
After path re-calculation

PE4-PEXKS01# tra mpl tra tu 2 Tracing MPLS TE Label Switched Path on Tunnel2, timeout is 2 seconds Codes: '!' '.' 'R' 'M' success, 'Q' - request not transmitted, timeout, 'U' - unreachable, downstream router but not target, malformed request
July 10
PE4-PEXKS01# sh mpl tra tu tu2 Load for five secs: 1%/0%; one minute: 1%; five minutes: 0% Time source is NTP, 19:13:33.301 GMT Fri Mar 2 2007 Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7 Status: Admin: up Oper: up Path: valid Signalling: connected path option 1, type dynamic (Basis for Setup, path weight 1960) path option 1 reoptimization in progress Config Parameters: Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF Metric Type: TE (default) AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based auto-bw: (86400/84825) 3785 Bandwidth Requested: 100 Active Path Option Parameters: State: dynamic path option 1 is active BandwidthOverride: disabled LockDown: disabled Verbatim: disabled InLabel : OutLabel : GigabitEthernet3/3, 49 FRR OutLabel : Tunnel60003, 79 RSVP Signalling Info: Src 172.17.0.4, Dst 172.17.0.7, Tun_Id 2, Tun_Instance 3957 RSVP Path Info: My Address: 172.17.0.4 Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1 172.17.0.7 Record Route: Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits RSVP Resv Info: Record Route: 172.17.0.5(49) 172.19.53.9(49) 172.17.0.31(79) 172.16.131.1(79) 172.17.0.32(80) 172.19.137.2(80) 172.17.0.7(0) 172.19.137.1(0) Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits Shortest Unconstrained Path Info: Path Weight: 1401 (TE) Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1 172.17.0.7 History: Tunnel: Time since created: 1 days, 6 hours, 44 minutes Time since path change: 20 minutes, 43 seconds Number of LSP IDs (Tun_Instances) used: 3703 Current LSP: Uptime: 20 minutes, 46 seconds Selection: reoptimization Reopt. LSP: Setup Time: 4 minutes, 44 seconds remaining Prior LSP: ID: path option 1 [3952] Removal Trigger: re-route path error
July 10
AToM issues
PE-7# sh mpl l2transport vc 100 Local intf ------------Se2/0 Local circuit Dest address VC ID Status -------------------------- --------------- ---------- ---------HDLC 172.17.0.4 100 DOWN
This output shows the virtual cirtuit created from this PE (PE7) to the remote PE (PE-4) is down. As the neighbour is reachable (172.17.0.4 reachability is OK), we can conclude the Layer 2 VPN is not configured in the remote site, or it is using a different VC-id. In this particular example, the remote site should have a VC-id 100 created with a destination IP address PE7 ip address. The configuration should be:
PE-7# sh run int s2/0 Building configuration... Current configuration : 157 bytes ! interface Serial2/0 description >>>> link to CE4 no ip address no ip directed-broadcast no cdp enable xconnect 172.17.0.4 100 encapsulation mpls end PE-4# sh run int s2/0 Building configuration... Current configuration : 157 bytes ! interface Serial2/0 description >>>> link to CE1 no ip address no ip directed-broadcast no cdp enable xconnect 172.17.0.7 100 encapsulation mpls end
July 10
Figure 12 - Lab topology for LINK and NODE failures scenarios

AX4000
E1 CHOC3-E1 STM1 or STM4 10GE POS CHOC48 POS STM16 GE POS STM1 FE
F 6 E
GE stm1 /4
3/2 0
packet 5 (to ports generator under test) 4 GE 3 1 2 stm 1/4
FE
172.17.7.83
2/2
0/1
6509-1
10.40.31.6 vlan98 3/0.98 10.40.31.5
172.17.0.8 172.16.18.0/30 RR1

2/0/0
3/20 172.17.8.51
6509-3
5/8 1/1
3/0.98 10.33.31.5 10.33.31.6 vlan98
1/2
1/1
1/2 2/2
172.17.0.1 P1
2/ 0/ 17 3 2. 19 .1 3. 0 2/ /30 0/ 3
2/ 0/ 1 17 2. 19 2/ 0/ .1 1 2. 0/ 30
0 .30.0/3 172.19 2/1/1
3/1 1/6
3/1 1/6
172.16.36.0/30 4/0/1 3/2
172.17.0.4 PE4
3/3
172.19.45.0/30
172.17.0.2
2/0/2 3/2 172.19.24.0/30
3/0/0 172.19.23.0/30
3/0/0
172.17.0.3 P3
172.17.0.6 PE6
0/2 3/1
P2
2/0/4
.3 172.19
3/2
2/0/4
.32 172.19
172.16.67.0/30
P30
6. 13 0. 0/ 30
3/3 0/1 0/2 0/1 172.19.29.8./30
17 2. 1
172.17.0.9 RR2
3/0/3
3/1 3/0/2 .9 172.19.53.8/30 .103/2
172.17.0.5
3/0/0.99 10.40.31.9 10.40.31.10 vlan99
172.17.0.31 P31
3/3 172.19.131.0/30
0/2 3/3
172.17.0.32 172.19.137.0/30 P32

3/2
3/0/2
172.17.0.7 PE7
PE5
3/0/0 3/0/8 3/0/9
3/0/4
3/0
3/0
0/2
QOS test targets
172.17.0.30
2. 17
3/0/0.99 10.33.31.9
1/1 5/13 5/14 1/2 2/2 172.17.7.84
5/8
1/1
10.33.31.10 vlan99
172.17.8.52 1/2 6509-4

2/2
6509-2
10.59.95.82/30 Gn
3/0
3/3 3/0/3
3/0
.0/30
1.0/30
.1 16 .0 32 0 /3
3/0/0
July 10
Advanced Service
140
Conclusion
This Troubleshothing guide aim to present a methodology to understand and how to fix some misconfiguration and failure scenarios may occur on MPLS network. Symptons may appear as the Forwarding Problem. Whether it is an actual Forwarding Problem (packet drops?) or Control Plane Problem. Whether it is an MPLS VPN, or MPLS or TE problem. Adhere to step-by-step systematic approach to troubleshooting.
In summary, you have kept in mind: RIB Routing Information Base (Routing Table) show ip route FIB Forwarding Information Base (CEF table derived from the RIB) show ip cef LIB Label Information Base (Label database containing the label bindings) show mpls label binding LFIB Forwarding Label Information Base (Label bindings used that is derived from the FIB & LIB) show mpls forwarding To view the FIB for IP-to-IP and IP-to-MPLS use: show ip cef To view the LFIB for MPLS-to-MPLS and MPLS-to-IP use: show mpls forwarding Control Plane verification Ensure CEF is enabled global show ip cef summary Ensure CEF is enabled on the interface (no ip route-cache cef - interface level) show ip cef <interface> Ensure LDP/TDP is enabled on the interfaces and the protocol matches with the neighbour routers show mpls interface show mpls ldp discovery Check the LDP neighbour adjacency show mpls ldp neighbor Ensure reachability to LDP router ID Ping from LDP router ID to the neighbours LDP router ID For LDP over ATM issues verify the control VC show mpls interfaces <interface> detail Ensure that the advertisement of labels has not been disabled mpls ldp advertise-labels
July 10
Advanced Service
141
Common Control Plane Issues Label distribution protocol does not match No route to the neighbors LDP router-ID learned via IGP LDP communication filtered Mismatch with LDP authentication
As Best Practice, always use the same router-id for each technology (BGP, Multicast, IGP, LDP, TE etc) Forwarding Plane verification Ensure the next-hop for the VPNv4 peering session is in the MPLS forwarding table show mpls forwarding <bgp next-hop IP address> ALWAYS CHECK THE CONFIGURATION
July 10
Advanced Service
142
TM
Part 6: Appendix
Appendix I
Troubleshooting GSR forwarding

Packet forwarding: FIB/LFIB on RP, LC and ASIC
PEXBE01# attach 3 LC-Slot3> en LC-Slot3# sh mpls traffic-eng fast-reroute data Tunnel head end item frr information: Protected tunnel Tunnel2 Tunnel11 Tunnel15 Tunnel23 Tunnel33 Tunnel10 Tunnel22 Tunnel43 <output omitted> LC-Slot3# sh mpls forwarding-table Local tag 16 17 22 77 79 80 153 154 155 163 164 167 168 171 185 Outgoing tag or VC Untagged Untagged Untagged 539 326 Untagged Untagged Pop tag Pop tag 29 22 Pop tag Pop tag Pop tag Untagged Prefix or Tunnel Id l2ckt(329506200) l2ckt(329506201) l2ckt(329546200) 172.17.1.116/30 172.17.2.168/30 l2ckt(329555300) 172.17.0.5/32 172.17.16.16/30 172.17.0.27/32 172.17.0.20/32 172.17.0.2/32 172.17.0.21/32 172.17.0.16/32 10.197.4.0/23[V] Bytes tag switched 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Outgoing interface none none none Gi3/1 Gi3/1 none none Gi3/0 Gi3/1 Gi3/1 Gi3/1 Tu2 Tu43 Tu7 point2point point2point point2point 172.17.1.10 172.17.1.10 point2point point2point 172.17.3.10 172.17.1.10 172.17.1.10 172.17.1.10 point2point point2point point2point Next Hop In-label Out intf/label Tun hd Tun hd Tun hd Tun hd Tun hd Tun hd Tun hd Tun hd Gi3/1:Untagged Gi3/1:Untagged Gi3/1:Untagged Gi3/1:Untagged Gi3/1:Untagged Gi3/1:Untagged Gi3/1:Untagged Gi3/1:Untagged FRR intf/label Status Tu60001:tag-impl ready Tu60002:tag-impl ready Tu60003:tag-impl ready Tu60004:tag-impl ready Tu60005:tag-impl ready Tu60006:870 Tu60006:872 Tu60006:869 ready ready ready
<output ommited>
l2ckt(2294240432) 0
Gi7/0/1.256 10.197.1.52
<output ommited>
July 10
Advanced Service
144
LC-Slot3# sh mpls alpha-lfib Start address of TFIB root: 0x28084000 Default PLU leaf: 0x28083FF0 (1047731 refs) Default tag rewrite in TLU: 0x2008FBC0 (549 refs incl. one from default leaf) Tag 16 17 18 22 23 24 25 26 27 28 29 30 31 32 PLU Loc Value Leaf Address (PLU/CPU) 0x00810766/0x30083B30 0x00010764/0x24083B20 0x0081075C/0x28083AE0 0x0081065A/0x300832D0 0x000107EA/0x24083F50 0x00010774/0x2C083BA0 0x00810774/0x30083BA0 0x00010772/0x24083B90 0x00810772/0x28083B90 0x00810782/0x28083C10 0x00010782/0x2C083C10 0x00810782/0x30083C10 0x00010780/0x24083C00 0x00810780/0x28083C00 leaf-bit Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear
0x28084040 0x01810766 0x28084044 0x00010764 0x28084048 0x0081075C 0x28084058 0x0181065A 0x2808405C 0x000107EA 0x28084060 0x01010774 0x28084064 0x01810774 0x28084068 0x00010772 0x2808406C 0x00810772 0x28084070 0x00810782 0x28084074 0x01010782 0x28084078 0x01810782 0x2808407C 0x00010780 0x28084080 0x00810780
<output ommited> LC-Slot3# sh mpls hardware-lfib Start address of TFIB root: 0x28084000 Default PLU leaf: 0x28083FF0 (1047734 refs) Default tag rewrite in TLU: 0x2008FBC0 (546 refs incl. one from default leaf) Tag 16 17 18 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 PLU Loc Value Leaf Address (PLU/CPU) 0x00810766/0x30083B30 0x00010764/0x24083B20 0x0081075C/0x28083AE0 0x0081065A/0x300832D0 0x000107EA/0x24083F50 0x00010774/0x2C083BA0 0x00810774/0x30083BA0 0x00010772/0x24083B90 0x00810772/0x28083B90 0x00810782/0x28083C10 0x00010782/0x2C083C10 0x00810782/0x30083C10 0x00010780/0x24083C00 0x00810780/0x28083C00 0x00010780/0x2C083C00 0x00810780/0x30083C00 0x0001077E/0x24083BF0 0x0081077E/0x28083BF0 leaf-bit Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear Clear
0x28084040 0x01810766 0x28084044 0x00010764 0x28084048 0x0081075C 0x28084058 0x0181065A 0x2808405C 0x000107EA 0x28084060 0x01010774 0x28084064 0x01810774 0x28084068 0x00010772 0x2808406C 0x00810772 0x28084070 0x00810782 0x28084074 0x01010782 0x28084078 0x01810782 0x2808407C 0x00010780 0x28084080 0x00810780 0x28084084 0x01010780 0x28084088 0x01810780 0x2808408C 0x0001077E 0x28084090 0x0081077E
<output ommited>
July 10
Advanced Service
145
Debug commands of interest for Control Plane

debug mpls ldp advertisements debug mpls ldp bindings debug mpls ldp igp debug mpls ldp message <send|received> debug mpls ldp session debug mpls traffic-eng path debug isis mpls traffic-eng debug isis update-packets debug isis spf-triggers debug isis mpls traffig-eng events debug isis mpls traffig-eng advertisements debug ip rsvp fast-reroute debug ip rsvp path <acl> detail debug ip rsvp resv <acl> detail debug ip rsvp rsvp signalling
PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01# PE4-PEXKS01# 002297: Mar 002298: Mar PE4-PEXKS01# 002299: Mar PE4-PEXKS01# debug debug debug debug ip ip ip ip rsvp rsvp rsvp rsvp fast-reroute resv path signalling
2 17:35:21.702 GMT: RSVP: Sending Srefresh message to 172.19.24.1 2 17:35:22.377 GMT: RSVP: Sending Srefresh message to 172.19.45.2 2 17:35:23.721 GMT: RSVP: Sending Srefresh message to 172.19.24.1
002300: Mar 2 17:35:25.273 GMT: RSVP: session 172.17.0.7_2[172.17.0.4]: Received Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002301: Mar 2 17:35:25.273 GMT: RSVP: 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3)
002302: Mar 2 17:35:25.273 GMT: RSVP: 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: reservation not found--new one
002303: Mar 2 17:35:25.273 GMT: RSVP-RESV: Admitting new reservation: 9BC75C8

002304: Mar 2 17:35:25.273 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 2_3803: UP 002305: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_
frr_event_resv_arrive: Event: Resv Arrived

002306: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_resv_arrive: Action: LSP has no backup, try to get one
002307: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels:
002308: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002309: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0
002310: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20
July 10
Advanced Service
146
002311: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002312: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002313: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002314: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002315: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_ frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002316: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002317: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002318: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 002319: Mar 2 17:35:25.273 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002320: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E
002321: Mar 2 17:35:25.273 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found:

NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 002322: Mar 2 17:35:25.277 GMT: NHOP Label 0x31 N-NHOP Label
0x4E
002323: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: Look for N-NHOP Bkup Tun to 172.17.0.31 protecting GigabitEthernet3/3 with > 100 kbs avail
002324: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: No such N-NHOP Backup Tunnel Found 002325: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: Look for NHOP Bkup Tun to 172.17.0.5 protecting GigabitEthernet3/3 with > 100 kbs avail 002326: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_prepare: Notify auto-tunnel for backup creation 002327: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_remove_lsp: clearing 0 kbs 002328: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_set_backup: prepare failed 002329: Mar 2 17:35:25.277 GMT: RSVP-RESV: reservation was installed: 9BC75C8 002330: Mar 2 17:35:25.277 GMT: %MPLS_TE-5-TUN: Tun2: installed LSP 2_3803 (popt 1) for 2_3744 (popt 1), reopt. LSP is up
002331: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_tunnel_info: Tunnel info requested by auto-tunnel backup
002332: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002333: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002334: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002335: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 002336: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success July 10
Advanced Service
147
002337: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002338: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002339: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002340: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002341: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002342: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002343: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 002344: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002345: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E 002346: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found: NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 PE4-PEXKS01# 002347: Mar 2 17:35:25.277 GMT: NHOP Label 0x31 N-NHOP Label 0x4E 002348: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_tunnel_info: Tunnel info: Protected I/F: GigabitEthernet3/3, NHOP Router ID: 172.17.0.5, N-NHOP Router ID: 172.17.0.31 002349: Mar 2 17:35:25.793 GMT: RSVP: Sending Ack message to 172.19.45.2 002350: Mar 2 17:35:26.025 GMT: RSVP: session 172.17.0.7_2[172.17.0.4]: Received Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002351: Mar 2 17:35:26.025 GMT: RSVP: 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002352: Mar 2 17:35:26.025 GMT: RSVP: 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: No change in reservation 002353: Mar 2 17:35:26.545 GMT: RSVP: Sending Ack message to 172.19.45.2 002354: Mar 2 17:35:26.925 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4 PE4-PEXKS01#
002355: Mar 2 17:35:26.925 GMT: %MPLS_TE-5-TUN: Tun2: installed LSP 2_3803 (popt 1) for 2_3744 (popt 1), reopt. LSP is up
PE4-PEXKS01# 002356: Mar 2 17:35:27.740 GMT: RSVP: Sending Srefresh message to 172.19.24.1 002357: Mar 2 17:35:28.272 GMT: %MPLS_TE-5-TUN: Tun2: installed LSP 2_3803 (popt 1) for 2_3744 (popt 1), reopt. LSP is up
002358: Mar 2 17:35:28.272 GMT: %MPLS_TE-5-TUN: Tun2: LSP path change 2_3803 for 2_3744, reroute path verification failed
PE4-PEXKS01# 002359: Mar 2 17:35:28.756 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4 002360: Mar 2 17:35:29.992 GMT: %CLNS-5-ADJCHANGE: ISIS: Adjacency to P2 (GigabitEthernet3/2) Down, hold time expired PE4-PEXKS01# 002361: Mar 2 17:35:29.996 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4
July 10
Advanced Service
148
002362: Mar 2 17:35:30.308 GMT: RSVP: session 172.17.0.6_1[172.17.0.4]: Received Resv mes sage from 172.19.45.2 (on GigabitEthernet3/3) 002363: Mar 2 17:35:30.308 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002364: Mar 2 17:35:30.308 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: reservation not found--new one 002365: Mar 2 17:35:30.308 GMT: RSVP-RESV: Admitting new reservation: 9BC79D0 002366: Mar 2 17:35:30.312 GMT: %MPLS_TE-5-LSP: LSP 172.17.0.4 1_2685: UP 002367: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_resv_arrive: Event: Resv Arrived 002368: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_resv_arrive: Action: LSP has no backup, try to get one 002369: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002370: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002371: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002372: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000035 flags 20 002373: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002374: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x35 002375: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002376: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002377: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000035 flags 00 002378: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002379: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002380: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 00000051 flags 29 002381: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002382: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x51 002383: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found: NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 002384: Mar 2 17:35:30.312 GMT: NHOP Label 0x35 N-NHOP Label 0x51 002385: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: Look for N-NHOP Bkup Tun to 172.17.0.31 protecting GigabitEthernet3/3 with > 100 kbs avail 002386: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: No such N-NHOP Backup Tunnel Found
July 10
Advanced Service
149
002387: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: Look for NHOP Bkup Tun to 172.17.0.5 protecting GigabitEthernet3/3 with > 100 kbs avail 002388: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_prepare: Notify auto-tunnel for backup creation 002389: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_remove_lsp: clearing 0 kbs 002390: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_set_backup: prepare failed 002391: Mar 2 17:35:30.312 GMT: RSVP-RESV: reservation was installed: 9BC79D0 002392: Mar 2 17:35:30.312 GMT: %MPLS_TE-5-TUN: Tun1: installed LSP 1_2685 (popt 1) for 1_2626 (popt 1), reopt. LSP is up 002393: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_ frr_get_tunnel_info: Tunnel info requested by auto-tunnel backup 002394: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002395: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002396: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002397: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000035 flags 20 002398: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002399: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x35 002400: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002401: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002402: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000035 flags 00 002403: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002404: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002405: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 00000051 flags 29 002406: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002407: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x51 002408: Mar 2 17:35:30.312 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found: NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 PE4-PEXKS01# 002409: Mar 2 17:35:30.312 GMT: NHOP Label 0x35 N-NHOP Label 0x51 002410: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: rsvp_ frr_get_tunnel_info: Tunnel info: Protected I/F: GigabitEthernet3/3, NHOP Router ID: 172.17.0.5, N-NHOP Router ID: 172.17.0.31
July 10
Advanced Service
150
002411: Mar 2 17:35:30.828 GMT: RSVP: Sending Ack message to 172.19.45.2 002412: Mar 2 17:35:31.060 GMT: RSVP: session 172.17.0.6_1[172.17.0.4]: Received Resv message from 172.19.45.2 (on GigabitEthernet3/3) 002413: Mar 2 17:35:31.060 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: Successfully parsed Resv message from 172.19.45.2 (on GigabitEthernet3/3) PE4-PEXKS01# 002414: Mar 2 17:35:31.060 GMT: RSVP: 172.17.0.4_2685>172.17.0.6_1[172.17.0.4]: No change in reservation 002415: Mar 2 17:35:31.580 GMT: RSVP: Sending Ack message to 172.19.45.2 002416: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_ frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002417: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs 002418: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002419: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 002420: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002421: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002422: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002423: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2002424: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002425: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002426: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4002427: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803->172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 PE4-PEXKS01# 002428: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002429: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E 002430: Mar 2 17:35:32.843 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found: NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 002431: Mar 2 17:35:32.843 GMT: NHOP Label 0x31 N-NHOP Label 0x4E 002432: Mar 2 17:35:33.071 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4002433: Mar 2 17:35:33.075 GMT: %MPLS_TE-5-TUN: Tun1: installed LSP 1_2685 (popt 1) for 1_2626 (popt 1), reopt. LSP is up 002434: Mar 2 17:35:33.311 GMT: %MPLS_TE-5-TUN: Tun1: installed LSP 1_2685 (popt 1) for 1_2626 (popt 1), reopt. LSP is up
002435: Mar 2 17:35:33.311 GMT: %MPLS_TE-5-TUN: Tun1: LSP path change 1_2685 for 1_2626, reroute path verification failed
002436: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_parse_ero_rro: Looking in RRO for NHOP & NNHOP Addrs/Labels: 002437: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 0, skipping 172.17.0.4's addrs
July 10
Advanced Service
151
002438: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 0 002439: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.5 Label 00000031 flags 20 002440: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002441: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31 002442: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Looking in RRO, starting at index 2, skipping 172.17.0.5's addrs 002443: Mar 2 17:35:33.767 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 2 002444: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.19.53.9 Label 00000031 flags 00 002445: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002446: Mar 2 17:35:33.771 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Get RRO subobject at index 4 002447: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_get_rro_subobject_at_index: Returning address 172.17.0.31 Label 0000004E flags 21 PE4-PEXKS01# 002448: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803>172.17.0.7_2[172.17.0.4]: rsvp_frr_find_rro_next_rrr_id: PCALC Success 002449: Mar 2 17:35:33.771 GMT: RSVP-FRR: rsvp_frr_find_rro_next_rrr_id: Succeeded, returning RRR ID 172.17.0.31 ADDR 172.17.0.31 Label 0x4E 002450: Mar 2 17:35:33.771 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO, found: NHOP Addr 172.17.0.5 N-NHOP Addr 172.17.0.31 NHOP RRR ID 172.17.0.5 N-NHOP RRR ID 172.17.0.31 002451: Mar 2 17:35:33.771 GMT: NHOP Label 0x31 N-NHOP Label 0x4E PE4-PEXKS01# 002469: Mar 2 17:35:35.759 GMT: RSVP: Sending Srefresh message to 172.19.24.1 PE4-PEXKS01# 002470: Mar 2 17:35:38.270 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Expiring sender host PATH state, reason: Local application requested tear (0:3744) 002471: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002472: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Action: LSP is ready, clear backup 002473: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_remove_lsp: clearing 100 kbs 002474: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_remove_lsp: reducing 100 kbs on Tunnel60006 002475: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002476: Mar 2 17:35:38.270 GMT: RSVP-FRR 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: rsvp_frr_event_lsp_down: Action: LSP has no backup, ignore event 002477: Mar 2 17:35:38.270 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Expiring GigabitEthernet3/2 RESV state, reason: Local application requested tear (0:3744) PE4-PEXKS01# 002478: Mar 2 17:35:38.270 GMT: RSVP-FRR: rsvp_frr_tpdb_node_change: topology data base node change: event: 4
July 10
Advanced Service
152
002479: Mar 2 17:35:38.294 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 002480: Mar 2 17:35:38.814 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002481: Mar 2 17:35:39.834 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002482: Mar 2 17:35:41.854 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002483: Mar 2 17:35:43.309 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Expiring sender host PATH state, reason: Local application requested tear (0:2626) 002484: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002485: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_lsp_down: Action: LSP is ready, clear backup 002486: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_remove_lsp: clearing 100 kbs 002487: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_remove_lsp: reducing 100 kbs on Tunnel60006 002488: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_frr_event_lsp_down: Event: psb or rsb Expiring 002489: Mar 2 17:35:43.309 GMT: RSVP-FRR 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: rsvp_ frr_event_lsp_down: Action: LSP has no backup, ignore event 002490: Mar 2 17:35:43.309 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Expiring GigabitEthernet3/2 RESV state, reason: Local application requested tear (0:2626) PE4-PEXKS01# 002491: Mar 2 17:35:43.333 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002492: Mar 2 17:35:43.853 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002493: Mar 2 17:35:44.873 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002494: Mar 2 17:35:45.873 GMT: RSVP: 172.17.0.4_3744>172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002495: Mar 2 17:35:46.893 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 PE4-PEXKS01# 002496: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1097>172.17.0.31_60004[172.17.0.4]: Resv state is being refreshed for 0x52271 nbr: 172.19.45.2 002497: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.1_29>172.17.0.4_60009[172.17.0.1]: Path state is being refreshed for 0x52282 nbr: 172.19.45.2 002498: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.31_4855>172.17.0.4_60005[172.17.0.31]: Path state is being refreshed for 0x52286 nbr: 172.19.45.2 002499: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1>172.17.0.31_60007[172.17.0.4]: Resv state is being refreshed for 0x52299 nbr: 172.19.45.2 002500: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1>172.17.0.1_60008[172.17.0.4]: Resv state is being refreshed for 0x523C4 nbr: 172.19.45.2 July 10
Advanced Service
153
002501: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_3057>172.17.0.3_60001[172.17.0.4]: Resv state is being refreshed for 0x52581 nbr: 172.19.45.2 002502: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_306>172.17.0.3_60006[172.17.0.4]: Resv state is being refreshed for 0x52582 nbr: 172.19.45.2 002503: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.3_1>172.17.0.4_60006[172.17.0.3]: Path state is being refreshed for 0x52585 nbr: 172.19.45.2 002509: Mar 2 17:35:50.156 GMT: RSVP: Sending Srefresh message to 172.19.24.1 002510: Mar 2 17:35:50.676 GMT: RSVP: Sending Srefresh message to 172.19.24.1 002511: Mar 2 17:35:50.912 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002512: Mar 2 17:35:51.696 GMT: RSVP: Sending Srefresh message to 172.19.24.1 002513: Mar 2 17:35:52.372 GMT: RSVP: Sending Srefresh message to 172.19.45.2 002514: Mar 2 17:35:53.719 GMT: RSVP: Sending Srefresh message to 172.19.24.1
002515: Mar 2 17:35:53.891 GMT: RSVP: 172.17.0.4_3744->172.17.0.7_2[172.17.0.4]: Sending PathTear message to 172.19.24.1
002516: Mar 2 17:35:57.739 GMT: RSVP: Sending Srefresh message to 172.19.24.1 002517: Mar 2 17:35:59.470 GMT: %RPGE-6-RX_LOS: Interface GigabitEthernet3/2: Detected RX Loss of Signal 002518: Mar 2 17:35:59.474 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet3/2, changed state to down 002519: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.6_9113>172.17.0.4_1[172.17.0.6]: rsvp_frr_event_input_if_dn: Event: input ifc GigabitEthernet3/2 is down 002520: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.6_9113>172.17.0.4_1[172.17.0.6]: rsvp_frr_event_input_if_dn: Action: enabled FRR on input for this LSP 002521: Mar 2 17:35:59.474 GMT: RSVP: 172.17.0.6_9113>172.17.0.4_1[172.17.0.6]: PATH not cleaned up (on GigabitEthernet3/2), fast reroute in progress 002522: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.7_4656>172.17.0.4_1[172.17.0.7]: rsvp_frr_event_input_if_dn: Event: input ifc GigabitEthernet3/2 is down 002523: Mar 2 17:35:59.474 GMT: RSVP-FRR 172.17.0.7_4656>172.17.0.4_1[172.17.0.7]: rsvp_frr_event_input_if_dn: Action: enabled FRR on input for this LSP 002524: Mar 2 17:35:59.474 GMT: RSVP: 172.17.0.7_4656>172.17.0.4_1[172.17.0.7]: PATH not cleaned up (on GigabitEthernet3/2), fast reroute in progress 002525: Mar 2 17:35:59.486 GMT: %RPGE-6-LINK_STATUS_DOWN: Interface GigabitEthernet4/0/0: Detected RX Link Status Down 002526: Mar 2 17:35:59.818 GMT: %RPGE-6-GBIC_TX_FAULT: Interface GigabitEthernet4/0/0: GBIC TX Fault Detected 002527: Mar 2 17:36:00.410 GMT: %RPGE-6-GBIC_TX_FAULT: Interface GigabitEthernet3/2: GBIC TX Fault OK 002528: Mar 2 17:36:00.474 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet3/2, changed state to down 002529: Mar 2 17:36:01.486 GMT: %LINK-3-UPDOWN: Interface GigabitEthernet4/0/0, changed state to down 002530: Mar 2 17:36:01.890 GMT: RSVP: 172.17.0.4_2626>172.17.0.6_1[172.17.0.4]: Sending PathTear message to 172.19.24.1 002531: Mar 2 17:36:01.890 GMT: RSVP: Sending Srefresh message to 172.19.24.1 PE4-PEXKS01# 002532: Mar 2 17:36:02.486 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEt hernet4/0/0, changed state to down
July 10
Advanced Service
154
Debug commands of interest for Data Plane

debug mpls packets tunnels <#> debug ip cef receive <acl>
Debug commands of interest for MPLS and MPLS/VPN

debug mpls ldp adver debug mpls lfib debug mpls bgp debug ip ospf packet debug clns packets
Debug commands of interest for AToM

Debug mpls l2transport
July 10
Advanced Service
155
How to measure packet loss

TTCP
Sender: ROUTER01 (10.33.252.231) Receiver: 6509-2 (10.40.31.2) Path: ROUTER01 6509-4 PE7 P32 P31 CE2 Check possible paths so TTCP will be seen to use the possible "slow" paths:
ROUTER01# tracer 10.40.31.2 Type escape sequence to abort. Tracing the route to 10.40.31.2 1 10.33.33.3 0 msec 10.33.33.4 0 msec 10.33.33.3 0 msec 2 10.33.31.9 0 msec 10.33.31.5 0 msec 10.33.31.9 0 msec 3 172.16.36.1 0 msec 172.19.137.2 4 msec 172.16.36.1 0 msec 4 172.16.131.1 0 msec 10.40.31.5 0 msec 172.16.131.1 4 msec 5 10.40.31.6 0 msec 10.40.31.9 0 msec 10.40.31.6 0 msec 6 10.40.31.10 0 msec 10.40.3.4 0 msec *
Start CE2 in Receive mode; using default parameters, except that we do want to see stats (last question):
CE2# ttcp transmit or receive [receive]: perform tcp half close [n]: receive buflen [8192]: bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: rcvwndsize [4128]: delayed ACK [y]: show tcp information at end [n]: y ttcp-r: buflen=8192, align=16384/0, port=5001 rcvwndsize=4128, delayedack=yes tcp
The vty session is now "hung" until TTCP sender finshes sending.
July 10
Advanced Service
156
Start ROUTER01 in sending mode; default all parameters except "t", target IP and stats Y. Default parameters sending 2024 x 8192 = 16Mbytes Remember, TCP mechanisms (slow start and congestion avoindance), so TCP will back off if congestion
ROUTER01# ttcp transmit or receive [receive]: t Target IP address: 10.40.31.2 perform tcp half close [n]: send buflen [8192]: send nbuf [2048]: bufalign [16384]: bufoffset [0]: port [5001]: sinkmode [y]: buffering on writes [y]: show tcp information at end [n]: y
### TTCP establishes the connection, and a message pops up at both ends
(ROUTER01) ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 ttcp-t: connect (mss 536, sndwnd 4128, rcvwnd 4128) tcp -> 10.40.31.2
(CE2) ttcp-r: accept from 10.33.33.75 (mss 536, sndwnd 4128, rcvwnd 4128)
Now, the 16 MBytes are sent from ROUTER01 6509-2 and 6509-2 sends TCP ACKs only. Check the time taken and hopefully it fineshes. Results at ROUTER01: ignore the TCP session details, just look at the time taken in the first line of output
ttcp-t: 16777216 bytes in 9308 ms (9.308 real seconds) (~1759 kB/s) +++ ttcp-t: 2048 I/O calls ttcp-t: 0 sleeps (0 ms total) (0 ms average) Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: 10.33.33.75, Local port: 32483 Foreign host: 10.40.31.2, Foreign port: 5001 Enqueued packets for retransmit: 4, input: 0
Total of time for transmission. Sender respective.
mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x58FF050): Timer Starts Wakeups Next Retrans 12798 0 0x58FF17B TimeWait 0 0 0x0 AckHold 0 0 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 2600288481 snduna: 2617063938 sndnxt: 2617065698 sndwnd: 4128
July 10
Advanced Service
157
irs: 3904303256
rcvnxt: 3904303257
rcvwnd:
4128
delrcvwnd:
SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: higher precedence, retransmission timeout Datagrams (max data segment is 536 bytes): Rcvd: 30718 (out of order: 0), with data: 0, total data bytes: 0 Sent: 32770 (retransmit: 0, fastretransmit: 0), with data: 32768, total data bytes: 16777216
(Results at 6509-2 end)

ttcp-r: 16777216 bytes in 9316 ms (9.316 real seconds) (~1757 kB/s) +++ ttcp-r: 13072 I/O calls ttcp-r: 0 sleeps (0 ms total) (0 ms average) Connection state is CLOSEWAIT, I/O status: 7, unread input bytes: Local host: 10.40.31.2, Local port: 5001 Foreign host: 10.33.33.75, Foreign port: 32483 Enqueued packets for retransmit: 0, input: 0
Total of time for transmission. Receiver respective. 0
mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x23A34543C): Timer Starts Wakeups Next Retrans 1 0 0x0 TimeWait 0 0 0x0 AckHold 12798 0 0x0 SendWnd 0 0 0x0 KeepAlive 32770 0 0x23A353E9C GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 iss: 3904303256 irs: 2600288481 snduna: 3904303257 rcvnxt: 2617065699 sndnxt: 3904303257 rcvwnd: 3976 sndwnd: delrcvwnd: 4128 152
SRTT: 37 ms, RTTO: 1837 ms, RTV: 1800 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms Flags: passive open, retransmission timeout, keepalive running nagle, path mtu capable, gen tcbs Datagrams (max data segment is 536 bytes): Rcvd: 32771 (out of order: 0), with data: 32768, total data bytes: 16777216 Sent: 30722 (retransmit: 0), with data: 0, total data bytes: 0
In problem cases, the time taken will vary to be greater than the benchmark shown and Rcvd "out of order" at the Receiver-End. Advise: to keep stats of benchmarks so that you know what is "normal". Don't worry about seeing 536 bytes or 1436 bytes as the TCP MSS size. This will affect throughput but the end devices are configured possibly not to do MTUD or just don't advertise any MSS. This is not a fault in the network or in the end device, just an option. Reason for using 6509 and not GSR is that 6509 is within a VRF/VPN and you need to prove the performance delivered to end systems. No use telling end user that "the core network is OK". 6509, 7200, 7500, 12000 have TTCP available, 3640: no TTCP
July 10
Advanced Service
158
Useful MIBs and how to poll them

In this test nodes are configured to accept snmp from 172.17.18.X. Be careful not to ask for too large a chunk of MIB. Access the server and perform the command showed as follows:
root@server01 # cd /opt/apps/InCharge6/IP/smarts/bin
This is an example of walking the RFC1573/RFC2233 ifMIB "interface MIB". Smarts s/w includes its own Solaris executable snmp tools called "sm_XXXXX". In our case we want to get back a formatted report of parts of a node's MIB tree. "mibwalk" is not an SNMP command but is a sequence of "snmp-get-next" commands and "get-bulk" commands In the example we are using community j8fyxjnh. We are NOT using SNMPv3 authentication and engine-ids. We are using snmpv2c. We ask for a walk of an OID value and the SNMP gets will make the target box (172.17.0.5) respond with all the subordinate fields including ifName and ifHCInOctets etc. Server will have created 3 files using the IP-address and a suffix: <node>.walk includes hex of character strings = difficult for human to read <node>.snap includes the format of each variable (eg COUNTER-32 for 32-but counter, COUNTER-64 for HC counters) <node>.mimic (easiest for human to read)
./sm_snmpwalk --community=j8fyxjnh --oid=.1.3.6.1.2.1.31 Saving MIB walk to file(s) '172.17.0.5.walk' '172.17.0.5.mimic' '172.17.0.5.snap' ... End of MIB walk 172.17.0.5
Now we want to display the results but to understand we need to know the variables represent. For this you need to display the particular MIB's OID file. This is the ifName
root@server01 # cat 172.17.0.5.mimic | more .1.3.6.1.2.1.31.1.1.1.1.1: Et0 .1.3.6.1.2.1.31.1.1.1.1.2: PO0/0 .1.3.6.1.2.1.31.1.1.1.1.3: PO0/1 .1.3.6.1.2.1.31.1.1.1.1.4: PO0/2 .1.3.6.1.2.1.31.1.1.1.1.5: PO0/3 .1.3.6.1.2.1.31.1.1.1.1.6: AT1/0 .1.3.6.1.2.1.31.1.1.1.1.7: AT1/1 .1.3.6.1.2.1.31.1.1.1.1.8: AT1/2 .1.3.6.1.2.1.31.1.1.1.1.9: AT1/3 .1.3.6.1.2.1.31.1.1.1.1.10: AT1/4 .1.3.6.1.2.1.31.1.1.1.1.11: AT1/5 .1.3.6.1.2.1.31.1.1.1.1.12: AT1/6 <snip>
Note that each interface has its own ifName Interface of index 3.
Value of the query In this case it is ifName value for interface index 9. In this case it is the ATM 1/3 This is the ifHCInOctest
July 10
Advanced Service
159
.1.3.6.1.2.1.31.1.1.1.6.1: 186302666 .1.3.6.1.2.1.31.1.1.1.6.2: 0 .1.3.6.1.2.1.31.1.1.1.6.3: 0 .1.3.6.1.2.1.31.1.1.1.6.4: 0 .1.3.6.1.2.1.31.1.1.1.6.5: 0 .1.3.6.1.2.1.31.1.1.1.6.6: 0 .1.3.6.1.2.1.31.1.1.1.6.7: 0 .1.3.6.1.2.1.31.1.1.1.6.8: 0 .1.3.6.1.2.1.31.1.1.1.6.9: 0 .1.3.6.1.2.1.31.1.1.1.6.10: 0 .1.3.6.1.2.1.31.1.1.1.6.11: 19342489088 .1.3.6.1.2.1.31.1.1.1.6.12: 0 .1.3.6.1.2.1.31.1.1.1.6.13: 0 .1.3.6.1.2.1.31.1.1.1.6.14: 6611579242127 .1.3.6.1.2.1.31.1.1.1.6.15: 4771349347637 .1.3.6.1.2.1.31.1.1.1.6.16: 1236953229021
Interface of index 1.
Interface of index 14.
Value of the query In this case it is ifHCInOctest value for interface index 16.
You can check it using a Cisco tool: Cisco web page Login Support Tools&Resources SNMP Object Navigator enter <OID string> http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en Then, look for the OID file to tell what each variable OID number means. Many MIB variables are based on ifIndex, each main and subinterface has a unique ifIndex, you need to know which ifIndex = what interface ask the router.
PE5-PEXKS02# sh snmp mib ifmib ifindex gig 3/0/0 Interface = GigabitEthernet3/0/0, Ifindex = 14
Poll the ifName MIB to obtain the ifIndex values

root@server01 # ./sm_snmpwalk --community=j8fyxjnh -oid=.1.3.6.1.2.1.31.1.1.1.1 172.17.0.5 Saving MIB walk to file(s) '172.17.0.5.walk' '172.17.0.5.mimic' '172.17.0.5.snap' ... End of MIB walk root@server01 # cat 172.17.0.5.mimic | more .1.3.6.1.2.1.31.1.1.1.1.1: Et0 .1.3.6.1.2.1.31.1.1.1.1.2: PO0/0 .1.3.6.1.2.1.31.1.1.1.1.3: PO0/1 .1.3.6.1.2.1.31.1.1.1.1.4: PO0/2 .1.3.6.1.2.1.31.1.1.1.1.5: PO0/3 .1.3.6.1.2.1.31.1.1.1.1.6: AT1/0 .1.3.6.1.2.1.31.1.1.1.1.7: AT1/1 .1.3.6.1.2.1.31.1.1.1.1.8: AT1/2 .1.3.6.1.2.1.31.1.1.1.1.9: AT1/3 .1.3.6.1.2.1.31.1.1.1.1.10: AT1/4 .1.3.6.1.2.1.31.1.1.1.1.11: AT1/5 July 10
Advanced Service
160
.1.3.6.1.2.1.31.1.1.1.1.12: .1.3.6.1.2.1.31.1.1.1.1.13: .1.3.6.1.2.1.31.1.1.1.1.14: .1.3.6.1.2.1.31.1.1.1.1.15:
AT1/6 AT1/7 Gi3/0/0 Gi3/0/1
The server tools are very comprehensive:

root@server01 # ./sm_snmpwalk -help Usage: sm_snmpwalk [options...] <node> Arguments: * <node> Host or IP address. Options: --fmt=<format> Output format, one of "walk", "mimic", "snap" or "all"; default "all". Also -w, -m , -n or -a. --timeout=<num> Timeout, in milliseconds; default 5000 (5 seconds). Also -t <num>. --retries=<num> Number of Retries; default 5. Also -r <num>. --community=<name> Community string; default "public". Also -c <name>.
To obtain every MIB from the target, don't specify the oid
root@server01 #./sm_snmpwalk --community=j8fyxjnh 172.17.0.5
Files will be large:

root@server01 # ls -l 172.17.0.5* -rw-r--r-1 root other 3590905 Mar 21 11:15 172.17.0.5.mimic -rw-r--r-1 root other 4207167 Mar 21 11:15 172.17.0.5.snap -rw-r--r-1 root other 3548827 Mar 21 11:15 172.17.0.5.walk
More technical information about SNMP and MIB: http://www.cisco.com/en/US/tech/tk648/tk362/tech_white_papers_list.html http://carsten.familie-doh.de/mibtree/root.html http://www.snmpsource.com/ http://www.stllinux.org/meeting_notes/1996/1017/sld008.html
July 10
Advanced Service
161
Appendix II
Configuration used in lab

PE4
service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers ! hostname PE-4 ! boot-start-marker boot-end-marker enable secret 5 $1$HUkw$FgrxXJK0CW1oyylI8y3vJ0 ! ip subnet-zero ip routing protocol purge interface ip cef no ip domain-lookup ip vrf VPN rd 25135:133001804 route-target export 25135:18 route-target export 212.183.144.1:18 route-target import 25135:18 route-target import 212.183.144.1:18 ! mpls label protocol ldp mpls ldp neighbor 172.17.0.2 password 7 00071A150754 mpls ldp neighbor 172.17.0.5 password 7 05080F1C2243 mpls traffic-eng tunnels mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface Loopback0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 0 mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000 mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel mesh tunnel-num min 1 max 999 tag-switching tdp router-id Loopback0 ! July 10
Advanced Service
162
key chain ISIS key 1 key-string 7 1043101D0A10 ! interface Loopback0 ip address 172.17.0.4 255.255.255.255 no ip directed-broadcast ! interface Loopback1 ip vrf forwarding VPN ip address 4.4.4.4 255.255.255.255 no ip directed-broadcast ! interface Auto-Template1 ip unnumbered Loopback0 no ip directed-broadcast tunnel destination access-list 41 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 4 4 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls traffic-eng fast-reroute tunnel mpls traffic-eng auto-bw collect-bw ! interface Serial0/0 description >>>> link to P2 ip address 172.19.24.2 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip no fair-queue isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial1/0 description >>>> link to PE5 ip address 172.19.45.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip isis metric 100 level-1 isis metric 640 level-2 isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 July 10
Advanced Service
163
interface Serial2/0 description >>>> link to CE1 no ip address no ip directed-broadcast no cdp enable xconnect 172.17.0.7 100 encapsulation mpls ! router ospf 1 vrf VPN router-id 4.4.4.4 log-adjacency-changes area 0 sham-link 4.4.4.4 5.5.5.5 redistribute bgp 25135 metric 60 metric-type 1 subnets route-map vpn network 10.0.0.0 0.255.255.255 area 0 ! router isis net 10.0000.0000.0004.00 is-type level-2-only authentication mode md5 level-2 authentication key-chain ISIS ispf level-2 metric-style wide external overload signalling set-overload-bit on-startup 180 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 ! router bgp 25135 bgp always-compare-med no bgp default ipv4-unicast bgp log-neighbor-changes bgp deterministic-med bgp bestpath med missing-as-worst timers bgp 10 30 neighbor mpbgp peer-group neighbor mpbgp remote-as 25135 neighbor mpbgp password 7 070C285F4D06 neighbor mpbgp update-source Loopback0 neighbor 172.17.0.8 peer-group mpbgp neighbor 172.17.0.9 peer-group mpbgp ! address-family vpnv4 neighbor mpbgp activate July 10
Advanced Service
164
neighbor mpbgp send-community both neighbor 172.17.0.8 peer-group mpbgp neighbor 172.17.0.9 peer-group mpbgp exit-address-family ! address-family ipv4 vrf VPN redistribute ospf 1 vrf VPN maximum-paths import 4 no auto-summary no synchronization network 4.4.4.4 mask 255.255.255.255 route-map metric exit-address-family ! ip classless ip rsvp signalling initial-retransmit-delay 750 ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction ! ip prefix-list vpn seq 5 permit 4.4.4.4/32 ip prefix-list vpn seq 10 permit 5.5.5.5/32 ip prefix-list vpn seq 15 permit 6.6.6.6/32 ip prefix-list vpn seq 20 permit 7.7.7.7/32 ! ip access-list standard all permit 10.0.0.0 0.255.255.255 access-list 1 permit 172.17.0.0 0.0.0.255 access-list 41 permit 172.17.0.5 access-list 41 permit 172.17.0.7 access-list 41 permit 172.17.0.6 route-map metric permit 10 set metric 100 ! route-map vpn deny 10 match ip address prefix-list vpn ! route-map vpn permit 20 ! control-plane ! line con 0 exec-timeout 60 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 privilege level 15 logging synchronous no login end July 10
Advanced Service
165
P2
version 12.0 service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers ! hostname P2 ! boot-start-marker boot-end-marker ! no logging on enable secret 5 $1$uTdy$GJINJn/02YFW3fT104OG5. ! ip subnet-zero ip routing protocol purge interface ip cef no ip domain-lookup mpls label protocol ldp mpls ldp neighbor 172.17.0.4 password 7 00071A150754 mpls ldp neighbor 172.17.0.3 password 7 094F471A1A0A mpls ldp neighbor 172.17.0.31 password 7 0822455D0A16 mpls ldp neighbor 172.17.0.1 password 7 00071A150754 mpls traffic-eng tunnels mpls traffic-eng auto-tunnel backup mpls traffic-eng auto-tunnel backup config unnumbered-interface Loopback0 mpls traffic-eng auto-tunnel backup timers removal unused 3600 0 mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000 mpls traffic-eng auto-tunnel mesh mpls traffic-eng auto-tunnel mesh tunnel-num min 1 max 999 mpls traffic-eng reoptimize timers frequency 30 tag-switching tdp router-id Loopback0 ! key chain ISIS key 1 key-string 7 110400011815 ! interface Loopback0 ip address 172.17.0.2 255.255.255.255 no ip directed-broadcast ! interface Serial0/0 description >>>> link to P1 ip address 172.19.12.2 255.255.255.252 July 10
Advanced Service
166
no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip no fair-queue isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial1/0 description >>>> link to P3 ip address 172.19.23.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels mpls traffic-eng backup-path Tunnel40 tag-switching ip isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial2/0 description >>>> link to P31 ip address 172.19.31.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip fair-queue 64 256 63 isis metric 1000 level-2 isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! interface Serial3/0 description >>>> link to PE4 ip address 172.19.24.1 255.255.255.252 no ip directed-broadcast ip router isis mpls traffic-eng tunnels tag-switching ip fair-queue 64 256 63 isis authentication mode md5 isis authentication key-chain ISIS ip rsvp bandwidth 155000 155000 ! router isis net 10.0000.0000.0002.00 is-type level-2-only July 10
Advanced Service
167
authentication mode md5 level-2 authentication key-chain ISIS ispf level-2 metric-style wide level-2 external overload signalling set-overload-bit on-startup 180 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 ! ip classless ip rsvp signalling initial-retransmit-delay 750 ip rsvp signalling refresh reduction ack-delay 500 ip rsvp signalling refresh reduction ! control-plane line con 0 exec-timeout 60 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 privilege level 15 logging synchronous no login ! no cns aaa enable end
RR1
service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service sequence-numbers ! hostname RR1 ! boot-start-marker boot-end-marker July 10
Advanced Service
168
enable secret 5 $1$tOku$A7DT/0Bv7IvSGM9psLuiU/ ! ip subnet-zero ip routing protocol purge interface ip cef no ip domain-lookup mpls label protocol ldp mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 30 tag-switching tdp router-id Loopback0 ! key chain ISIS key 1 key-string 7 110400011815 ! interface Loopback0 ip address 172.17.0.8 255.255.255.255 no ip directed-broadcast ! interface Serial0/0 description >>>> link to P1 ip address 172.16.18.2 255.255.255.252 no ip directed-broadcast ip router isis tag-switching ip no fair-queue isis authentication mode md5 isis authentication key-chain ISIS ! router isis net 10.0000.0000.0008.00 is-type level-2-only authentication mode md5 level-2 authentication key-chain ISIS ispf level-2 metric-style wide level-2 external overload signalling set-overload-bit on-startup 180 max-lsp-lifetime 65535 lsp-refresh-interval 65000 spf-interval 5 1 50 prc-interval 5 1 50 lsp-gen-interval 5 1 50 log-adjacency-changes mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 passive-interface Loopback0 ! router bgp 25135 July 10
Advanced Service
169
bgp always-compare-med no bgp default ipv4-unicast bgp cluster-id 1 bgp log-neighbor-changes bgp deterministic-med bgp bestpath med missing-as-worst timers bgp 10 30 neighbor mpbgp_client peer-group neighbor mpbgp_client remote-as 25135 neighbor mpbgp_client password 7 104D000A0618 neighbor mpbgp_client update-source Loopback0 neighbor 172.17.0.4 peer-group mpbgp_client neighbor 172.17.0.5 peer-group mpbgp_client neighbor 172.17.0.6 peer-group mpbgp_client neighbor 172.17.0.7 peer-group mpbgp_client neighbor 172.17.0.9 remote-as 25135 neighbor 172.17.0.9 password 7 02050D480809 neighbor 172.17.0.9 update-source Loopback0 ! address-family ipv4 neighbor mpbgp_client activate no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor mpbgp_client activate neighbor mpbgp_client send-community both neighbor mpbgp_client route-reflector-client neighbor 172.17.0.4 peer-group mpbgp_client neighbor 172.17.0.5 peer-group mpbgp_client neighbor 172.17.0.6 peer-group mpbgp_client neighbor 172.17.0.7 peer-group mpbgp_client neighbor 172.17.0.9 activate neighbor 172.17.0.9 send-community both exit-address-family ! ip classless control-plane line con 0 exec-timeout 60 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 privilege level 15 logging synchronous no login end July 10
Advanced Service
170
Glossary
Term AAL ATM AToM BGP CBR CE CEF CLI CLNS Control Plane cSPF Data Plane / Forwarding Plane DiffServ FEC FIB FRR IETF IGP IntServ IP IS-IS Label LDP LFIB LSP LSR MP-BGP MPLS N-HOP NLRI NN-HOP OSPF P PE Definition ATM Adaptation Layer Asynchronous Transfer Mode Any Transport over MPLS Border Gateway Protocol Constraint-Based Routing Customer Edge Router Cisco Express Forwarding Cisco latest packet switching method. Command-Line Interface Connection Less Network Service Where control information, such as routing and label information is exchanged. Constrained Shortest Path First Where the actual forwarding occurs. This can only exist after the control plane has been established. Differentiated Services (One of the Model defined in QoS Architecture) Forward Equivalence Class Forwarding Information Base The table that is created by enabled CEF. Fast Re-Route Internet Engineering Task Force Interior Gateway Protocol Integrated Services (One of the Model defined in QoS Architecture) Internet Protocol Intermediate System to Intermediate System MPLS header that is used for switch a packet Label Distribution Protocol Label Forwarding Information Base The table where the various label bindings that an LSR receives over the LDP protocol are stored. It forms the basis of populating the FIB and LFIB tables. Label Switch Path Label Switch Router Multi-Protocol BGP Multi Protocol Label Switching Next-Hop Designation for Link Protection in FRR Network Layer Reachability Information Next-Next-Hop Designation for Node Protection in FRR Open Shortest Path First Provider Router Provider Edge Router
July 10
Advanced Service
171
PHP RIP RD RSVP SNPA TDP TE TTL VPN VRF
Penultimate Hop Popping Routing Information Base Route Distinguished Resource Reservation Protocol Sub-network Points of Attachment Tag Distribution Protocol Traffic Engineering Time To Live Virtual Private Network Virtual Route Forwarding Please refer to the CCO Internetworking Terms and Acronyms Guide at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm for additional terms.
July 10
Advanced Service
172
References
Book Cisco Press Traffic Engineer with MPLS Eric Osborne and Ajay Simha IP Quality of Service
Srinivas Vegesna Cisco Official Training Course MPLST v2.0 - Implementing Cisco MPLS Traffic Engineering and Other Features 2004 MPLS v2.2 - Implement Cisco MPLS
2006 RFC (http://rfc.net/rfc<number>.html) RFC2702 Requirements for Traffic Engineering Over MPLS RFC3473 Generalised Multi-Protocol Label Switching (GMPLS) Signalling RSVP-TE Extensions RFC4205 ISIS Extensions in Support of Generalized Multi-Protocols Label Switching RFC4420 Encoding of Attributes for MPLS LSP Establishment using RSVP-TE RFC2283 Multiprotocol Extensions for BGP-4 RFC2858 Multiprotocol Extensions for BGP-4 URL Configuring MPLS Label Switching http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1831/products_configuration_guide_ chapter09186a00800ca6ce.html Configuring a Basic MPLS VPN
http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_configuration_example09186 a00800a6c11.shtml BGP Multipath Load Sharing in an MPLS-VPN
http://www.cisco.com/en/US/partner/products/ps6017/products_feature_guide09186a00804181b 4.html Configuring a MPLS TE using IS-IS
http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_configuration_example09186 a0080093fcb.shtml
July 10
Advanced Service
173
RSVP Extension for MPLS/TE Signalling - RFC3473
http://rfc.net/rfc3473.html RSVP Extension for MPLS/TE Signalling - RFC4208
http://rfc.net/rfc4208.html FRR - Fast ReRoute - Link and Node Protection
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a 0080264560.html MPLS Traffic Engineering - Autotunnel Mesh Group
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s29/ gsamg2.pdf MPLS VPN Inter AS Solution
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a 0080265adc.html MPLS Traffic-eng configuration guide
http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapte r09186a008017cf43.html http://www.cisco.com/en/US/products/ps6922/products_command_reference_chapter09186a008 06c0fd1.html#wp1021058
July 10
Advanced Service
174
About This MPLS - Troubleshooting Guide

Author: Change Authority: Reference Number: Lizabete Ponte Advanced Service Lizabete Ponte
History
Version No. 1.0 Issue Date July 2010 Status 1st version Reason for Change First release
Review
Reviewers Details Version No. Date
Change Forecast: High This document will be kept under revision control.
July 10
Advanced Service
175

MPLS - Troubleshooting Guide

Uploaded by

Copyright:

Available Formats

MPLS - Troubleshooting Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MPLS - Troubleshooting Guide

Uploaded by

Copyright:

Available Formats

TM

Part 1: Technology Description

MPLS and MPLS/VPN Introduction

What Are MPLS Labels?

What Are MPLS Label Operations?

What Are MPLS VPNs?

What Are The Interactions Between MPLS Application?

What Is The MPLS VPN Architecture?

What Are Route Distinguishers (RD)?

What Are Route-Targets (RTs)?

In an IP version 6 implementation, the theory is the same.

RTs: How Do They Work?

How Have Complex VPNs Redefined The Meaning of VPNs?

How Is The Routing Between CE-PE and PE-PE?

Figure 4 - Non BGP Route Propagation - Outbound

Figure 5 - Non BGP Route Propagation - Inbound

For troubleshooting we will follow these steps which are in detail in

What Is Multi-VRF CE (VRF-Lite)?

What Are the Effects of MPLS VPNs on Packet Forwarding?

MPLS Traffic Engineering Introduction

What is MPLS TE?

Why use MPLS TE?

How does MPLS TE optimise network utilisation?

How does MPLS TE handle unexpected congestion?

How does MPLS TE handle unexpected link and node failures?

CBR (Constraint-Based Routing)

Fast Reroute (FRR)

Middle Point Points

Figure 7 - Backup Tunnel - Node Protection

Figure 8 - Backup Tunnel - Link Protection Link Protected Next-Hop

Auto Tunnel Mesh and Backup

Benefits of Autotunnel Mesh Group

Why implement AToM?

How AToM works?

Figure 10 - AToM - frame forwarding

Part 2: Troubleshooting Methodology

Essential MPLS/VPN configs

MPLS TE FRR configuration

Essential AToM configs

Part 3: Some MPLS Commands

ip cef mpls label protocol ldp no tag-switching ip propagate-ttl forwarded

tag-switching tdp router-id loopback0

interface <physical interface> tag-switching ip

maximum route <max> <warning threshold>

interface <physical interface> ip vrf forwarding <vrf-name>p

ip address <address> <mask>

bgp bestpath med missing-as-worst

neighbor neighbor neighbor neighbor neighbor

neighbor <peer-group-name> route-reflector-client

neighbor <ip-address> prefix-list <name> [in|out] neighbor <ip-address> allowas-in <#>

route-map <name> [permit|deny] <seq> match ... set ...

mpls traffic-eng tunnels mpls traffic-eng reoptimize timers frequency 3600

no mpls traffic-eng auto-bw timers frequency 0

mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000

interface Auto-Template1 ip unnumbered Loopback0 tunnel destination access-list 41

tunnel mpls traffic-eng interface down delay 0

A Simplistic Topology to be used as an example for the Troubleshooting

172.17.0.6 s2/0 PE6

30 0/ 0. .3 000 19 1 2. = 17 tric e M s1/0

s2/0 s1/0 s0/0