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 Advanced Service 2

A printed copy of this document is considered uncontrolled.
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

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

Figures
Figure 1 – Information Base 9
Figure 2 - Interactions between MPLS applications 11
Figure 3 – Routing look up using CEF and BGP prefixes 12
Figure 4 - Non BGP Route Propagation - Outbound 15
Figure 5 - Non BGP Route Propagation - Inbound 15
Figure 6 - Primary Tunnel Path 21
Figure 7 - Backup Tunnel - Node Protection 21
Figure 8 - Backup Tunnel - Link Protection 22
Figure 9 - AToM - Label exchanging 24
Figure 10 - AToM - frame forwarding 25
Figure 11 - Topology used in lab for capturing output 39
Figure 12 - Lab topology for LINK and NODE failures scenarios 140

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

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.

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.

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.
 Cell-mode MPLS is MPLS over ATM:
- The fields in the ATM header are used as the label.
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:
 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.

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:
 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.

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.
1
It can‟t be learnt via BGP, otherwise you will have an unstable network with flapping prefixes on routing table.

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.
2
In an IP version 6 implementation, the theory is the same.

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).

Figure 4 - Non BGP Route Propagation - Outbound
Figure 5 - Non BGP Route Propagation - Inbound
10 8
6
9
For troubleshooting we will follow these steps which are in detail in

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).
 BGP next-hops announced in IGP must not be summarised in the core network.
- Summarisation breaks the LSP tunnel.
 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 Don‟t 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

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 doesn‟t 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 wouldn‟t 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.

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 didn‟t 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 link-
state 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 Dijkstra‟s 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.

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 Internet‟s 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.

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.

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 N-
Hop 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

P1
Head End
PE4 P2 P3 PE6
Middle Points
Point 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
PE4 P2 P3 PE6
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).

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.

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.
3
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.

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.

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 de-
encapsulate 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.

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).

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.

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.

TM
Part 3: Some MPLS Commands

ip cef IP cef must be enabled for the router to be able to build the label database.
mpls label protocol ldp It enables ldp to be used as a default label protocol on all interfaces which have
mpls enabled.
no tag-switching ip propagate-ttl forwarded (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.
tag-switching tdp router-id loopback0 (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 <physical interface> Interface configuration mode

tag-switching ip It enables mpls on interface applying the label protocol enabled in global
configuration mode in it is not explicit specified under interface
configuration mode.
ip vrf <vrf-name> It creates a VRF.

rd <AS>:<number> It creates a local virtual routing and forwarding tables a VRF.
route-target export <AS>:<value> It creates a BGP extended community. This specifies a set of prefixes should be
imported in remote PEs.
route-target import <AS>:<value> It specifies a set of prefixes based on extended community value should be
imported to local VRF database.
export-map <route-map> (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.
import-map <route-map> (Optional) It refines the selection on prefixes should be imported to local VRF
based on route-map configuration. The prefixes should attend the route-
target 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.
maximum route <max> <warning threshold> (Optional) It limits the number of prefixes imported to local VRF.
31
July 10 Advanced Service
ip vrf forwarding <vrf-name>p It enables mpls on interface applying the label protocol enabled in global
configuration mode in it is not explicit specified under interface
configuration mode.
ip address <address> <mask> 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.
MP-BGP configuration
route bgp 25135 Create/enter BGP/MP-BGP processes
bgp always-compared-med It enables the comparison of MED for paths from neighbours in different
autonomous systems.
no bgp default ipv4-unicast 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.
bgp log-neighbor-changes It enables logging of BGP neighbor status changes (up or down) and resets for
troubleshooting network connectivity problems and measuring network
stability.
bgp deterministic-med 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.
bgp bestpath med missing-as-worst By default, Cisco assigns a value of 0 to routes which didn‟t 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)
timers bgp 10 30 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.
neighbor <peer-group-name> peer-group It creates a peer-group (neighbour configuration template)
neighbor <peer-group-name> remote-as <AS> It assigns the neighbour‟s AS for neighbours assigned to this peer-group.
neighbor <peer-group-name> password <pwd> It enables a MD-5 password
neighbor <peer-group-name> update-source loopback 0 It defined the IP source address in all BGP packet created by local router.
neighbor <neighbor-ip> peer-group <peer-group-name> It assigns a BGP neighbour to a peer-group template.
32
address-family vpnv4 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.
neighbor <peer-group-name> activate It activate the BGP session.
neighbor <peer-group-name> send-community both It enables the local router to send the standard community and extended
community (RT, SOO, OSPF information, and so on).
neighbor <peer-group-name> advertisement-interval 0 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.
neighbor <peer-group-name> route-reflector-client 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.
neighbor <neighbor-ip> peer-group <peer-group-name> It assigns a BGP neighbour to a peer-group template.
PE-CE configuration
ip route vrf <vrf-name> <network> <mask> <exit-interface> <next-hop> It defines a static route in a vrf context.
router ospf <id> vrf <vrf-name> It defines an OSPF configuration in a vrf context.
redistribute bgp 25135 subnets You should redistribute BGP prefixes in order to local CE learns remote
network <range> <wildcard> area <area-id> prefixes. Do NOT forget the keyword subnets, otherwise the
...
subnetworks will not be redistributed, only classfull prefixes (such as
10.0.0.0/8).
router bgp 25135 It defines a BGP configuration in a vrf context.
address-family ip vrf <vrf-name>
neighbor <ip-address> remote-as <as>
neighbor <ip-address> update-source <interface>
neighbor <ip-address> route-map <name> [in|out] It defines an incoming or outgoing filter based on route-map configuration.
neighbor <ip-address> filter-list <as-path-acl-#> [in|out] It defines an incoming or outgoing filter based on as-path access-list
configuration.
neighbor <ip-address> prefix-list <name> [in|out] It defines an incoming or outgoing filter based on prefix-list
neighbor <ip-address> allowas-in <#> 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.
redistribute [static|connected] It redistributes the vrf prefixes into MP-BGP vrf database.
redistribute ospf <id> vrf<name> match internal external1 external2
default-information originate It allows redistributing a default-route in routing table onto BGP database.
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> It defines a set of rules/selection based on BGP as-path attribute information.
...
ip prefix-list <name> [permit|deny]<prefix>/<len>{ge<value>}{le<value>} 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.
route-map <name> [permit|deny] <seq> It defines a set of rules/selection based on many values/attributes.
match ...
set ...
34
mpls traffic-eng tunnels It enables MPLS traffic engineer tunnel on a device.
mpls traffic-eng reoptimize timers frequency 3600 (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.
no mpls traffic-eng auto-bw timers frequency 0 (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).
mpls traffic-eng reoptimize events link-up (Optional) It turns on automatic reoptimisation of MPLS- TE when certain
events occur, such as when an interface becomes operational.
no mpls traffic-eng topology holddown sigerr 0 (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.
mpls traffic-eng auto-tunnel mesh It enables autotunnel mesh group globally.

mpls traffic-eng auto-tunnel min 1 max 999 (Optional) It configures a range of mesh primary tunnel interface numbers.
Valid values are from 1 to 65535.
mpls traffic-eng auto-tunnel backup It enables the capability of automatically building NHOP and NNHOP backup
tunnels.
mpls traffic-eng auto-tunnel backup config unnumbered-interface (Optional) It enables IP processing without an explicit address.
loopback 0
mpls traffic-eng auto-tunnel backup timers removal unused 3600 3600 (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).
mpls traffic-eng auto-tunnel backup tunnel-num min 60000 max 64000 (Optional) It configures the range of mesh secondary tunnel interface numbers.
Valid values are from 1 to 65535.
35
mpls traffic-eng tunnels It enables MPLS traffic engineer on this interface.
ip rsvp bandwidth 155000 155000 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.
router isis ISIS configuration mode

is-type level-2-only It enable this router creates level-2 adjacency only (backbone).
metric-style wide It configures a router to generate and accept only new-style TLVs (To enable to
propagate TE information).
mpls traffic-eng router-id Loopback0 It specifies the traffic engineering router identifier for the node to be the IP
address associated with interface loopback0.
mpls traffic-eng level-2 It turns on MPLS traffic engineering for ISIS level-2 (backbone area).
ip rsvp signalling initial-retransmit delay 760 (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.
ip rsvp signalling refresh reduction ack-delay 500 (Optional) It configures the maximum amount of time that a RSVP configured
router holds on to an ACK message before sending it.
ip rsvp signalling refresh reduction (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
interface Auto-Template1 It creates a template interface. The interface number could be from the value of
1 to 25.
ip unnumbered Loopback0 It enables IP processing on an interface without assigning an explicit IP address
to the interface.
tunnel destination access-list 41 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.
tunnel mode mpls traffic-eng It sets the MPLS TE encapsulation mode for the tunnel interface.
tunnel mpls traffic-eng autoroute announce It specifies to send data traffic to this tunnel since the IP destination is the IP of
Tail End or beyond of it.
tunnel mpls traffic-eng priority 4 4 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 pre-
empted 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.
tunnel mpls traffic-eng bandwidth 100 To configure bandwidth required for an MPLS traffic engineering tunnel. The
default bandwidth required is 0.
tunnel mpls traffic-eng path-option 1 dynamic 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.
tunnel mpls traffic-eng record-route (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.
tunnel mpls traffic-eng fast-reroute It enables an MPLS TE tunnel to use an established backup tunnel if there is a
link or node failure.
tunnel mpls traffic-eng auto-bw collect-bw 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 tunnel‟s bandwidth.
tunnel mpls traffic-eng interface down delay 0 It forces a tunnel to go down as soon as the headend router detects that the
label-switched path (LSP) is down.
37
AToM
interface atm <slot/port>.<sub-interface> point-to-point It creates a sub-interface
pvc <vpi>/<vci> l2transport It defines a PVC identification for this ATM circuit
encapsulation aal0 Defined the type of AAL layer on ATM, for this particular case uses AAL0
xconnect <peer-router-ip address> <vcid> encapsulation mpls It defines the AToM circuit when the <vcid> has to be same as configured on
remote PE.
38
A Simplistic Topology to be used as an example for the Troubleshooting
Figure 11 - Topology used in lab for capturing output
.Loopback 0
Interfaces
1st host of sub-network /30
Links which do not have ISIS metric specified
.
172.16.18.0/30
172.17.0.8
RR1
s0/0
...
s0/0
are using the default value (metric = 10)
172.17.0.1
30
.
172.17.7.83
6509-1
10
.4 0.31
.4 /
.
30
0 9.
12
.0
/ 30 s2/0
s1/0
P1
s3/0
1 72
.1
9.
13.
0/
.
172.17.8.51
6509-3
.
...
s1/0 /3 1 /3 10.33.31.4/30 s1/0
.
4.0 2. .0 s2/0
s2/0
.2 17 .3
6
19 s0/0 16
.
2. 2.
. .
s0/0
s2/0 172.17.0.4 17 172.17.0.2 172.17.0.3 17 172.17.0.6 s2/0
s0/0 s3/0 s3/0 s0/0
PE4 P2 s1/0 3 0 s1/0 P3 PE6
0/
s1/0 3.
s2/0 9 .2 s2/0 s1/0
1
2.
17
0 172.17.0.9
/3
.0
0 . 30 000
/3 19 1 RR2 0
.0 2. = /3
10
. 40.
31
M
4
. 6
19 =
2. ic
17 etr
0/
30
5. 40
M
e
19 1
2. =
17 tric
3
. 0
0/
30
1. 00 M
s2/0
e
.
17 tric
. .
s1/0
172.17.0.30
P30
s0/0
s0/0 172.19.29.8/30
s3/0 .1
32.
0/
30
2. ic
17 etr
M
.
19 =
.0 0
32 100
M
.
16 =
2. ic
17 etr
.0
/3
67 640
0
10
. 33
.3
1.
0/
30
16
7 2.
1
0
/3
.
0 172.16.130.0/30
. .
/3 0
s1/0 8 s2/0 s0/0 s2/0 7. s1/0
3. s0/0 13
. .
.5 .
19 19
172.17.0.5 2. s3/0 172.17.0.31 s1/0 172.17.0.32 s3/0 2. 172.17.0.7 /3
0
s0/0 17 s1/0 17 s0/0 .8
s2/0 .31
s2/0 PE5 P31 P32 PE7 .3
3
172.19.131.0/30
10
s1/0 s1/0
s0/0 s0/0
10.40.31.8/30
172.17.7.84 172.17.8.52
6509-2 6509-4
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 IP-Address Status Switching
Serial0/0 172.19.24.2 up CEF
Serial1/0 172.19.45.1 up CEF
Serial2/0 10.40.31.5 up CEF
Null0 unassigned up no CEF
Loopback0 172.17.0.4 up -
Loopback1 4.4.4.4 up -
Auto-Template1 unassigned up -
OSPF_SL0 unassigned down -
Tunnel1 unassigned up 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 IP Tunnel Operational
Serial0/0 Yes (ldp) 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:
:0 means per platform allocation.
172.17.0.4:0 (recommended mode of label
Discovery Sources: allocation in frame-mode).
Interfaces:
Serial0/0 (ldp): xmit/recv
LDP Id: 172.17.0.2:0
LDP Id: 172.17.0.5:0
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: Neighbour‟s Prefixes (all
Serial1/0, Src IP addr: 172.19.45.2 interfaces in global routing table).
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.17.0.2 172.19.23.1 172.19.31.1
172.19.24.1
It shows TCP connection status between neighbors. This defines either
172.17.0.2 neighbour is the
PE-4# sh mpl ldp bindings destionation of 172.17.0.2/32
tib entry: 172.16.18.0/30, rev 40 prefix, or this neighbour is in
local binding: tag: 30 MPLS border, beyond it it is
an IP network only (edge
remote binding: tsr: 172.17.0.2:0, tag: 28
LSR).
tib entry: 172.17.0.2/32, rev 8
local binding: tag: 16
remote binding: tsr: 172.17.0.2:0, tag: imp-null 172.17.0.4/32 is a Loopback 0
IP address, local ip address
prefix, so PE-4 is sending a
tib entry: 172.17.0.4/32, rev 4 POP label flag to its
local binding: tag: imp-null neighbours.
tib entry: 172.19.45.0/30, rev 5 Label to be
172.19.45,0/30 is a serial
local binding: tag: imp-null imposed
address which connects PE-4 to
remote binding: tsr: 172.17.0.5:0, tag: imp-null 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
[output omitted] 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
It shows the LIB (label control plane database).
Checking RIB
PE-4# sh ip route 172.17.0.2 and/or FIB this
Routing entry for 172.17.0.2/32 is the best path
Known via "isis", distance 115, metric 10, type level-2 to reach
Redistributing via isis 172.17.18.0/30
Each neighbour
advertises their own Last update from 172.19.24.1 on Serial0/0, 2d11h ago
labels. In this case PE- Routing Descriptor Blocks:
4 received two * 172.19.24.1, from 172.17.0.2, via Serial0/0
advertisements for
Route metric is 10, traffic share count is 1
172.16.18.0/30 prefix.
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
These labels It shows the RIB information (IP routing database).
should match
with the
information PE-4# sh mpl forwarding-table 172.16.18.0
provided in
Local Outgoing Prefix Bytes tag Outgoing Next Hop
LIB, as
showed above. tag tag or VC or Tunnel Id switched interface
30 28 172.16.18.0/30 0 Se0/0 point2point
It shows the LFIB (label data plane database).
Label to be
imposed in label
PE-4# sh ip cef 172.16.18.0 det data packet
172.16.18.0/30, version 29, epoch 0, cached adjacency to Serial0/0 going to serial
0 packets, 0 bytes 0/0 interface.
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}
July 10
PE-4# sh mpl forwarding-table
tag tag or VC or Tunnel Id switched interface
16 Pop tag 172.17.0.2/32 0 Se0/0 point2point
17 Pop tag 172.19.12.0/30 0 Se0/0 point2point
. . .
26 31 172.17.0.32/32 0 Se0/0 point2point
35 Untagged[T] 172.16.67.0/30 0 Tu2 point2point
. . .
43 Aggregate 4.4.4.4/32[V] 0
44 26 172.16.132.0/30 0 Se0/0 point2point
45 29 172.16.130.0/30 0 Se0/0 point2point
46 38 172.17.0.30/32 0 Se0/0 point2point
47 56 172.19.29.80/30 0 Se0/0 point2point
48 57 172.17.0.9/32 0 Se0/0 point2point
49 0 l2ckt(100) 161019 none point2point
. . .
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 VRF prefixes leart via remote
[output omitted] PE. (via MP-iBGP – AD=200).
AD
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/100] via 172.17.0.5, 13:42:19
O 172.17.8.84 [110/97] via 10.40.31.6, 02:36:04, Serial2/0
VRF prefixes leart via local
[output omitted] CE. (via CE-PE routing, in
this case OSPF). If it were
PE-4# sh ip bgp vpn vrf VPN label
learnt via eBGP the AD
would be 20.
Network Next Hop In label/Out label
Route Distinguisher: 25135:133001804 (VPN)
4.4.4.4/32 0.0.0.0 47/aggregate(VPN)
Label learnt via MP-BGP,
from MP-BGP neighbour.
5.5.5.5/32 172.17.0.5 nolabel/47
Path #1 172.17.0.5 nolabel/47
[output omitted] Label allocated locally and
172.17.8.84/32 172.17.0.5 52/58 advertise to all MP-BGP,
neighbours.
Path #2 172.17.0.5 52/58
10.40.31.6 52/nolabel
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
172.17.0.5 (metric 620) from 172.17.0.9 (172.17.0.9)
Path #3 Best Path.
mpls labels in/out 52/58 Path to be adverstised and to
Local populate the FIB/LFIB
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
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
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 Why it does not imposed
local tag: 52 labels?
via 10.40.31.6, Serial2/0, 0 dependencies
next hop 10.40.31.6, Serial2/0
tag rewrite with Se2/0, point2point, tags imposed {}

Path #1 Paths: (2 available, best #1, table VPN)
Not advertised to any peer
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
Path #2 Originator: 172.17.0.5, Cluster list: 0.0.0.1,

Best Path.
mpls labels in/out nolabel/47 Path to be adverstised and to
Local, imported path from 25135:133001805:5.5.5.5/32 populate the FIB/LFIB
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
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 Why it does imposed
tag information set, all rewrites owned labels in this case?
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)
tag rewrite with Tu1, point2point, tags imposed {57 47}
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 Default RD Interfaces
VPN 25135:133001804 Lo1
Se2/0
It shows the vrf list created locally and what interfaces belong to vrf.
PE-4# sh ip vrf int

Interface IP-Address VRF
Protocol
Lo1 4.4.4.4 VPN up
Se2/0 10.40.31.5 VPN 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
„^‟ : means line which starts
route-target export 212.183.144.1:18
with once space following by
route-target import 25135:18 route-target.
route-target import 212.183.144.1:18
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
It selects BGP prefixes which in as-path attribute
value starts with the AS value 25000. (This means
PE-4# sh ip as-path-access-list 100
the next AS hop to forward the path).
AS path access list 100
permit ^25000
It selects BGP prefixes which in as-path attribute is
permit ^$
empty (This means only prefixes created in local-AS).
PE-4# sh ip extcommunity-list
Extended community standard list 1
It selects MP-BGP prefixes which RT value is 1:1 or
permit RT:1:1
25135:133001804
permit RT:25135:133001804
July 10
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

C 4.4.4.4 is directly connected, Loopback1
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C 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 Any figures here
means the BGP
5 BGP extended community entries using 264 bytes of memory
connection is being
0 BGP route-map cache entries using 0 bytes of memory established. Active or
0 BGP filter-list cache entries using 0 bytes of memory Idle status means TCP
BGP using 8579 total bytes of memory connection issue.
BGP activity 37/4 prefixes, 100/21 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.33.31.10 4 1 5537 7182 636990 0 0 15:22:00 1
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
BGP capability been
Neighbor capabilities:
negotiated during
Route refresh: advertised and received(new) Open sent and
Address family IPv4 Unicast: advertised and received confirmed state.
[output omitted]
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
RD created locally
Network Next Hop Metric LocPrf Weight Path as there is a vrf
assigned to it.
Route Distinguisher: 25135:133001804 (default for vrf VPN)
*>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 ? RD learnt from MP-
* i 172.17.0.7 96 100 0 ? BGP neighbour as
[output omitted]
there is no vrf
assigned to it.
Route Distinguisher: 25135:133001805
*>i5.5.5.5/32 172.17.0.5 100 100 0 i
* i 172.17.0.5 100 100 0 i
*>i10.40.31.0/30 172.17.0.5 96 100 0 ?
* i 172.17.0.5 96 100 0 ?
[output omitted]
PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 adv

Network Next Hop Metric LocPrf Weight Path
*> 10.33.31.0/30 10.33.31.10 96 32768 ?
*> 10.33.31.4/30 10.33.31.10 144 32768 ?
*> 10.33.31.8/30 0.0.0.0 0 32768 ?
*>i10.40.31.0/30 172.17.0.5 96 100 0 ?
*>i10.40.31.4/30 172.17.0.4 0 100 0 ?
*>i10.40.31.8/30 172.17.0.5 0 100 0 ?
*> 172.17.8.52/32 10.33.31.10 49 32768 ? Total of prefixes
*>i172.17.8.84/32 172.17.0.5 49 100 0 ? adverstised to this
neighbour
Total number of prefixes 8
PE-7# sh ip bgp vpn vrf VPN neighbor 10.33.31.10 route

*> 10.33.31.0/24 10.33.31.10 0 0 1 i Total of prefixes
learnt (and accept)
Total number of prefixes 1 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 PID Area IP Address/Mask Cost State Nbrs F/C
Se2/0 1 0 10.40.31.5/30 48 P2P 1/1
Sl0 1 0 0.0.0.0/0 1 DOWN 0/0
PE-4# sh ip ospf neighbo
Neighbor ID Pri State Dead Time Address Interface

172.17.8.83 0 FULL/ - 00:00:38 10.40.31.6 Serial2/0
In P2P link we should

PE-4# sh ip ospf database
expect FULL state. In
LSA 1 (router links), we should broadcast link, if the local
OSPF Router with ID (4.4.4.4) (Process ID 1) router is neither a DR nor
expect one LSA per router in
an Area. The Link ID is the BDR it could be 2-way
router-id. In this case there are Router Link States (Area 0)
4 routers in Area 0
Link ID ADV Router Age Seq# Checksum Link count
4.4.4.4 4.4.4.4 1354 0x80000074 0xA3C8 2
5.5.5.5 5.5.5.5 1991 0x80000076 0xED6B 2
172.17.8.83 172.17.8.83 34 0x80000075 0xCF4 5
172.17.8.84 172.17.8.84 1887 0x80000076 0x6C84 5
LSA 2 (network links),
we this example there
LSA 3 (summary Net links), Summary Net Link States (Area 0) is not network link in
we should expect one LSA per area 0. If we have, it
prefix which comes from would be one per
another OSPF area. Link ID ADV Router Age Seq# Checksum
broadcast link. The
10.33.31.3 4.4.4.4 1098 0x8000001D 0x15F4
Link-ID is the IP prefix Link ID is the DR‟s
10.33.31.3
Adv Router is the ABR. 5.5.5.5 726 0x8000001D 0xF60F router-id.
10.33.31.4 4.4.4.4 1618 0x8000001D 0xBFD
P.S.: Summary links DOES not
mean OSPF prefixes10.33.31.4 5.5.5.5 466 0x80000073 0x406E
summared. 10.33.31.8 4.4.4.4 1618 0x8000001D 0xE222
10.33.31.8 5.5.5.5 466 0x80000073 0x1892
172.17.8.51 4.4.4.4 1618 0x8000001D 0xC199LSA 5 (AS External links), we
172.17.8.51 5.5.5.5 466 0x80000073 0xF60Ashould expect one LSA per
172.17.8.52 4.4.4.4 1618 0x8000001D 0xB7A2prefix which comes from
172.17.8.52 5.5.5.5 466 0x80000073 0xEC13another IP routing process (via
redistribution command).
Type-5 AS External Link States

Link-ID is the IP prefix
Adv Router is the ASBR.
Link ID ADV Router Age Seq# Checksum Tag

10.33.31.0 4.4.4.4 1100 0x8000001D 0xF42B 3489686063
10.33.31.0 5.5.5.5 728 0x8000001D 0xD645 3489686063
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 Link type: There are 5 OSPF link types:

Options: (No TOS-capability, DC) - Stub Link
LS Type: Router Links - Broadcast Link
- Point-to-Point Link
Link State ID: 172.17.8.83
- Virtual Link
Advertising Router: 172.17.8.83 - Loopback Link
LS Seq Number: 80000075 All link type counts as one Link, except
Checksum: 0xCF4 Point-to-Point links counts as two
Links.
Length: 84
Number of Links: 5
Link count #1 Link connected to: a Stub Network

This is a loopback
(Link ID) Network/subnet number: 172.17.8.83 interface.
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link count #2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 172.17.8.84
These two links are aan
(Link Data) Router Interface address: 10.40.31.1 P2P interface.
interface
TOS 0 Metrics: 48
Link count #3
Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.40.31.0
TOS 0 Metrics: 48
Link count #4 These two links are aan
Link connected to: another Router (point-to-point) P2P interface.
interface In OSPF
(Link ID) Neighboring Router ID: 4.4.4.4 the P2P interfaces
(such as PPP and
(Link Data) Router Interface address: 10.40.31.6
HDLC encapsulation)
Number of TOS metrics: 0 will be account as 2
TOS 0 Metrics: 48 links: one to represent
Link count #5 the neighbour‟s ip
address and another for
Link connected to: a Stub Network
sub-network and mask.
(Link ID) Network/subnet number: 10.40.31.4
TOS 0 Metrics: 48
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

1 BGP AS-PATH entries using 24 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 Total of VPNv4
BGP using 13626 total bytes of memory prefixes received
by this neighbour.
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

172.17.0.8 4 25135 248264 77603 673771 0 0 2d17h 19
172.17.0.9 4 25135 248263 77602 673771 0 0 2d17h 19
Checking these 19 prefixes:

PE-4# sh ip bgp vpn all neigh 172.17.0.8 route
*>i5.5.5.5/32 172.17.0.5 100 100 0 i
*>i6.6.6.6/32 172.17.0.6 100 100 0 i
*>i7.7.7.7/32 172.17.0.7 100 100 0 i
*>i10.33.31.0/30 172.17.0.6 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
*>i10.33.31.4/30 172.17.0.6 0 100 0 ?
From those 19
* i 172.17.0.7 144 100 0 ?
prefixes learnt
*>i10.33.31.8/30 172.17.0.7 0 100 0 ? from this
* i 172.17.0.6 144 100 0 ? neighbour
* i10.40.31.0/30 172.17.0.5 96 100 0 ? these are what
* i10.40.31.4/30 172.17.0.5 144 100 0 ?
were imported
onto VRF
* i10.40.31.8/30 172.17.0.5 0 100 0 ? VPN.
*>i172.17.8.51/32 172.17.0.6 49 100 0 ?
* i 172.17.0.7 97 100 0 ?
*>i172.17.8.52/32 172.17.0.7 49 100 0 ?
* i 172.17.0.6 97 100 0 ?
* i172.17.8.83/32 172.17.0.5 97 100 0 ?
* i172.17.8.84/32 172.17.0.5 49 100 0 ?
July 10
*>i5.5.5.5/32 172.17.0.5 100 100 0 i
*>i10.40.31.0/30 172.17.0.5 96 100 0 ?
*>i10.40.31.4/30 172.17.0.5 144 100 0 ?
*>i10.40.31.8/30 172.17.0.5 0 100 0 ?
*>i172.17.8.83/32 172.17.0.5 97 100 0 ?
*>i172.17.8.84/32 172.17.0.5 49 100 0 ?
*>i6.6.6.6/32 172.17.0.6 100 100 0 i
*>i10.33.31.0/30 172.17.0.6 96 100 0 ?
*>i10.33.31.4/30 172.17.0.6 0 100 0 ? These are the
19 VPNv4
*>i10.33.31.8/30 172.17.0.6 144 100 0 ?
prefixes learnt
*>i172.17.8.51/32 172.17.0.6 49 100 0 ? from the MP-
*>i172.17.8.52/32 172.17.0.6 97 100 0 ? BGP
*>i7.7.7.7/32 172.17.0.7 100 100 0 i
*>i10.33.31.0/30 172.17.0.7 96 100 0 ?
*>i10.33.31.0/24 172.17.0.7 0 100 0 1 i
*>i10.33.31.4/30 172.17.0.7 144 100 0 ?
*>i10.33.31.8/30 172.17.0.7 0 100 0 ?
*>i172.17.8.51/32 172.17.0.7 97 100 0 ?
*>i172.17.8.52/32 172.17.0.7 49 100 0 ?

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


*> 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 ?
*> 10.40.31.8/30 10.40.31.6 144 32768 ?
*> 172.17.8.83/32 10.40.31.6 49 32768 ?
Total of VPNv4
*> 172.17.8.84/32 10.40.31.6 97 32768 ? 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
Let‟s check if it neighbour is receiving and advertising the same set of prefixes. It should be the same if
there aren‟t filters applied inbound direction (neighbour … filter | prefix-list | route-map commands).
RR1# sh ip bgp vpn all n 172.17.0.4 adv


*>i4.4.4.4/32 172.17.0.4 100 100 0 i
*>i10.40.31.0/30 172.17.0.4 96 100 0 ?
*>i10.40.31.4/30 172.17.0.4 0 100 0 ?
*>i10.40.31.8/30 172.17.0.4 144 100 0 ?
*>i172.17.8.83/32 172.17.0.4 49 100 0 ?
*>i172.17.8.84/32 172.17.0.4 97 100 0 ?
*>i5.5.5.5/32 172.17.0.5 100 100 0 i
*>i10.40.31.0/30 172.17.0.5 96 100 0 ?
*>i10.40.31.4/30 172.17.0.5 144 100 0 ?
*>i10.40.31.8/30 172.17.0.5 0 100 0 ?
*>i172.17.8.83/32 172.17.0.5 97 100 0 ?
*>i172.17.8.84/32 172.17.0.5 49 100 0 ?
*>i6.6.6.6/32 172.17.0.6 100 100 0 i
*>i10.33.31.0/30 172.17.0.6 96 100 0 ? These are the
same 19 VPNv4
prefixes which
*>i10.33.31.4/30 172.17.0.6 0 100 0 ? PE-4 learnt from
*>i10.33.31.8/30 172.17.0.6 144 100 0 ? RR1 (see output
*>i172.17.8.51/32 172.17.0.6 49 100 0 ? on previous
page).
*>i172.17.8.52/32 172.17.0.6 97 100 0 ?
*>i7.7.7.7/32 172.17.0.7 100 100 0 i
*>i10.33.31.0/30 172.17.0.7 96 100 0 ?
*>i10.33.31.0/24 172.17.0.7 0 100 0 1 i
*>i10.33.31.4/30 172.17.0.7 144 100 0 ?
*>i10.33.31.8/30 172.17.0.7 0 100 0 ?
*>i172.17.8.51/32 172.17.0.7 97 100 0 ?
*>i172.17.8.52/32 172.17.0.7 49 100 0 ?

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, it‟s 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

*>i4.4.4.4/32 172.17.0.4 100 100 0 i
*>i10.40.31.0/30 172.17.0.4 96 100 0 ?
*>i10.40.31.4/30 172.17.0.4 0 100 0 ?
*>i10.40.31.8/30 172.17.0.4 144 100 0 ?
*>i172.17.8.83/32 172.17.0.4 49 100 0 ?
Total of VPNv4
*>i172.17.8.84/32 172.17.0.4 97 100 0 ? 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


*> 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 This prefix was learn via
learn via RR2 and *>i6.6.6.6/32 172.17.0.6 100 100 0 i RR1 and had a RD value
had a RD value * i 172.17.0.6 100 100 0 i 25135:133001806
25135:133001806 *>i7.7.7.7/32 172.17.0.7 100 100 0 i
* 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 ? This prefix was learn via
*>i10.33.31.0/24 172.17.0.7 0 100 0 1 i RR1 and had a RD value
This prefix was * i 172.17.0.7 0 100 0 1 i 25135:133001807
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
*>i10.33.31.8/30 172.17.0.7 0 100 0 ?
* i 172.17.0.7 0 100 0 ?
* i 172.17.0.6 144 100 0 ?
* i 172.17.0.6 144 100 0 ?
*> 10.40.31.0/30 10.40.31.6 96 32768 ?
* i 172.17.0.5 96 100 0 ?
* i 172.17.0.5 96 100 0 ?
*> 10.40.31.4/30 0.0.0.0 0 32768 ?
* i 172.17.0.5 144 100 0 ?
* i 172.17.0.5 144 100 0 ?
* i10.40.31.8/30 172.17.0.5 0 100 0 ?
* i 172.17.0.5 0 100 0 ?
*> 10.40.31.6 144 32768 ?
*>i172.17.8.51/32 172.17.0.6 49 100 0 ?
* i 172.17.0.6 49 100 0 ?
* i 172.17.0.7 97 100 0 ?
* i 172.17.0.7 97 100 0 ?
* i172.17.8.52/32 172.17.0.7 49 100 0 ?
*>i 172.17.0.7 49 100 0 ?
* i 172.17.0.6 97 100 0 ?
* i 172.17.0.6 97 100 0 ?
*> 172.17.8.83/32 10.40.31.6 49 32768 ?
* i 172.17.0.5 97 100 0 ?
* i 172.17.0.5 97 100 0 ?
Textblue
The bluetext
are are * i172.17.8.84/32 172.17.0.5 49 100 0 ?
prefixes
the prefixes * i 172.17.0.5 49 100 0 ?
advertised by RR1 *> 10.40.31.6 97 32768 ?
*>i5.5.5.5/32 172.17.0.5 100 100 0 i
* i 172.17.0.5 100 100 0 i
*>i10.40.31.0/30 172.17.0.5 96 100 0 ?
* i 172.17.0.5 96 100 0 ?
*>i10.40.31.4/30 172.17.0.5 144 100 0 ? This Prefixes are
* i 172.17.0.5 144 100 0 ? from PE5‟s VPN
*>i10.40.31.8/30 172.17.0.5 0 100 0 ?
* i 172.17.0.5 0 100 0 ?
vrf. They were
*>i172.17.8.83/32 172.17.0.5 97 100 0 ? exported with RT
* i 172.17.0.5 97 100 0 ? 25135:18 value.
*>i172.17.8.84/32 172.17.0.5 49 100 0 ?
* i 172.17.0.5 49 100 0 ?
*>i6.6.6.6/32 172.17.0.6 100 100 0 i
* i 172.17.0.6 100 100 0 i
*>i10.33.31.0/30 172.17.0.6 96 100 0 ?
* i 172.17.0.6 96 100 0 ? This Prefixes are
*>i10.33.31.4/30 172.17.0.6 0 100 0 ? from PE6‟s VPN
* i 172.17.0.6 0 100 0 ? vrf. They were
*>i10.33.31.8/30 172.17.0.6 144 100 0 ?
* i 172.17.0.6 144 100 0 ?
exported with RT
*>i172.17.8.51/32 172.17.0.6 49 100 0 ? 25135:18 value.
* i 172.17.0.6 49 100 0 ?
*>i172.17.8.52/32 172.17.0.6 97 100 0 ?
* i 172.17.0.6 97 100 0 ?
* i7.7.7.7/32 172.17.0.7 100 100 0 i
The green text are *>i 172.17.0.7 100 100 0 i
the prefixes * i10.33.31.0/30 172.17.0.7 96 100 0 ?
advertised by RR2 *>i 172.17.0.7 96 100 0 ?
*>i10.33.31.0/24 172.17.0.7 0 100 0 1 i This Prefixes are
* i 172.17.0.7 0 100 0 1 i from PE7‟s VPN
* i10.33.31.4/30 172.17.0.7 144 100 0 ?
*>i 172.17.0.7 144 100 0 ?
vrf. They were
* i10.33.31.8/30 172.17.0.7 0 100 0 ? exported with RT
*>i 172.17.0.7 0 100 0 ? 25135:18 value.
* i172.17.8.51/32 172.17.0.7 97 100 0 ?
*>i 172.17.0.7 97 100 0 ?
* i172.17.8.52/32 172.17.0.7 49 100 0 ?
*>i 172.17.0.7 49 100 0 ?
July 10
Where other prefixes in vrf VPN come from? They are generated locally (in PE-4) or they come from CE-
PE 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
O 172.17.8.84 [110/97] via 10.40.31.6, 06:20:14, Serial2/0
O 172.17.8.83 [110/49] via 10.40.31.6, 06:20:14, Serial2/0
O 10.40.31.8/30 [110/144] via 10.40.31.6, 06:20:14, Serial2/0
O 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

Finally, this appointed out what
Flag: 0x800
is the path will be used on FIB
Not advertised to any peer vrf table.
172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8)
Origin incomplete, metric 96, localpref 100, valid, internal, best
Due to maximum- Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200
path import
command we have
here two paths Originator: 172.17.0.6, Cluster list: 0.0.0.1,
imported for the mpls labels in/out nolabel/47
same VPNv4 prefix Local, imported path from 25135:133001806:10.33.31.0/30
25135:133001806 172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9) RT value,
:10.33.31.0/30 reason
why these
Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200 prefixes
RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:6.6.6.6:512 were
Originator: 172.17.0.6, Cluster list: 0.0.0.1, imported
mpls labels in/out nolabel/47 onto BGP
vrf VPN
table.
172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8)
2nd
2 nd set of the
VPNv4 RT:212.183.144.1:18 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:7.7.7.7:512
VPN
prefix.prefixes
The blue Originator: 172.17.0.7, Cluster list: 0.0.0.1,
text was learnt mpls labels in/out nolabel/48
via router-
reflector 1 Local, imported path from 25135:133001807:10.33.31.0/30
(172.17.0.8) and 172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9)
the green text Origin incomplete, metric 96, localpref 100, valid, internal
was learnt via Extended Community: RT:25135:18 OSPF DOMAIN ID:0x0005:0x000000010200
router-reflector 2
(172.17.0.9)
July 10
Paths: (2 available, best #1, no table)
This Prefixes are from PE6‟s
Flag: 0x800 VPN vrf. They were exported
Not advertised to any peer with RT 25135:18 value.
Local
172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8)
Local
172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9)
Flag: 0x800
Local
172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8)
Local
172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9)
This Prefixes are from
PE7‟s VPN vrf. They
PE-4# sh ip route vrf VPN 10.33.31.0
were exported with RT
Routing entry for 10.33.31.0/30 25135:18 value.
Known via "bgp 25135", distance 200, metric 96, type internal
BGP next-hop Redistributing via ospf 1
(remote PE) Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn
Last update from 172.17.0.6 20:32:11 ago
* 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 BGP neighbour which
AS Hops 0, BGP network version 0 adversited this prefix (RR1).
July 10
MPLS/TE and FRR
Identify the destination
Step 1. From a source PE identify the 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.7 1d23h ago
* 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 1d23h ago
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
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
* 172.17.0.7, from 172.17.0.7, via Tunnel3
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
Label in the Top of “Label

Step 2. Checking the label stack in Data plane Database Stack” - MPLS/TE label
PE-4# sh ip cef vrf VPN 172.17.8.52 Leart via RSVP
0 packets, 0 bytes
tag information set, all rewrites owned
via 172.17.0.7, 0 dependencies, recursive Label in the Bottom of
next hop 172.17.0.7, Tunnel3 via 172.17.0.7/32 (Default) “Label Stack” -
valid cached adjacency MPLS/VPN laabel
tag rewrite with Tu3, point2point, tags imposed {58 50} 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
0 packets, 0 bytes
RSVP Label, learnt via
tag information set, all rewrites owned RSVP neighbor
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
tag rewrite with Tu3, point2point, tags imposed {58}
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
RSVP Label, learnt via
Tun Sender: 172.17.0.4 LSP ID: 6053
RSVP neighbor
Next Hop: 172.19.24.1 on Serial0/0
Label: 58 (outgoing)
. . .
[output omitted]

In MP-BGP database, you
Paths: (4 available, best #1, table VPN) have to look for what the
preferential path is. It will
Flag: 0x800
be always identify with the
Not advertised to any peer keyword “best”
172.17.0.7 (metric 670) from 172.17.0.8 (172.17.0.8)
MPLS/VPN Label, learnt
via remote PE flooded via
Local, imported path from 25135:133001807:172.17.8.52/32 MP-BGP neighbour (route-
172.17.0.7 (metric 670) from 172.17.0.9 (172.17.0.9) reflector)
. . .
[output omitted]
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 Interface
----------- ---------
172.17.0.5 Tunnel1
172.17.0.6 Tunnel2
172.17.0.7 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 | i 172.17.0.7

172.17.0.7 Tunnel3
PE-4# sh mpl traffic-eng auto-tunnel mesh | i Tunnel3

172.17.0.7 Tunnel3
PE-4# sh ip int bri

Interface IP-Address OK? Method Status
Protocol
Serial0/0 172.19.24.2 YES NVRAM up up
Auto-Template1 172.17.0.4 YES unset up up
Loopback0 172.17.0.4 YES NVRAM up up
Tunnel1 172.17.0.4 YES unset 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
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

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
Both interfaces facing Core P routers are operational in both MPLS (LDP) and MPLS-TE.
PE-4# sh mpl int | i (Interface|Serial0/0)

4
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
Step 4.
enabled in all PEs and Ps
PE-4# sh mpl traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
auto-tunnel:
backup Enabled (4 ), id-range:60000-64000
onehop Disabled (0 ), id-range:65336-65435
mesh Enabled (3 ), id-range:1-999
Periodic reoptimization: every 3600 seconds, next in 2546 seconds

Periodic FRR Promotion: Not Running
Periodic auto-tunnel:
backup notinuse scan: every 3600 seconds, next in 2643 seconds
Periodic auto-bw collection: every 300 seconds, next in 184 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF
STATE/PROT
PE-4_t1 172.17.0.5 - Se1/0 up/up
PE-4_t2 172.17.0.6 - Se0/0 up/up
PE-4_t3 172.17.0.7 - Se0/0 up/up
PE-4_t60000 172.17.0.5 - Se0/0 up/up
PE-4_t60001 172.17.0.2 - Se1/0 up/up
. . . [ 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

Step 5.
enabled in all PEs and Ps
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: none
Generate wide metrics: level-1-2
Accept wide metrics: 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 Neighbor ID IP Address Interface Status Level
3d05h PE-5.00 172.19.45.2 Se1/0 Up level-2
03:55:38 P2.00 172.19.24.1 Se0/0 Up 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 Tunnel Name BW Metric Nexthop Metric Mode
PE-5.00 Tunnel1 20000000 172.17.0.5
PE-6.00 Tunnel2 20000000 172.17.0.6
PE-7.00 Tunnel3 20000000 172.17.0.7
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 Metric Next-Hop Interface SNPA
P1 20 P2 Se0/0 *HDLC*
P2 10 P2 Se0/0 *HDLC*
P3 20 P2 Se0/0 *HDLC*
PE-4 --
PE-5 620 PE-5 Tu1 *MPLS TE-Tunnel*
RR1 30 P2 Se0/0 *HDLC*
RR2 630 P2 Se0/0 *HDLC*
P30 620 P2 Se0/0 *HDLC*
P31 610 P2 Se0/0 *HDLC*
P32 620 P2 Se0/0 *HDLC*
July 10
PE-4# sh isis data PE-4.00-00 verbo
IS-IS Level-2 LSP PE-4.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
PE-4.00-00 * 0x00000018 0x9B99 64183 0/0/0
Auth: Length: 17
Area Address: 10
NLPID: 0xCC
Hostname: PE-4
Router ID: 172.17.0.4
IP Address: 172.17.0.4
Metric: 10 IS-Extended P2.00
Affinity: 0x00000000
Interface IP Address: 172.19.24.2
Neighbor IP Address: 172.19.24.1
These figures show the amount
Physical BW: 2048 kbits/sec
of Bandwidth available after
Reservable Global Pool BW: 155000 kbits/sec reservation for this priority and
Global Pool BW Unreserved: lower.
[0]: 155000 kbits/sec, [1]: 155000 kbits/sec Because of “tunnel mpls
[2]: 155000 kbits/sec, [3]: 155000 kbits/sec traffic-eng auto-bw collect-
[4]: 154998 kbits/sec, [5]: 154998 kbits/sec bw” command applied under
interface tunnel configuration,
[6]: 154998 kbits/sec, [7]: 154998 kbits/sec
Instead of reserving the
Metric: 640 IS-Extended PE-5.00 maximum bandwidth
Affinity: 0x00000000 (100Kbits) it is reserved the
Interface IP Address: 172.19.45.1 amount of the traffic rate being
utilised per interface tunnel.
PS.: high number means low priority.
Reservable Global Pool BW: 155000 kbits/sec
Global Pool BW Unreserved:
Metric: 0 IP 172.17.0.4/32
Metric: 10 IP 172.19.24.0/30
Metric: 640 IP 172.19.45.0/30
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
Admin. Weight te: 10 igp: 10
Reservable Global Pool BW: 155000 kbits/sec
Reservable Sub Pool BW: 0 kbits/sec
Global Pool BW unreserved:
July 10
Sub Pool BW unreserved:
[0]: 0 kbits/sec, [1]: 0 kbits/sec These figures show the amount
of Bandwidth available after
reservation for this priority and
[4]: 0 kbits/sec, [5]: 0 kbits/sec lower.
[6]: 0 kbits/sec, [7]: 0 kbits/sec Because of “tunnel mpls
Affinity Bits: 0x00000000 traffic-eng auto-bw collect-
Link[2] bw” command applied under
Neighbor System ID: PE-5.00 (P2P link) interface tunnel configuration,
Instead of reserving the
Interface IP address: 172.19.45.1
maximum bandwidth
Neighbor IP Address: 172.19.45.2 (100Kbits) it is reserved the
Admin. Weight te: 640 igp: 640 amount of the traffic rate being
Physical BW: 2048 kbits/sec utilised per interface tunnel.
Reservable Global Pool BW: 155000 kbits/sec PS.: high number means low priority.
. . .
[output omitted]
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) These figures show the amount
Interface IP address: 172.19.24.2 of Bandwidth available after
lower.
Admin. Weight te: 10 igp: 10
Results without “tunnel mpls
traffic-eng auto-bw collect-
Reservable Global Pool BW: 155000 kbits/sec bw” command
Reservable Sub Pool BW: 0 kbits/sec
Global Pool BW unreserved:
Sub Pool BW unreserved:
Affinity Bits: 0x00000000
. . .
[output omitted]
July 10
Step 6. Checking RSVP status
PE-4# sh ip rsvp int
This value (bandwidth to be
interface rsvp allocated i/f max flow max sub max
considered in resource
Se0/0 ena 300K 155M 155M 0 reservation – “ip rsvp
Se1/0 ena 0 155M 155M 0 bandwidth” interface
Tu60000 ena 0 0 0 0 command) should be always
higher than the bandwidth
Tu60001 ena 0 0 0 0
configured on interface tunnel
Tu60002 ena 0 0 0 0 otherwise the reservation will
Tu60003 ena 0 0 0 0 fail for this physical interface.
Tu60004 ena 0 0 0 0
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
Se0/0 ena 300K 155M 155M 0
PE-4# sh ip rsvp neighbor

172.19.24.1 RSVP
172.19.45.2 RSVP
It displays RSVP neighbour-ship created. Here we can identify which
tunnels are using the
PE-4# sh ip rsvp installed
physical resource.
RSVP: Serial0/0
Figures due to tunnel mpls
BPS To From Protoc DPort Sport
traffic-eng auto-bw
0 172.17.0.2 172.17.0.5 0 60003 1 collect-bw tunnel interface
1K 172.17.0.5 172.17.0.4 0 1 478 command is applied.
0 172.17.0.5 172.17.0.4 0 60000 8950
0 172.17.0.6 172.17.0.4 0 2 6911
0 172.17.0.7 172.17.0.4 0 3 6103
0 172.17.0.31 172.17.0.4 0 60001 8948
RSVP: Serial1/0 has no installed reservations
RSVP: Tunnel60000 has no installed reservations
Here we can identify which
tunnels are using the
PE-4# sh ip rsvp installed physical resource.
RSVP: Serial0/0
Case when “tunnel mpls
BPS To From Protoc DPort Sport traffic-eng auto-bw
0 172.17.0.2 172.17.0.6 0 60001 7514 collect-bw” tunnel
0 172.17.0.3 172.17.0.6 0 60000 7514 interface command is NOT
applied.
0 172.17.0.3 172.17.0.7 0 60001 7517
0 172.17.0.5 172.17.0.4 0 60000 168
100K 172.17.0.6 172.17.0.4 0 2 2518
0 172.17.0.6 172.17.0.7 0 60000 7523
0 172.17.0.6 172.17.0.32 0 60003 4687
100K 172.17.0.7 172.17.0.4 0 3 7463
It shows RSVP allocation per interface, per tunnel.
July 10
PE-4# sh ip rsvp installed | i (RSVP|100K)
RSVP: Serial0/0
100K 172.17.0.6 172.17.0.4 0 2 2518
100K 172.17.0.7 172.17.0.4 0 3 7463
RSVP: Serial1/0
100K 172.17.0.5 172.17.0.4 0 1 9437
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.
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:
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Resv ID handle: 05000410.
Average Bitrate is 100K bits/sec, Maximum Burst is 1K 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)
172.17.0.3/32, Flags:0x29 (Local Prot Avail/to NNHOP, Node-id)
July 10
172.19.32.1/32, Flags:0x9 (Local Prot Avail/to NNHOP)
172.17.0.7/32, Flags:0x20 (No Local Protection, Node-id)
172.19.137.2/32, Flags:0x0 (No Local Protection)
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:
RRO:
172.17.0.3/32, Flags:0x29 (Local Prot Avail/to NNHOP, Node-id)
172.19.32.1/32, Flags:0x9 (Local Prot Avail/to NNHOP)
Status:
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 From Pro DPort Sport Next Hop I/F Fi Serv BPS
172.17.0.4 172.17.0.5 0 1 5507 none none SE LOAD 4K
Mode(s): Host LSP-Tunnel
172.17.0.4 172.17.0.6 0 1 7913 none none SE LOAD 0
172.17.0.4 172.17.0.7 0 1 4927 none none SE LOAD 0
172.17.0.4 172.17.0.2 0 60000 7495 none none SE LOAD 0
172.17.0.4 172.17.0.5 0 60000 7515 none none SE LOAD 0
172.17.0.4 172.17.0.3 0 60001 7496 none none SE LOAD 0
172.17.0.4 172.17.0.31 0 60003 4670 none none SE LOAD 0
List of Tunnels where PE4 is a tail End
PE-4# sh ip rsvp host senders

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

To From Pro DPort Sport Next Hop I/F Fi Serv BPS
172.17.0.2 172.17.0.4 0 60001 167 172.19.45.2 Se1/0 SE LOAD 0
172.17.0.2 172.17.0.6 0 60001 7514 172.19.24.1 Se0/0 SE LOAD 0
172.17.0.3 172.17.0.6 0 60000 7514 172.19.24.1 Se0/0 SE LOAD 0
172.17.0.3 172.17.0.7 0 60001 7517 172.19.24.1 Se0/0 SE LOAD 0
172.17.0.3 172.17.0.4 0 60002 167 172.19.45.2 Se1/0 SE LOAD 0
172.17.0.4 172.17.0.5 0 1 5507 none none SE LOAD 4K
172.17.0.4 172.17.0.6 0 1 7913 none none SE LOAD 0
172.17.0.4 172.17.0.7 0 1 4927 none none SE LOAD 0
It shows the Reservation Requests from Downstream.
July 10
PE-4# sh ip rsvp counters interface s1/0
Serial1/0 Recv Xmit Recv Xmit
Path 51 48 Resv 94 96
PathError 2 0 ResvError 0 13
PathTear 47 56 ResvTear 26 27
ResvConf 0 0 RTearConf 0 0
Ack 17893 17881 Srefresh 17782 17784
Hello 0 0 IntegrityChalle 0 0
IntegrityRespon 0 0 DSBM_WILLING 0 0
I_AM_DSBM 0 0 Errors 0 0
PE-4# sh ip rsvp counters summary

All Interfaces Recv Xmit Recv Xmit
Path 100 98 Resv 188 192
PathError 10 0 ResvError 0 25
PathTear 105 114 ResvTear 44 36
ResvConf 0 0 RTearConf 0 0
Ack 35794 35795 Srefresh 35579 35579
Hello 0 0 IntegrityChalle 0 0
IntegrityRespon 0 0 DSBM_WILLING 0 0
I_AM_DSBM 0 0 Errors 0 0
Error Distribution Recv Xmit
Authentication 0 0
Other 0 0
Recv Msg Queues Current Max
RSVP 0 8
Hello (per-I/F) 0 0
Awaiting Authentication 0 0
If the network is stable these figures shouldn‟t 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 Interface
----------- ---------
172.17.0.5 Tunnel1
172.17.0.6 Tunnel2
172.17.0.7 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)
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: Name: PE-4_t1 (Tunnel1) Destination: 172.17.0.5
Check the
Status:
status (up up).
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 1040)
Config Parameters:
Third check:
Check if the path is valid.
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/82153) 2 Bandwidth Requested: 100
Active Path Option Parameters:
State: dynamic path option 1 is active
Last check:
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
Check outLabel to track the LSP (also the
InLabel : - FRR information such as Interface number
OutLabel : Serial0/0, 51 and label.
FRR OutLabel : Tunnel60002, 59
RSVP Signalling Info:
Fourth check:
Src 172.17.0.4, Dst 172.17.0.5, Tun_Id 1, Tun_Instance 9719
Check if this is expected path (confirm
RSVP Path Info: checking the topology).
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: Fifth check:
Record Route: 172.17.0.2(51) 172.17.0.1(59) LSP labels end-to-end.
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: Additional check:
Check how long this tunnel is
Tunnel:
operational and the last path
Time since created: 1 hours, 9 minutes changed.
Time since path change: 1 hours, 9 minutes
Number of LSP IDs (Tun_Instances) used: 2
Current LSP:
Uptime: 1 hours, 9 minutes
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 Sub Pool
Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 155000 0
Bandwidth available after
bw[1]: 0 155000 0
bw[2]: 0 155000 lower. 0
bw[3]: 0 155000 0
PS.: high number means low priority.
bw[4]: 300 154700 0
bw[5]: 0 154700 0
bw[6]: 0 154700 0
bw[7]: 0 154700 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 0: 172.19.45.1 : affinity 00000000, bandwidth 154900 (kbps)
Hop 4: 172.17.0.7
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)
July 10
Hop 4: 172.17.0.7
PE-4# show mpls traffic-eng autoroute
MPLS TE autorouting enabled
destination 0000.0000.0005.00, area isis level-2, has 1 tunnels
Tunnel1 (load balancing metric 20000000, nexthop 172.17.0.5)
(flags: Announce)
(flags: Announce)
(flags: Announce)
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: 1 transitions, 0 admin down, 0 oper down
Signalling statistics:
Opens: 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
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: 1 transitions, 0 admin down, 0 oper down
Signalling statistics:
Opens: 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
172.17.0.5 60004 (Destination 172.17.0.32; Name PE-5_t60004)
July 10
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 Path Info:
Explicit Route: NONE
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
LSP Tunnel P3_t60001 is signalled, connection is up
InLabel : Serial1/0, implicit-null
OutLabel : -
RSVP Path Info:
Explicit Route: NONE
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
PE-4# sh mpl traffic-eng tunnels accounting

5 minute output rate 2 kbits/sec, 1 packets/sec
Totals for 7 Tunnels
July 10
PE-4# sh mpl traffic-eng link-management bandwidth-allocation serial 1/0
System Information::
Links Count: 2 It displays how many interfaces
Bandwidth Hold Time: max. 15 seconds
are enabled on RSVP.
Link ID:: Se1/0 (172.19.45.1)
Link Status:
SRLGs: None
Physical Bandwidth: 2048 kbits/sec
Max Res Global BW: 155000 kbits/sec (reserved: 0% in, 0% out)
Max Res Sub BW: 0 kbits/sec (reserved: 100% in, 100% out)
BW Descriptors: 1
MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded
Inbound Admission: allow-all It shows the threshold when a
Outbound Admission: allow-if-room new LSP will be generated and
Admin. Weight: 640 (IGP) flooded to whole backbone
IGP Neighbor Count: 1 area.
Up Thresholds: 15 30 45 60 75 80 85 90 95 96 97 98 99 100
(default)
Down Thresholds: 100 99 98 97 96 95 90 85 80 75 60 45 30 15
(default)
Downstream Global Pool Bandwidth Information (kbits/sec):
KEEP PRIORITY BW HELD BW TOTAL HELD BW LOCKED BW TOTAL LOCKED
0 0 0 0 0
1 0 0 0 0
2 0 0 0 0
3 0 0 0 0
4 0 0 100 100
5 0 0 0 100
6 0 0 0 100
7 0 0 0 100
Downstream Sub Pool Bandwidth Information (kbits/sec):
KEEP PRIORITY BW HELD BW TOTAL HELD BW LOCKED BW TOTAL LOCKED
0 0 0 0 0 global pool.
“G” means
Total of the . . . [ output omitted ] “R” means bandwidth is
tunnels this router reserved.
is aware of. “H” means bandwidth is
PE-4# sh mpl traffic-eng link-management admission-control temporarily being held
System Information:: Upstream interface for a path message.
T Tunnels Count: 36
Downstream interface
Tunnels Selected: 36
TUNNEL ID UP IF DOWN IF PRIORITY STATE BW (kbps)
172.17.0.1 60001_78 Se0/0 Se1/0 7/7 Resv Admitted 0 G
172.17.0.3 60001_52 Se1/0 - 7/7 Resv Admitted 0 G
Tunnel id: <Head- 172.17.0.3 60002_58 Se0/0 Se1/0 7/7 Resv Admitted 0 G
end IP address> +
<tunnel #>_<id>. 172.17.0.3 60003_58 Se0/0 Se1/0 7/7 Resv Admitted 0 G
172.17.0.4 1_9721 - Se1/0 4/4 Resv Admitted 100 RG
172.17.0.4 2_1367 - Se0/0 4/4 Resv Admitted 100 RG
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: ready
Configured Areas: 1
IGP Area[1] ID:: isis level-2
Flooding Protocol: ISIS
Header Information::
IGP System ID: 0000.0000.0004.00
MPLS TE Router ID: 172.17.0.4
Flooded Links: 2
Link ID:: 0
Link Subnet Type: Point-to-Point
Link IP Address: 172.19.24.2
IGP Neighbor: ID 0000.0000.0002.00, IP 172.19.24.1
TE metric: 10
IGP metric: 10
SRLGs: None
These figures should match with
“show mpls traffic-eng topology
Res. Global BW: 155000 kbits/sec igp-id isis <system-id>.00
Res. Sub BW: 0 kbits/sec command output.
Downstream::
Global Pool Sub Pool
----------- ----------
Reservable Bandwidth[0]: 155000 0 kbits/sec
Attribute Flags: 0x00000000
Link ID:: 1
Link Subnet Type: Point-to-Point
Link IP Address: 172.19.45.1
IGP Neighbor: ID 0000.0000.0005.00, IP 172.19.45.2
TE metric: 640
IGP metric: 640
SRLGs: None
Res. Global BW: 155000 kbits/sec
Res. Sub BW: 0 kbits/sec
Downstream::
July 10
PE-4# sh mpl traffic-eng link-management igp-neighbors
Link ID:: Se0/0
Neighbor ID: 0000.0000.0002.00 (area: isis level-2, IP: 172.19.24.1)
Link ID:: Se1/0
Neighbor ID: 0000.0000.0005.00 (area: isis level-2, IP: 172.19.45.2)
It shows MPLS-TE ISIS neighbours.
PE-4# sh mpl traffic-eng link-management statistics

LSP Admission Statistics:
Path: 85 setup requests, 85 admits, 0 rejects, 0 setup errors
43 tear requests, 0 preempts, 0 tear errors
Resv: 90 setup requests, 90 admits, 0 rejects, 0 setup errors
Link ID:: Se0/0 (172.19.24.2)
Link Admission Statistics:
Up Path: 34 setup requests, 34 admits, 0 rejects, 0 setup errors
Up Resv: 30 setup requests, 30 admits, 0 rejects, 0 setup errors
Down Path: 32 setup requests, 32 admits, 0 rejects, 0 setup errors
Down Resv: 46 setup requests, 46 admits, 0 rejects, 0 setup errors
Link ID:: Se1/0 (172.19.45.1)
Link Admission Statistics:
Up Path: 31 setup requests, 31 admits, 0 rejects, 0 setup errors
PE-4# sh mpl traffic-eng link-management interfaces s0/0

Links Count: 2
Link ID:: Se0/0 (172.19.24.2)
Link Status:
SRLGs: None
Max Res Global BW: 155000 kbits/sec (reserved: 0% in, 0% out)
Max Res Sub BW: 0 kbits/sec (reserved: 100% in, 100% out)
MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded
Inbound Admission: allow-all
Outbound Admission: allow-if-room
Admin. Weight: 10 (IGP)
IGP Neighbor Count: 1
IGP Neighbor: ID 0000.0000.0002.00, IP 172.19.24.1 (Up)
Flooding Status for each configured area [1]:
IGP Area[1]: isis level-2: flooded
July 10
If the state is “active” means
the primary tunnel is down and N-Nhop means Link
Step 8. FAST REROUTE CHECKING protection.
the backup is being used.
PE-4# sh ip rsv fast-reroute
Primary Protect BW Backup
Tunnel I/F BPS:Type Tunnel:Label State Level Type
------ ------- -------- ------------- ------ ----- ------
PE-4_t1 Se0/0 100K:G Tu60003:56 Ready any-unl N-Nhop
PE-4# sh ip rsvp fast bw-protect

Primary Protect BW Backup
Tunnel I/F BPS:Type Tunnel:Label State BW-P Type
------ ------- -------- ------------- ------ ----- ------
PE-4_t1 Se0/0 100K:G Tu60003:56 Ready OFF N-Nhop
This output shows the status of backup bandwidth protection.
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
Fast Reroute Backup Provided:
Protected i/fs: Se1/0
Protected lsps: 0
Backup BW: any pool unlimited; inuse: 0 kbps
PE-4_t60001
Protected lsps: 0
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 (Tunnel60002) Destination: 172.17.0.3

Status:
path option 1, type explicit __dynamic_tunnel60002 (Basis for Setup, path
weight 1260)
Config Parameters:
AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
State: explicit path option 1 is active
This is the Tail end of Backup tunnel.

In this case it is P3.
InLabel : - This is a node protection.
OutLabel : Serial1/0, 53 In this case the node protected is P2.
RSVP Path Info:
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
Path of Backup
RSVP Resv Info: Tunnel in case of
Record Route: NONE failures (failure link
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits between PE4 or node
failure, P2 node)
Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3
History:
Tunnel: Path when there is
Time since created: 3 hours, 1 minutes NO failure.
Time since path change: 3 hours, 1 minutes
Current LSP:
Uptime: 3 hours, 1 minutes
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:
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)
ERO: (outgoing)
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
Outbound FRR: Ready -- backup tunnel selected
Backup Tunnel: Tu60002 (label 42)
Bkup Sender Template:
Tun Sender: 172.19.45.1 LSP ID: 7169
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
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 In-label Out intf/label FRR intf/label Status
Tunnel3 Tun hd Se0/0:Untagged Tu60002:42 ready
Prefix item frr information:

Prefix Tunnel In-label Out intf/label FRR intf/label Status
172.17.0.6/32 Tu2 46 Se0/0:Pop tag Tu60002:41 ready
172.16.67.0/30 Tu2 48 Se0/0:Untagged Tu60002:41 ready
6.6.6.6/32 vpn vpn Se0/0:25 Tu60002:41 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: 1
Total Groups: 2
Total Items: 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
July 10
AToM
PE-4# sh mpl l2transport binding 100
Destination Address: 172.17.0.7, VC ID: 100
Local Label: 49
Cbit: 1, VC Type: HDLC, GroupID: 0
MTU: 1500, Interface Desc: >>>> link to CE1
VCCV Capabilities: Type 1, Type 2
Remote Label: 50
It displays the status of vc-id 100.
PE-4# sh mpl l2transport binding 172.17.0.7
Destination Address: 172.17.0.7, VC ID: 100
Local Label: 49
Remote Label: 50
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: receive 0, seq error 0, send 0
July 10
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
LDP or RSVP label for
6 10.33.31.10 20 msec * 20 msec LSP tunnel from PE4- to
This path is: CE-1  PE4  P2  P31  P32  PE7  CE-4 PE7.
Let‟s check this from PE4.
PE-4# trace vrf VPN 10.33.31.10
VPN label (learn
Type escape sequence to abort. via MP-BGP
1 172.19.24.1 [MPLS: Labels 43/49 Exp 0] 40 msec 40 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 LDP or RSVP label for
0 packets, 0 bytes LSP tunnel from PE4- to
tag information set, all rewrites owned PE7.
via 172.17.0.7, 0 dependencies, recursive
next hop 172.17.0.7, Tunnel3 via 172.17.0.7/32 (Default) VPN label (learn
via MP-BGP
tag rewrite with Tu3, point2point, tags imposed {43 49}
Let‟s 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 172.17.0.7 nolabel/49
10.33.31.8/30 172.17.0.7 nolabel/49
You can also with the following command:

PE-4# sh ip bgp vpn all 10.33.31.8
172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8)
172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9)
Local
172.17.0.7 (metric 630) from 172.17.0.9 (172.17.0.9)
Local
172.17.0.7 (metric 630) from 172.17.0.8 (172.17.0.8)
Let‟s 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
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
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
Status:
Config Parameters:
InLabel : -
This is the RSVP
OutLabel : Serial0/0, 43
label.
RSVP Path Info:
Explicit Route: 172.19.24.1 172.19.31.2 172.19.131.2 172.19.137.2
172.17.0.7
Record Route:
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)
With this command you
172.17.0.32(37) 172.19.137.1(37) can also get the LSP
172.17.0.7(0) 172.19.137.2(0) tunnel from PE-4 to PE-
[output ommitted] 7. This set of label
should match with the
output shown in
You can also get the RSVP label from the following command: traceroute 2 page before.
July 10
PE-4# sh ip rsvp reservation detail filter destination 172.17.0.7
Reservation:
Created: 09:09:13 UTC Fri Jul 13 2007
RRO:
Status:
Let‟s 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 20 172.17.0.8/32 608143 Se0/0 point2point
43 40 172.17.0.4 3 [5407] 484533 Se2/0 point2point
This is the outgoing

label for this LSP.
Which should match
with the output in the
Label for incoming trace command.
labelled packet
Incoming Let‟s to the same for the next hop, which is P31 (172.19.31.2).
label.
31 16 172.17.0.4/32 336408 Se2/0 point2point
40 37 172.17.0.4 3 [5407] 486261 Se1/0 point2point
Outgoing
label.
July 10
Because P32 is the
PHP, we will have
here a pop tag
(explicit-null).
Let‟s to the same for the next hop, which is P32 (172.19.131.2).
37 Pop tag 172.17.0.4 3 [5407] 463873 Se3/0 point2point
41 38 172.17.0.5 2 [3337] 0 Se2/0 point2point
42 37 172.17.0.7 1 [2002] 0 Se1/0 point2point
54 56 172.17.0.7 2 [9988] 73748 Se2/0 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)

Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via bgp 25135
Advertised by bgp 25135
* directly connected, via Serial2/0
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
RSVP Path Info:
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
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)
July 10
Checking in the diagram if this route is the expect path: PE4   P2   P3   PE6   PE7.
P1
Head End Middle Points
Point
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,
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,

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 This is a node protection
Src 172.17.0.4, Dest 172.17.0.7, Instance 7463 (NNHOP).
Fast Reroute Protection: Requested The node protected here is P2
Outbound: FRR Ready (as the next hop is P3).
Backup Tu60002 to LSP nnhop Look in the previous output to
understand why P2 is the node
Tu60002: out i/f: Se1/0, label: 57 protected.
This backup tunnel is a node protection (nnhop).
PE-4# sh mpl traffic-eng tunnels tunnel 60002 | i Path|Explicit Route
RSVP Path Info:
Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2
Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3
July 10
Verify the Path used for this backup tunnel: PE4   PE5   P31   P32   PE7   PE6.
Node Protected
for this tunnel P1
PE-4 – T60002 Next-Next -Hop
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
Is this path expected? Why the cSPF algorithm chose this path? Let‟s check the ISIS metric for this path.
PE-4# sh cln int | i Serial|Metric

PE-5# sh cln int | i (line protocol|Metric)
Auto-Template1 is up, line protocol is up
Loopback0 is up, line protocol is up
Tunnel1 is up, line protocol is up
P31# sh cln int | i line protocol|Metric

Level-2 Metric: 10, Priority: 64, Circuit ID: P31.00
July 10
Serial4/0 is up, line protocol is down
P32#sh cln int | i line protocol|Metric

Serial4/0 is up, line protocol is down
PE-7# sh cln int | i line protocol|Metric

Auto-Template1 is up, line protocol is up
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
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
Protected lsps: 2
P2# sh mpl traffic-eng tunnels tun 60002 backup
P2_t60002
Protected lsps: 0
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
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)
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2
172.17.0.7
July 10
Checking in the diagram in this route the expect path: PE4   P2   P3   P32   PE7.
P1
Head End
PE4 P2 P3 PE6
Middle Points
Point 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 This tunnel is a
Node protection.
Outbound: FRR Ready
Tu60002: out i/f: Se1/0, label: 46
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
RSVP Resv Info:
Record Route: NONE
Checking in the diagram in this route the expect path: PE4   PE5   P31   P32   P3.
Node Protected P1
Next-Next -Hop
for this tunnel
PE-4 – T60002
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
July 10
PE-4# sh mpl traffic-eng tunnels backup | i Tunnel|172.17.0.2
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 P2‟s 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
RSVP Resv Info:
Record Route: NONE
Explicit Route: 172.19.24.1 172.17.0.2
Checking in the diagram in this route the expect path: PE4   PE5   P31   P2.
P1
Link Protected Next-Hop
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
July 10
RSVP bandwidth
PE-4# sh ip int bri

Protocol
Tunnel2 172.17.0.4 YES unset up down
PE-4# sh mpl tra tu tu2

Status:
Admin: up Oper: down Path: valid Signalling: RSVP signalling proceeding
Config Parameters: Status changed
Bandwidth: 100 kbps (Global) Priority: 4 4 after reducing
Affinity: 0x0/0xFFFF
Metric Type: TE (default) bandwidth
availablility in
the path.
Active Path Option Parameters: Before, P2 was
allocating
bandwidth for
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled two tunnels:
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,
History: one of the
Tunnel: tunnels went
Time since created: 13 hours, 29 minutes
down.
Time since path change: 1 minutes, 18 seconds
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

Protocol
After a couple of seconds the Tunnel 3 is still down. Let‟s check the tunnel status.
PE-4# sh mpl tra tu t3

Status:
Admin: up Oper: down Path: valid Signalling: RSVP signalling proceeding
Config Parameters: It is trying to
Bandwidth: 100 kbps (Global) Priority: 4 4 find a path of
Affinity: 0x0/0xFFFF
Metric Type: TE (default) this tunnel.
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
Current LSP:
After a minute later the Tunnel 3 is up.
July 10
PE-4# sh mpl tra tu t3
Config Parameters:
InLabel : -
RSVP Path Info:
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:
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)
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 path change: 6 seconds
Current LSP:
Uptime: 6 seconds
Selection: reoptimization
Prior LSP:
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
Let‟s check the RSVP status in P2 and P31.
P2# sh ip rsvp int S0/0 does NOT have
interface rsvp allocated i/f max flow max sub max bandwidth for RSVP
Se0/0 ena 0 0 0 0 reservation.
Se1/0 ena 100K 100K 100K 0
S1/0 and S2/0 have full
Se2/0 ena 100K 100K 100K 0
filled all bandwidth
Se3/0 ena 300K 155M 155M 0 capacity for RSVP.
Tu60000 ena 0 0 0 0
Tu60001 ena 0 0 0 0 So, there is not a
Tu60002 ena 0 0 0 0
bandwidth capacity
available for RSVP
Tu60003 ena 0 0 0 0
reservation when
Tu60004 ena 0 0 0 0
tunnel 3 has requested.
Tu60005 ena 0 0 0 0
Tu60006 ena 0 0 0 0 S0/0 connects to P1
which does not have
P2# sh ip rsvp installed
RSVP enabled.
RSVP: Serial0/0 has no installed reservations S1/0 connects to P3 and
RSVP: Serial1/0 has 100k bandwidth
BPS To From Protoc DPort Sport allocated.
0 172.17.0.3 172.17.0.1 0 60000 1 S2/0 connects to P31 and
0 172.17.0.3 172.17.0.31 0 60005 1 has 100k bandwidth
100K 172.17.0.6 172.17.0.4 0 2 8822 allocated.
0 172.17.0.7 172.17.0.31 0 60004 1
0 172.17.0.32 172.17.0.5 0 60004 1
RSVP: Serial2/0
0 172.17.0.4 172.17.0.2 0 60000 1
100K 172.17.0.5 172.17.0.6 0 3 9469
0 172.17.0.5 172.17.0.4 0 60000 20
0 172.17.0.5 172.17.0.2 0 60001 1
0 172.17.0.6 172.17.0.2 0 60003 2249
0 172.17.0.31 172.17.0.5 0 60002 1
0 172.17.0.31 172.17.0.4 0 60004 1
0 172.17.0.31 172.17.0.7 0 60004 1
0 172.17.0.32 172.17.0.2 0 60006 2141
RSVP: Serial3/0
100K 172.17.0.4 172.17.0.5 0 1 3666
100K 172.17.0.4 172.17.0.6 0 2 514
100K 172.17.0.4 172.17.0.7 0 2 5455
0 172.17.0.4 172.17.0.5 0 60000 27
0 172.17.0.5 172.17.0.31 0 60000 1
P31# sh ip rsvp int Then, S0/0 interface

which connects to P30
is the best option.
Se0/0 ena 300K 155M 155M 0
Se1/0 ena 0 0 0 0
Se2/0 ena 200K 155M 155M 0 RSVP is not enabled in
Se3/0 ena 200K 155M 155M 0 S1/0 interface which
. . . [ output omitted ] 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
Status:
Config Parameters:
InLabel : -
RSVP Path Info:
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2
172.17.0.7
Record Route:
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)
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.2
172.17.0.7
History:
Tunnel:
Current LSP:
Uptime: 1 minutes, 41 seconds
Prior LSP:
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

Status:
Config Parameters:
Again, the Tunnel 3 is
not using the best path
InLabel : - we would expect.
RSVP Path Info:
Explicit Route: 172.19.45.2 172.19.53.9 172.19.131.2 172.19.137.2
172.17.0.7
Record Route:
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)
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 path change: 54 seconds Look at this time, the
unconstrained Path
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.
July 10
Let‟s check the status in P2.
P2# sh ip rsvp int
Se0/0 ena 0 155M 155M 0
Se1/0 ena 0 155M 155M 0
Se2/0 ena 0 155M 155M 0
Se3/0 ena 0 155M 155M 0
Tu60000 ena 0 0 0 0
Tu60001 ena 0 0 0 0
Tu60002 ena 0 0 0 0
Tu60003 ena 0 0 0 0
Tu60004 ena 0 0 0 0
Tu60005 ena 0 0 0 0
Tu60006 ena 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
This command do not show if MPLS/TE is enabled or not. This message indicates
P2# sh mpl traffic-eng tunnels summary that mpls traffic-eng
Signalling Summary: global command is not
LSP Tunnels Process: not running, disabled enabled in this router.
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
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
tib entry: 172.16.36.0/30, rev 65
tib entry: 172.16.67.0/30, rev 66
tib entry: 172.17.0.3/32, rev 71
PE-4# sh mpl forwarding-table

Tag switching is not operational.
CEF or tag switching has not been enabled.
PE-4# sh cef int

CEF not running
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
PE-4# sh mpl ldp discovery

Local LDP Identifier:
172.17.0.4:0
Discovery Sources: No LDP received on
Interfaces: Serial 1/0 interface
LDP Id: 172.17.0.2:0
Serial1/0 (ldp): xmit
July 10
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

O 172.17.8.84 [110/97] via 10.40.31.6, 00:00:09, Serial2/0
O 172.17.8.83 [110/49] via 10.40.31.6, 00:00:09, Serial2/0
O 10.40.31.0/30 [110/96] via 10.40.31.6, 00:00:09, Serial2/0
PE-4#
% Network not in table
PE-4#
PE-4#
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

C 4.4.4.4 is directly connected, Loopback1
O 172.17.8.84 [110/97] via 10.40.31.6, 00:04:26, Serial2/0
O 172.17.8.83 [110/49] via 10.40.31.6, 00:04:26, Serial2/0
C 10.40.31.4 is directly connected, Serial2/0
O 10.40.31.0 [110/96] via 10.40.31.6, 00:04:26, Serial2/0
July 10
PE-4# sh ip bgp vpn 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 ?


*> 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
*>i6.6.6.6/32 172.17.0.6 100 100 0 i
*>i7.7.7.7/32 172.17.0.7 100 100 0 i
*>i10.33.31.0/30 172.17.0.6 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
*>i10.33.31.4/30 172.17.0.6 0 100 0 ?
* i 172.17.0.7 144 100 0 ?
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
ip vrf forwarding VPN Because there is at least a vrf importing
ip vrf forwarding VPN 212.182.144.1:18 route-target, we can see these
prefixes on “global bgp database” otherwise the
BGP process will drop these prefixes.
PE-4# sh ip bgp vpn all 10.33.31.0
Flag: 0x820
Local
172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8)
Local
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 It did not accept any
route-target export 25135:18 VPNv4 prefixes.
Reasons:
There isn‟t vrf import
prefixes which RT
BGP router identifier 172.17.0.4, local AS number 25135 value advertised by
BGP table version is 4018, main routing table version 4018 these neighbours.
5 path entries using 340 bytes of memory Or there is a inbound
filter denying all
prefixes, such as route-
map, prefix-list
assigned to these
0 BGP route-map cache entries using 0 bytes of memory neighbours.
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2625 total bytes of memory Or RR is not
BGP activity 103/98 prefixes, 257/252 paths, scan interval 15 secs adversiting prefixes to
PE-4.
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
172.17.0.8 4 25135 279840 87206 4018 0 0 00:51:02 0
172.17.0.9 4 25135 279840 87206 4018 0 0 00:51:02 0


*> 4.4.4.4/32 0.0.0.0 100 32768 i Local prefixes only:
*> 10.40.31.0/30 10.40.31.6 96 32768 ? learnt via local CE or
*> 10.40.31.4/30 0.0.0.0 0 32768 ? genered via local BGP
process (next-hop =
*> 172.17.8.83/32 10.40.31.6 49 32768 ?
0.0.0.0)
*> 172.17.8.84/32 10.40.31.6 97 32768 ?
RR1# sh ip bgp vpn all nei 172.17.0.4 adv


*>i4.4.4.4/32 172.17.0.4 100 100 0 i
*>i10.40.31.0/30 172.17.0.4 96 100 0 ?
*>i10.40.31.4/30 172.17.0.4 0 100 0 ?
*>i172.17.8.83/32 172.17.0.4 49 100 0 ?
July 10
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 table version is 208, main routing table version 208 Only 172.17.0.9 is
19 network entries using 2527 bytes of memory configured as route-
19 path entries using 1292 bytes of memory reflector-client.
17/16 BGP path/bestpath attribute entries using 2244 bytes of memory However this
1 BGP AS-PATH entries using 24 bytes of memory neighbour is not
4 BGP extended community entries using 204 bytes of memory adversiting any
0 BGP route-map cache entries using 0 bytes of memory prefixes to RR1.
0 BGP filter-list cache entries using 0 bytes of memory All other neighbours
BGP using 6291 total bytes of memory now are normal
BGP activity 97/78 prefixes, 110/91 paths, scan interval 15 secs iBGP.

State/PfxRcd
172.17.0.4 4 25135 78 278 203 0 0 00:01:46 5
172.17.0.5 4 25135 87354 280837 203 0 0 00:01:47 1
172.17.0.6 4 25135 92716 280837 203 0 0 00:01:45 6
172.17.0.7 4 25135 92754 280837 203 0 0 00:01:49 7
172.17.0.9 4 25135 281058 280857 208 0 0 00:00:15 0
RR1#
RR1# sh ip bgp vpn all n 172.17.0.4 adv

4 BGP extended community entries using 204 bytes of memory No prefixes
0 BGP route-map cache entries using 0 bytes of memory received/learnt/accept.
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3369 total bytes of memory

State/PfxRcd
172.17.0.8 4 25135 280902 87435 4018 0 0 00:06:25 0
172.17.0.9 4 25135 281289 87395 4018 0 0 01:22:39 0
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
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
* 10.40.31.5, from 4.4.4.4, 00:25:58 ago, via Serial1/0
CE-1# trace 172.17.8.52

Link between PE7 and CE-4
1 10.40.31.5 20 msec 20 msec 20 msec
2 172.19.24.1 36 msec 20 msec 20 msec
3 172.19.23.2 16 msec 32 msec 20 msec
4 172.19.32.2 16 msec 20 msec 16 msec
5 10.33.31.9 20 msec 20 msec 20 msec
6 10.33.31.10 20 msec * 20 msec

BGP next-hop:
Redistributing via ospf 1 PE-7
Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn and CE-4
Status as soon as PE7 reloads.

BGP next-hop:
Redistributing via ospf 1 PE-6
Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn
and CE-4
July 10
Tunnel which destines to
PE7 is down.
PE-4# sh ip int bri
Protocol
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]:
Sending 10000, 100-byte ICMP Echos to 172.17.8.52, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
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

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
* 10.40.31.5, from 4.4.4.4, 00:46:40 ago, via Serial1/0
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:
Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn RR1
PE-4# trace vrf VPN 172.17.8.52

4 10.33.31.9 [MPLS: Label 34 Exp 0] 28 msec 28 msec 32 msec
5 10.33.31.10 44 msec * 48 msec
Path did not
Status as soon as RR failure: change after RR
PE-4# traceroute vrf VPN 172.17.8.52 failure
4 10.33.31.9 [MPLS: Label 34 Exp 0] 24 msec 20 msec 44 msec
5 10.33.31.10 20 msec * 28 msec

Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn RR2
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 route-
reflector will be in BGP vrf database).
PE-4# ping vrf VPN
Protocol [ip]:
Repeat count [5]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Sending 10000, 100-byte ICMP Echos to 172.17.8.52, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
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:
Config Parameters:
InLabel : -
OutLabel : GigabitEthernet3/2, 82
Path: PE4 P2P3P32PE7
RSVP Path Info:
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
Record Route:
RSVP Resv Info:
Record Route: 172.17.0.2(82) 172.19.23.1(82) Check these labels with
172.17.0.3(112) 172.19.32.1(112) trace mpls traffic-eng
172.17.0.32(112) 172.19.137.2(112) command.
172.17.0.7(0) 172.19.137.1(0)
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Prior LSP:
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: '!' - success, 'Q' - request not transmitted,

'.' - timeout, 'U' - unreachable,
'R' - downstream router but not target,
'M' - malformed request

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 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 Gi3/0/0 172.19.23.1
112 112 172.17.0.4 2 [3069] 96047 Gi2/0/4 172.19.32.2
By coincidence in P3 the incoming label is the same as outgoing label.
P32> sh mpl forw | i 112
61 49 10.59.27.112/30 0 Gi3/0 172.19.32.1
58 10.59.27.112/30 0 PO2/0 point2point
112 Pop tag 172.17.0.4 2 [3069] 106274 Gi3/2 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
Time source is NTP, 11:58:21.219 GMT Fri Mar 2 2007
PE4-PEXKS01_t2
Outbound: FRR Ready
Tu60006: out i/f: Gi3/3, label: 249
Tail-end for this LSP signalling info:
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
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
Name: PE4-PEXKS01_t60006 (Tunnel60006) Destination: 172.17.0.3

Status:
path option 1, type explicit __dynamic_tunnel60006 (Basis for Setup, path
weight 1401)
Config Parameters:
AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
State: explicit path option 1 is active
InLabel : -
RSVP Path Info:
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
RSVP Resv Info:
Record Route: NONE
Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3
History:
Tunnel:
Time since created: 37 minutes, 37 seconds
Current LSP:
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 P1
Next-Next -Hop
for this tunnel
PE-4 – T60006
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
July 10
2nd checking:
Status did NOT
Link failure between P2 and PE4: change!
PE4-PEXKS01# sh mpl traff tun tu 2

Status:
Change in required resources detected: reroute pending
Currently Signalled Parameters:
Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity:
0x0/0xFFFF
Metric Type: TE (default) 4th checking: In back ground it is
path option 1 reoptimization in progress being calculated the new path for
primary tunnel. This occurs due
Config Parameters: to the dynamic path configuration
Bandwidth: 100 kbps (Global) Priority: 4 4 and reoptimaztion
Affinity: 0x0/0xFFFFpath being
Metric Type: TE (default) enabled.
st
InLabel : - 1 checking: Backup
OutLabel : GigabitEthernet3/2, 82 tunnel in used. Check
FRR OutLabel : Tunnel60006, 112 (in use)
the trace mpls
command output in the
next path.
RSVP Path Info:
Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7
Record Route:
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=100used
kbits
we can NOT check the
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:
Current LSP:
Reopt. LSP:
Uptime: 1 seconds
Prior LSP:
July 10
The backupCodes: '!' - success, 'Q' - request not transmitted,

tunnel label is '.' - timeout, 'U' - unreachable,
the top of label These 4 “112” value are the
'R' - downstream router but not target, same. It is in the bottom of the
stack. 'M' - malformed request label stack. It is being
encapsulated into backup
Type escape sequence to abort. tunnel.
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 4 172.19.32.1 MRU 4470 [Labels: 112 Exp: 0] 3 ms P3 node
! 6 172.19.137.1 5 ms
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.


0 172.19.45.1 MRU 4470 [Labels: 25 Exp: 0]
! 4 172.19.137.1 1 ms
The path is PE4  PE5  P31  P32  PE7. As you have checked, P3 is not longer a hop for
the PE4-tunnel2.
Let‟s check the new information of PE4-tunnel 2 information.
July 10
Status:
Config Parameters:
Tunnel NEVER
Metric Type: TE (default) went down.
InLabel : -
OutLabel : GigabitEthernet3/3, 25 New path
RSVP Path Info:
Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1
172.17.0.7
Record Route:
RSVP Resv Info: New LSP labels
Record Route: 172.17.0.5(25) 172.19.53.9(25) – Check with
172.17.0.31(81) 172.16.131.1(81) previous
172.17.0.32(86) 172.19.137.2(86) command (trace
172.17.0.7(0) 172.19.137.1(0) mpls traffic-
Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits eng).
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
Number of LSP IDs (Tun_Instances) used: 2856 can prove only
Current LSP: the path has
Uptime: 1 minutes, 32 seconds changed.
Prior LSP:
Removal Trigger: re-route path error
P1
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
July 10
Link failure between P2 and P3
Status:
Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity:
0x0/0xFFFF
Metric Type: TE (default) In back ground it is being
path option 1 reoptimization in progress calculated the new path for
primary tunnel.
Config Parameters:
InLabel : -
OutLabel : GigabitEthernet3/2, 124 No information this
FRR OutLabel : Tunnel60006, 108 backup tunnel being in
RSVP Signalling Info: used.
RSVP Path Info:
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
Record Route:
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)
Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Reopt. LSP:
Prior LSP:
Removal Trigger: reoptimization completed
July 10

'.' - timeout, 'U' - unreachable, The backup tunnel label
'R' - downstream router but not target, is the top of label stack.

0 172.19.24.2 MRU 4470 [Labels: 124 Exp: 0] P31 is PHP, so it is being
R 1 172.19.24.1 MRU 4466 [Labels: 84/96 Exp: 0/0] 4 ms
removed the backup
label of label stack.
U 2 172.19.31.2 MRU 4474 [Labels: 96 Exp: 0] 1 ms
! 4 172.19.137.1 3 ms
The backup tunnel activated here is P3-node protection. The rendezvous point between primary and backup
tunnels is P32. Why the packet didn‟t pass P32 P3 link twice?
P1
Node protected.
PE4 P2 P3 PE6
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.


0 172.19.24.2 MRU 4470 [Labels: 91 Exp: 0]
! 4 172.19.137.1 3 ms
P1
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
July 10

Status:
Config Parameters:
InLabel : -
RSVP Path Info:
Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1
172.17.0.7
Record Route:
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)
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Uptime: 38 seconds
Prior LSP:
July 10
Before link failure:
0 172.19.24.2 MRU 4470 [Labels: 141 Exp: 0]
! 4 172.19.137.1 3 ms
PE4  P2  P3  P32  PE7
After link failure:

Because P32 is the last
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:
New Path PE4  P2 P31  P32 PE7
0 172.19.24.2 MRU 4470 [Labels: 100 Exp: 0]
! 4 172.19.137.1 4 ms
July 10
PE4-PEXKS01# sh mpl tra tu tu2

Status:
Config Parameters:
InLabel : -
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
Record Route: traffic-eng output in the
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100previous
kbits page.
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)
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
Current LSP:
Prior LSP:
The primary tunnel details before link failure.
July 10
Output during new path calculation, meanwhile the backup tunnel is be used:

Status:
path option 1 reoptimization in progress
As soon as the new path was defined:


Status:
path option 1, delayed clean in progress
Config Parameters:
InLabel : -
RSVP Path Info:
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
failure. The same result
RSVP Resv Info:
Record Route: 172.17.0.2(100) 172.19.31.1(100)
as the third trace mpls
172.17.0.31(97) 172.16.131.1(97) traffic-eng output in two
172.17.0.32(94) 172.19.137.2(94) page before.
172.17.0.7(0) 172.19.137.1(0)
Explicit Route: 172.19.24.1 172.19.31.2 172.16.131.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Uptime: 4 seconds
July 10
Before link failure:


0 172.19.24.2 MRU 4470 [Labels: 106 Exp: 0]
! 4 172.19.137.1 2 ms
Path: PE4 P2  P3  P32  PE7
After link failure meanwhile the backup tunnel is being used:



0 172.19.24.2 MRU 4470 [Labels: 106 Exp: 0]
Link P32 P3 twice.
Because P32 is PHP for
the primary tunnel, we
R 3 172.19.32.2 MRU 4470 [Labels: 104 Exp: 0] 1 ms do NOT see two labels in
R 4 172.19.32.1 MRU 4470 [Labels: 129 Exp: 0] 2 ms label stack.
U 5 172.16.36.2 MRU 4474 [implicit-null] 3 ms
! 6 172.16.67.2 4 ms
P1
PE4 P2 P3 PE6
P30
PE5 P31 P32 PE7
July 10
P Node Failure
P2 failure
Information before failure:

Status:
Config Parameters:
InLabel : -
RSVP Path Info:
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
Record Route:
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)
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Uptime: 23 seconds
Prior LSP:
July 10
PE4-PEXKS01# sh mpl traf tu tu 2 protection
PE4-PEXKS01_t2
Outbound: FRR Ready
Tu60006: out i/f: Gi3/3, label: 54
Original: out i/f: Gi3/2, label: 63, nhop: 172.19.24.1



0 172.19.24.2 MRU 4470 [Labels: 63 Exp: 0]
! 4 172.19.137.1 3 ms
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 didn‟t 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.


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
Status:
Bandwidth: 100 Even though
kbps (Global) Priority: 4 4 in Affinity:
Data Plane the path can still
0x0/0xFFFF be used; Control Plane received a signal to
Metric Type: TE (default) recalculate a new path. In the next pages there
path option 1 reoptimization in progress are some debug commands to identify this
signal (ISIS flag; there is not RSVP flag for
Config Parameters: this pariticula case.
Even though it is running the path calculation the backup
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 Path Info:
Explicit Route: 172.19.24.1 172.19.23.2 172.19.32.2 172.19.137.1
172.17.0.7
Record Route:
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)
Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Reopt. LSP:
Prior LSP:
July 10
After path calculation:


0 172.19.45.1 MRU 4470 [Labels: 26 Exp: 0]
! 4 172.19.137.1 2 ms
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:
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)
Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1
172.17.0.7
History:
Tunnel:
Current LSP:
Uptime: 3 seconds
Prior LSP:
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
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]
metric [115/1280]
metric [115/2560]
metric [115/1320]
metric [115/2041]
metric [115/1320]
metric [115/2041]
metric [115/761]
metric [115/1320]
metric [115/721]
metric [115/1280]
metric [115/761]
July 10
metric [115/1320]
metric [115/1761]
metric [115/2320]
metric [115/1680]
metric [115/2401]
metric [115/680]
metric [115/1401]
metric [115/640]
002650: Mar 2 18:08:37.106 GMT: RT: delete subnet route to 172.17.0.2/32
metric [115/680]
metric [115/1401]
002653: Mar 2 18:08:37.106 GMT: RT: del 194.164.243.141/32 via 172.19.24.1,
isis metric [115/791]
002654: Mar 2 18:08:37.106 GMT: RT: add 194.164.243.141/32 via 172.19.45.2,
isis metric [115/1512]
metric [115/791]
metric [115/1512]
metric [115/791]
metric [115/1512]
metric [115/790]
metric [115/1511]
metric [115/740]
metric [115/1611]
metric [115/780]
metric [115/1501]
metric [115/790]
metric [115/1511]
metric [115/1960]
PE4-PEXKS01#
metric [115/2
600]
metric [115/1320]
002670: Mar 2 18:08:37.106 GMT: RT:
002671: Mar 2 18:08:38.114 GMT: RT(VOIP): 10.18.115.0/24 gateway changed from
172.17.0.6 to 172.17.0.7
002672: Mar 2 18:08:38.114 GMT: RT(VOIP): 10.220.132.0/23 gateway changed from
10.59.255.253 to 10.59.255.254
July 10
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:

Status:
Config Parameters:
InLabel : -
FRR OutLabel : Tunnel60006, 86 (in use) Backup tunnel in used.
RSVP Path Info:
Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7
Record Route:
July 10
RSVP Resv Info:
Record Route: 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)
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
Current LSP:
Reopt. LSP:
Prior LSP:
After path re-calculation

PE4-PEXKS01# tra mpl tra tu 2


0 172.19.45.1 MRU 4470 [Labels: 49 Exp: 0]
! 4 172.19.137.1 2 ms
July 10

Status:
Config Parameters:
InLabel : -
RSVP Path Info:
Explicit Route: 172.19.45.2 172.19.53.10 172.16.131.2 172.19.137.1
172.17.0.7
Record Route:
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)
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
Current LSP:
Reopt. LSP:
Prior LSP:
July 10
AToM issues
PE-7# sh mpl l2transport vc 100
Local intf Local circuit Dest address VC ID Status

------------- -------------------------- --------------- ---------- ----------
Se2/0 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
no ip address
no cdp enable
end
July 10
Figure 12 - Lab topology for LINK and NODE failures scenarios
F
AX4000 6 E
5 (topacket generator
4 GE
ports under test)
E1
CHOC3-E1
3 1 2
stm
FE
STM1 or STM4
1/4
GE
/4
10GE
stm1
0
3/2
POS CHOC48
POS STM16
GE 3/20 172.17.8.51
POS STM1 172.17.7.83 0/1
FE 172.17.0.8 172.16.18.0/30
2/2 6509-1 6509-3
RR1 2/0/0
1/2 1/2 2/2
10.40.31.6 vlan98
1/1 5/8 1/1

172.17.0.1
10.33.31.6 vlan98
P1
2/
0/ 17
1
0/
3 2.
3/0.98 10.40.31.5
30
3/0.98 10.33.31.5
2/1/1
172.19
2/
19
0/
.1
2.
3.
.1
0
19
2/ /30 3/1
.30.0/3
1/6
3/3
2.
0/
3/1
0/
17
3
2/
3/0 3/0
1/6
10.59.95.82/30 Gn
0
172.17.0.4 172.17.0.2 172.17.0.3 172.17.0.6
3/0/0 172.19.23.0/30 3/0/0 172.16.36.0/30
2/0/2 3/2
PE4 P2 P3 3/1
3/2 172.19.24.0/30 4/0/1 PE6
3/3 2/0/4 2/0/4 0/2
3/2
172.19
172.17.0.30
172.19.45.0/30
172.16.67.0/30
QOS test targets

172.19 P30
.32
.0/30
30
.3
3/3
17
0/1
1.0/30
0/
0/2
2.
0.
0/1
16
13
172.19.29.8./30
.1
6.
32
1
2. 172.17.0.9
.0
3/0
17
/3
3/0/3 3/1 0/2
0
3/0
RR2
3/0/4
0/2
172.17.0.5 172.17.0.31 172.17.0.32 172.19.137.0/30 172.17.0.7
3/0/2 .9 172.19.53.8/30 .103/2 3/0/2
3/0/0.99 10.40.31.9 PE5 P31 3/3 172.19.131.0/30 3/3 P32 3/2 PE7
10.40.31.10 vlan99
3/0/0.99 10.33.31.9
3/0/3
3/0/0
3/0/0
3/0/8
3/0/9
5/8 1/1 10.33.31.10 vlan99

1/1 5/13 5/14
1/2
2/2 172.17.7.84 172.17.8.52 1/2
6509-2 6509-4 2/2
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 neighbour’s 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

Common Control Plane Issues
 Label distribution protocol does not match
 No route to the neighbor‟s 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

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 In-label Out intf/label FRR intf/label Status
Tunnel2 Tun hd Gi3/1:Untagged Tu60001:tag-impl ready
Tunnel10 Tun hd Gi3/1:Untagged Tu60006:870 ready
<output omitted>
LC-Slot3# sh mpls forwarding-table

16 Untagged l2ckt(329506200) 0 none point2point
<output ommited>
77 539 172.17.1.116/30 0 Gi3/1 172.17.1.10
79 326 172.17.2.168/30 0 Gi3/1 172.17.1.10
154 Pop tag 172.17.0.5/32 0 Gi3/0 172.17.3.10
155 Pop tag 172.17.16.16/30 0 Gi3/1 172.17.1.10
163 29 172.17.0.27/32 0 Gi3/1 172.17.1.10
164 22 172.17.0.20/32 0 Gi3/1 172.17.1.10
167 Pop tag 172.17.0.2/32 0 Tu2 point2point
185 Untagged 10.197.4.0/23[V] 0 Gi7/0/1.256 10.197.1.52
<output ommited>

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 PLU Loc Value Leaf Address (PLU/CPU) leaf-bit

16 0x28084040 0x01810766 0x00810766/0x30083B30 Clear
17 0x28084044 0x00010764 0x00010764/0x24083B20 Clear
18 0x28084048 0x0081075C 0x0081075C/0x28083AE0 Clear
22 0x28084058 0x0181065A 0x0081065A/0x300832D0 Clear
23 0x2808405C 0x000107EA 0x000107EA/0x24083F50 Clear
24 0x28084060 0x01010774 0x00010774/0x2C083BA0 Clear
25 0x28084064 0x01810774 0x00810774/0x30083BA0 Clear
26 0x28084068 0x00010772 0x00010772/0x24083B90 Clear
27 0x2808406C 0x00810772 0x00810772/0x28083B90 Clear
28 0x28084070 0x00810782 0x00810782/0x28083C10 Clear
29 0x28084074 0x01010782 0x00010782/0x2C083C10 Clear
30 0x28084078 0x01810782 0x00810782/0x30083C10 Clear
31 0x2808407C 0x00010780 0x00010780/0x24083C00 Clear
32 0x28084080 0x00810780 0x00810780/0x28083C00 Clear
<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 PLU Loc Value Leaf Address (PLU/CPU) leaf-bit

16 0x28084040 0x01810766 0x00810766/0x30083B30 Clear
17 0x28084044 0x00010764 0x00010764/0x24083B20 Clear
18 0x28084048 0x0081075C 0x0081075C/0x28083AE0 Clear
22 0x28084058 0x0181065A 0x0081065A/0x300832D0 Clear
23 0x2808405C 0x000107EA 0x000107EA/0x24083F50 Clear
24 0x28084060 0x01010774 0x00010774/0x2C083BA0 Clear
25 0x28084064 0x01810774 0x00810774/0x30083BA0 Clear
26 0x28084068 0x00010772 0x00010772/0x24083B90 Clear
27 0x2808406C 0x00810772 0x00810772/0x28083B90 Clear
28 0x28084070 0x00810782 0x00810782/0x28083C10 Clear
29 0x28084074 0x01010782 0x00010782/0x2C083C10 Clear
30 0x28084078 0x01810782 0x00810782/0x30083C10 Clear
31 0x2808407C 0x00010780 0x00010780/0x24083C00 Clear
32 0x28084080 0x00810780 0x00810780/0x28083C00 Clear
33 0x28084084 0x01010780 0x00010780/0x2C083C00 Clear
34 0x28084088 0x01810780 0x00810780/0x30083C00 Clear
35 0x2808408C 0x0001077E 0x0001077E/0x24083BF0 Clear
36 0x28084090 0x0081077E 0x0081077E/0x28083BF0 Clear
<output ommited>

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# debug ip rsvp fast-reroute

PE4-PEXKS01# debug ip rsvp resv
PE4-PEXKS01# debug ip rsvp path
PE4-PEXKS01# debug ip rsvp signalling
PE4-PEXKS01#
002297: Mar 2 17:35:21.702 GMT: RSVP: Sending Srefresh message to 172.19.24.1
PE4-PEXKS01#
PE4-PEXKS01#
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

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
Succeeded, returning RRR ID 172.17.0.5 ADDR 172.17.0.5 Label 0x31
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-
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-
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:
002335: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803-
address 172.17.0.5 Label 00000031 flags 20
002336: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803-

002340: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803-
002341: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803-
002343: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803-
002344: Mar 2 17:35:25.277 GMT: RSVP-FRR 172.17.0.4_3803-
002346: Mar 2 17:35:25.277 GMT: RSVP-FRR: rsvp_frr_parse_ero_rro: In RRO,
found:
PE4-PEXKS01#
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
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#
002358: Mar 2 17:35:28.272 GMT: %MPLS_TE-5-TUN: Tun2: LSP path change 2_3803 for 2_3744, re-
route path verification failed
PE4-PEXKS01#
002360: Mar 2 17:35:29.992 GMT: %CLNS-5-ADJCHANGE: ISIS: Adjacency to P2
(GigabitEthernet3/2) Down, hold time expired
PE4-PEXKS01#

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-
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-
NNHOP Addrs/Labels:
002372: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002373: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002377: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002378: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002380: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002381: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
found:
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

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-
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
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-
NNHOP Addrs/Labels:
002397: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002398: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002402: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002403: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002405: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
002406: Mar 2 17:35:30.312 GMT: RSVP-FRR 172.17.0.4_2685-
found:
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

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-
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
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:
002419: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803-
002420: Mar 2 17:35:32.843 GMT: RSVP-FRR 172.17.0.4_3803-
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-
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-
found:
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
002435: Mar 2 17:35:33.311 GMT: %MPLS_TE-5-TUN: Tun1: LSP path change 1_2685 for 1_2626, re-
route path verification failed
002436: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803-
NNHOP Addrs/Labels:

002439: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803-
002440: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803-
002444: Mar 2 17:35:33.767 GMT: RSVP-FRR 172.17.0.4_3803-
002445: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803-
002447: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803-
PE4-PEXKS01#
002448: Mar 2 17:35:33.771 GMT: RSVP-FRR 172.17.0.4_3803-
found:
PE4-PEXKS01#
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-
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-
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#

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-
PE4-PEXKS01#
002481: Mar 2 17:35:39.834 GMT: RSVP: 172.17.0.4_3744-
PE4-PEXKS01#
002482: Mar 2 17:35:41.854 GMT: RSVP: 172.17.0.4_3744-
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-
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-
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-
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-
002492: Mar 2 17:35:43.853 GMT: RSVP: 172.17.0.4_2626-
PE4-PEXKS01#
002493: Mar 2 17:35:44.873 GMT: RSVP: 172.17.0.4_2626-
002494: Mar 2 17:35:45.873 GMT: RSVP: 172.17.0.4_3744-
PE4-PEXKS01#
002495: Mar 2 17:35:46.893 GMT: RSVP: 172.17.0.4_2626-
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.19.45.2
002499: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_1-
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

002501: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_3057-
172.19.45.2
002502: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.4_306-
172.19.45.2
002503: Mar 2 17:35:48.792 GMT: RSVP: 172.17.0.3_1-
172.19.45.2
002511: Mar 2 17:35:50.912 GMT: RSVP: 172.17.0.4_2626-
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
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-
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

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

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
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.

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
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 tcp -> 10.40.31.2
ttcp-t: connect (mss 536, sndwnd 4128, rcvwnd 4128)
(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 Total of time for

transmission. Sender
ttcp-t: 0 sleeps (0 ms total) (0 ms average)
respective.
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 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

irs: 3904303256 rcvnxt: 3904303257 rcvwnd: 4128 delrcvwnd: 0
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 Total of time for

ttcp-r: 0 sleeps (0 ms total) (0 ms average) transmission.
Connection state is CLOSEWAIT, I/O status: 7, unread input bytes: 0Receiver respective.
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 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 snduna: 3904303257 sndnxt: 3904303257 sndwnd: 4128

irs: 2600288481 rcvnxt: 2617065699 rcvwnd: 3976 delrcvwnd: 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

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 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
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
Note that each interface
has its own ifName
.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
Interface of
.1.3.6.1.2.1.31.1.1.1.1.3: PO0/1
index 3.
.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 Value of the query
.1.3.6.1.2.1.31.1.1.1.1.7: AT1/1 In this case it is ifName value
.1.3.6.1.2.1.31.1.1.1.1.8: AT1/2 for interface index 9. In this
.1.3.6.1.2.1.31.1.1.1.1.9: AT1/3 case it is the ATM 1/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 This is the
.1.3.6.1.2.1.31.1.1.1.1.12: AT1/6 ifHCInOctest
<snip>

.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
Interface of
.1.3.6.1.2.1.31.1.1.1.6.4: 0 index 1.
.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
Interface of
.1.3.6.1.2.1.31.1.1.1.6.8: 0 index 14.
.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 Value of the query
.1.3.6.1.2.1.31.1.1.1.6.12: 0 In this case it is
.1.3.6.1.2.1.31.1.1.1.6.13: 0 ifHCInOctest value for
.1.3.6.1.2.1.31.1.1.1.6.14: 6611579242127 interface index 16.
.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
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

.1.3.6.1.2.1.31.1.1.1.1.12: AT1/6
.1.3.6.1.2.1.31.1.1.1.1.13: AT1/7
.1.3.6.1.2.1.31.1.1.1.1.14: Gi3/0/0
.1.3.6.1.2.1.31.1.1.1.1.15: 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

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 import 25135: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
!

key chain ISIS
key 1
key-string 7 1043101D0A10
!
interface Loopback0
ip address 172.17.0.4 255.255.255.255
!
interface Loopback1
ip vrf forwarding VPN
ip address 4.4.4.4 255.255.255.255
!
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 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
ip router isis
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
ip router isis
tag-switching ip
isis metric 100 level-1

interface Serial2/0
no ip address
no cdp enable
!
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
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
!
address-family vpnv4
neighbor mpbgp activate

neighbor mpbgp send-community both
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 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
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

P2
version 12.0
service nagle
no service pad
!
hostname P2
!
boot-start-marker
boot-end-marker
!
no logging on
enable secret 5 $1$uTdy$GJINJn/02YFW3fT104OG5.
!
ip subnet-zero
ip cef
no ip domain-lookup
mpls ldp neighbor 172.17.0.3 password 7 094F471A1A0A
mpls ldp neighbor 172.17.0.31 password 7 0822455D0A16
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
!
key chain ISIS
key 1
key-string 7 110400011815
!
interface Loopback0
ip address 172.17.0.2 255.255.255.255
!
interface Serial0/0
ip address 172.19.12.2 255.255.255.252

ip router isis
tag-switching ip
no fair-queue
!
interface Serial1/0
ip address 172.19.23.1 255.255.255.252
ip router isis
mpls traffic-eng backup-path Tunnel40
tag-switching ip
!
interface Serial2/0
ip address 172.19.31.1 255.255.255.252
ip router isis
tag-switching ip
fair-queue 64 256 63
!
interface Serial3/0
description >>>> link to PE4
ip address 172.19.24.1 255.255.255.252
ip router isis
tag-switching ip
fair-queue 64 256 63
!
router isis
net 10.0000.0000.0002.00

ispf level-2
metric-style wide level-2
spf-interval 5 1 50
prc-interval 5 1 50
!
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
!
hostname RR1
!
boot-start-marker
boot-end-marker

enable secret 5 $1$tOku$A7DT/0Bv7IvSGM9psLuiU/
!
ip subnet-zero
ip cef
no ip domain-lookup
mpls traffic-eng reoptimize timers frequency 30
!
key chain ISIS
key 1
key-string 7 110400011815
!
interface Loopback0
ip address 172.17.0.8 255.255.255.255
!
interface Serial0/0
ip address 172.16.18.2 255.255.255.252
ip router isis
tag-switching ip
no fair-queue
!
router isis
net 10.0000.0000.0008.00
ispf level-2
metric-style wide level-2
spf-interval 5 1 50
prc-interval 5 1 50
!
router bgp 25135

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.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.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

Glossary
Term Definition
AAL ATM Adaptation Layer
ATM Asynchronous Transfer Mode
AToM Any Transport over MPLS
BGP Border Gateway Protocol
CBR Constraint-Based Routing
CE Customer Edge Router
CEF Cisco Express Forwarding – Cisco latest packet switching method.
CLI Command-Line Interface
CLNS Connection Less Network Service
Control Plane Where control information, such as routing and label information is exchanged.
cSPF Constrained Shortest Path First
Data Plane / Where the actual forwarding occurs. This can only exist after the control plane has been
Forwarding Plane established.
DiffServ Differentiated Services (One of the Model defined in QoS Architecture)
FEC Forward Equivalence Class
FIB Forwarding Information Base – The table that is created by enabled CEF.
FRR Fast Re-Route
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IntServ Integrated Services (One of the Model defined in QoS Architecture)
IP Internet Protocol
IS-IS Intermediate System to Intermediate System
Label MPLS header that is used for switch a packet
LDP Label Distribution Protocol
LFIB 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.
LSP Label Switch Path
LSR Label Switch Router
MP-BGP Multi-Protocol BGP
MPLS Multi Protocol Label Switching
N-HOP Next-Hop – Designation for “Link Protection” in FRR
NLRI Network Layer Reachability Information
NN-HOP Next-Next-Hop – Designation for “Node Protection” in FRR
OSPF Open Shortest Path First
P Provider Router
PE Provider Edge Router

PHP Penultimate Hop Popping
RIP Routing Information Base
RD Route Distinguished
RSVP Resource Reservation Protocol
SNPA Sub-network Points of Attachment
TDP Tag Distribution Protocol
TE Traffic Engineering
TTL Time To Live
VPN Virtual Private Network
VRF 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.

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

 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

About This MPLS - Troubleshooting
Guide
Author: Lizabete Ponte

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


MPLS Troubleshooting Guide

Uploaded by

Copyright:

Available Formats

MPLS Troubleshooting Guide

Uploaded by

Document Information

Original Description:

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

Document Purpose ...................................................................................................................6

Part 1: Technology Description ....................................................................................................7

MPLS and MPLS/VPN Introduction ..............................................................................................8

MPLS Features ..........................................................................................................................8

MPLS Traffic Engineering Introduction .................................................................................... 17

What is MPLS TE? ................................................................................................................. 17

AToM Introduction ...................................................................................................................... 23

Why implement AToM? ......................................................................................................... 23

July 10 Advanced Service 2

Essential MPLS/VPN configs ..................................................................................................... 27

Essential TE configs .............................................................................................................. 28

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

Troubleshooting commands ...................................................................................................... 46

MPLS and MPLS/VPN ............................................................................................................ 46

Part 5: Failure Scenarios ............................................................................................................ 94

Conclusion ................................................................................................................................. 141

Part 6: Appendix ........................................................................................................................ 143

Appendix I .................................................................................................................................. 144

Troubleshooting GSR forwarding ...................................................................................... 144

July 10 Advanced Service 3

Appendix II ................................................................................................................................. 162

Configuration used in lab .................................................................................................... 162

Glossary ..................................................................................................................................... 171

References ................................................................................................................................. 173

About This MPLS - Troubleshooting Guide ........................................................................... 175

History ................................................................................................................................... 175

July 10 Advanced Service 4

Figure 1 – Information Base 9

Figure 2 - Interactions between MPLS applications 11

Figure 3 – Routing look up using CEF and BGP prefixes 12

Figure 4 - Non BGP Route Propagation - Outbound 15

Figure 5 - Non BGP Route Propagation - Inbound 15

Figure 6 - Primary Tunnel Path 21

Figure 7 - Backup Tunnel - Node Protection 21

Figure 8 - Backup Tunnel - Link Protection 22

Figure 9 - AToM - Label exchanging 24

Figure 10 - AToM - frame forwarding 25

Figure 11 - Topology used in lab for capturing output 39

July 10 Advanced Service 5

July 10 Advanced Service 6

Part 1: Technology Description

July 10 Advanced Service 8

Figure 1 – Information Base

July 10 Advanced Service 9

What Are MPLS Label Operations?

July 10 Advanced Service 10

What Are The Interactions Between MPLS Application?

July 10 Advanced Service 11

The attribute contains one or more triples:

Figure 3 – Routing look up using CEF and BGP prefixes

For BGP prefixes the routing look up occurs twice:

July 10 Advanced Service 12

What Are Route Distinguishers (RD)?

What Are Route-Targets (RTs)?