MPLS - Troubleshooting Guide

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

Advanced Services

TM

http://www.cisco.com/

July 10 Advanced Service

A printed copy of this document is considered uncontrolled.

2

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



3

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



4

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



5

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



6

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

Part 1: Technology Description

TM



8

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.



9

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.



10

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.



11

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.



12

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.



13

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.



14

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



15

Figure 4 - Non BGP Route Propagation - Outbound

Figure 5 - Non BGP Route Propagation - Inbound

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

1

2

3

4

5

6

8

7

9

10



16

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

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml



17

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.



18

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.



19

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.



20

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.



21

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

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

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

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

Head End

Tail End Middle Point Middle Points Middle Points

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

Next-Next -Hop P1

P1



22

Figure 8 - Backup Tunnel - Link Protection

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.

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

Next-Hop Link Protected P1



23

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.



24

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

pop

2322

21

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.



25

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

DLCI 101

17

DLCI 202

17 21

17 22

17 23 17 17

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.

Part 2: Troubleshooting Methodology

TM



27

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



28

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.



29

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.

Part 3: Some MPLS Commands

TM



31

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.



32

interface <physical interface> Interface configuration mode 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.



33

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>

redistribute bgp 25135 subnets

network <range> <wildcard> area <area-id>

...

It defines an OSPF configuration in a vrf context.

You should redistribute BGP prefixes in order to local CE learns remote

prefixes. Do NOT forget the keyword subnets, otherwise the

subnetworks will not be redistributed, only classfull prefixes (such as

10.0.0.0/8). router bgp 25135

address-family ip vrf <vrf-name>

neighbor <ip-address> remote-as <as>

neighbor <ip-address> update-source <interface>

It defines a BGP configuration in a vrf context.

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]

redistribute ospf <id> vrf<name> match internal external1 external2 It redistributes the vrf prefixes into MP-BGP vrf database.

default-information originate It allows redistributing a default-route in routing table onto BGP database.



34

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>

match ...

set ...

It defines a set of rules/selection based on many values/attributes.



35

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

loopback 0 (Optional) It enables IP processing without an explicit address.

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.



36

interface <physical interface> Interface configuration mode 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.



37

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.



38

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.



39

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

Figure 11 - Topology used in lab for capturing output

6509-3

172.17.8.51

6509-4

172.17.8.52

PE7

172.17.0.7

PE6

172.17.0.6

RR1

172.17.0.8

P1

172.17.0.1

RR2

172.17.0.9

P32

172.17.0.32

P30

172.17.0.30

P31

172.17.0.31

P2

172.17.0.2

P3

172.17.0.3

PE4

172.17.0.4

PE5

172.17.0.5

6509-2

172.17.7.84

6509-1

172.17.7.83

s0/0s0/0

s0/0

s0/0

s2/0

s1/0

s3/0

s2/0

s1/0

s3/0

s0/0

s2/0

s2/0

s2/0

s2/0

s1/0

s1/0

s1/0

s1/0

s0/0s0/0

s3/0

s3/0

s3/0

s3/0s0/0

s0/0

s1/0

s1/0

s2/0

s0/0

s0/0

s0/0

s1/0

s1/0

s2/0

s1/0

s1/0s0/0

s2/0

s2/0

s2/0

s1/0

s1/0s0/0

s2/0

. ...

.

..

. ...

.

. . ..

... .. .

.

Loopback 0Interfaces.1

st host of sub-network /30

10.40.31.4/30

172.19.1

2.0/3

0

172.19.1

3.0/3

0

172.16.18.0/30

172.19.2

3.0/3

0

172.19.3

0.0/3

0

172.19.2

4.0/3

0

172.19.4

5.0/3

0

172.19.3

1.0/3

0

10.40.3

1.0/3

0

10.40.31.8/30

172.19.5

3.8/3

0

172.16.1

32.0/3

0

172.19.3

2.0/3

0

172.16.3

6.0/3

0

172.19.1

37.0/3

0

172.16.6

7.0/3

0

10.33.3

1.0/3

0

10.33.31.4/30

10.33.3

1.8/3

0

172.16.130.0/30

172.19.131.0/30

172.19.29.8/30

Links which do not have ISIS metric specified

are using the default value (metric = 10)

Metri

c = 6

40

Metri

c = 1

000 Metri

c = 1

000

Metri

c = 1

000

Metri

c = 6

40

Part 4: List of Show Commands

TM



41

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>



42

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>



43

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



44

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.



45

AToM Troubleshooting

show mpls l2transport vc

show mpls l2transport vc detail

show mpls l2transport summary



46

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:

172.17.0.4:0

Discovery Sources:

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.

:0 means per platform allocation.

(recommended mode of label

allocation in frame-mode).

:0 means per platform allocation.

(recommended mode of label

allocation in frame-mode).



47

PE-4# show mpl ldp neigh

Peer LDP Ident: 172.17.0.5:0; Local LDP Ident 172.17.0.4:0

TCP connection: 172.17.0.5.54266 - 172.17.0.4.646

State: Oper; Msgs sent/rcvd: 4067/4059; Downstream

Up time: 2d10h

LDP discovery sources:

Serial1/0, Src IP addr: 172.19.45.2

Addresses bound to peer LDP Ident:

172.19.53.10 172.17.0.5 172.19.45.2

Peer LDP Ident: 172.17.0.2:0; Local LDP Ident 172.17.0.4:0

TCP connection: 172.17.0.2.646 - 172.17.0.4.42241

State: Oper; Msgs sent/rcvd: 4054/4069; Downstream

Up time: 2d10h

LDP discovery sources:

Serial0/0, Src IP addr: 172.19.24.1

Addresses bound to peer LDP Ident:

172.19.12.2 172.17.0.2 172.19.23.1 172.19.31.1

172.19.24.1

It shows TCP connection status between neighbors.

PE-4# sh mpl ldp bindings

tib entry: 172.16.18.0/30, rev 40

local binding: tag: 30

remote binding: tsr: 172.17.0.2:0, tag: 28


tib entry: 172.17.0.2/32, rev 8


remote binding: tsr: 172.17.0.2:0, tag: imp-null


tib entry: 172.17.0.4/32, rev 4

local binding: tag: imp-null



tib entry: 172.19.45.0/30, rev 5

local binding: tag: imp-null

remote binding: tsr: 172.17.0.5:0, tag: imp-null


. . .

[output omitted]

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.

Neighbour‟s Prefixes (all

interfaces in global routing table).

This defines either

172.17.0.2 neighbour is the

destionation of 172.17.0.2/32

prefix, or this neighbour is in

MPLS border, beyond it it is

an IP network only (edge

LSR).

172.17.0.4/32 is a Loopback 0

IP address, local ip address

prefix, so PE-4 is sending a

POP label flag to its

neighbours.

Label to be

imposed 172.19.45,0/30 is a serial

address which connects PE-4 to

172.17.0.5 neighbor (PE-5), so

it is a local ip address prefix to

PE-4 and PE-5. Then, both are

sending POP label flag to their

neighbours.



48

PE-4# sh mpl ldp bind 172.16.18.0 30

tib entry: 172.16.18.0/30, rev 40




It shows the LIB (label control plane database).

PE-4# sh ip route 172.17.0.2

Routing entry for 172.17.0.2/32

Known via "isis", distance 115, metric 10, type level-2

Redistributing via isis

Last update from 172.19.24.1 on Serial0/0, 2d11h ago

Routing Descriptor Blocks:

* 172.19.24.1, from 172.17.0.2, via Serial0/0

Route metric is 10, traffic share count is 1

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




Last update from 172.19.24.1 on Serial0/0, 2d11h ago


* 172.19.24.1, from 172.17.0.1, via Serial0/0


It shows the RIB information (IP routing database).

PE-4# sh mpl forwarding-table 172.16.18.0

Local Outgoing Prefix Bytes tag Outgoing Next Hop

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

PE-4# sh ip cef 172.16.18.0 det

172.16.18.0/30, version 29, epoch 0, cached adjacency to Serial0/0

0 packets, 0 bytes

tag information set, all rewrites owned

local tag: 30

fast tag rewrite with Se0/0, point2point, tags imposed {28}

via 172.19.24.1, Serial0/0, 0 dependencies

next hop 172.19.24.1, Serial0/0

valid cached adjacency

tag rewrite with Se0/0, point2point, tags imposed {28}

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

Each neighbour

advertises their own

labels. In this case PE-

4 received two

advertisements for

172.16.18.0/30 prefix.

Checking RIB

and/or FIB this

is the best path

to reach

172.17.18.0/30

Checking RIB

and/or FIB this

is the best path

to reach

172.17.18.0/30

These labels

should match

with the

information

provided in

LIB, as

showed above.

Label to be

imposed

Label to be

imposed in label

data packet

going to serial

0/0 interface.



49

PE-4# sh mpl forwarding-table



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



50

In the next two pages we will analyse in detail two VRF prefixes in LIB, FIB and LFIB databases.

PE-4# sh ip route vrf VPN

[output omitted]

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

[output omitted]

PE-4# sh ip bgp vpn vrf VPN label

Network Next Hop In label/Out label

Route Distinguisher: 25135:133001804 (VPN)

4.4.4.4/32 0.0.0.0 47/aggregate(VPN)

5.5.5.5/32 172.17.0.5 nolabel/47

172.17.0.5 nolabel/47

[output omitted]

172.17.8.84/32 172.17.0.5 52/58

172.17.0.5 52/58

10.40.31.6 52/nolabel

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:

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,

mpls labels in/out 52/58


172.17.0.5 (metric 620) from 172.17.0.9 (172.17.0.9)





mpls labels in/out 52/58

Local

10.40.31.6 (via VPN) from 0.0.0.0 (172.17.0.4)

Origin incomplete,metric 97,localpref 100,weight 32768,valid, sourced, best


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

VRF prefixes leart via remote

PE. (via MP-iBGP – AD=200).

VRF prefixes leart via local

CE. (via CE-PE routing, in

this case OSPF). If it were

learnt via eBGP the AD

would be 20.

AD

AD

Administrative

Distance (AD).

Label learnt via MP-BGP,

from MP-BGP neighbour.

Label allocated locally and

advertise to all MP-BGP,

neighbours.

Path #1

Path #2

Path #3 Best Path. Path to be adverstised and to

populate the FIB/LFIB

Path #1

Path #2

Path #3



51

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


local tag: 52

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 {}





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


mpls labels in/out nolabel/47


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



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


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.

Why it does not imposed

labels?

Why it does imposed

labels in this case?

Best Path. Path to be adverstised and to

populate the FIB/LFIB

Path #1

Path #2



52

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

route-target export 212.183.144.1:18

route-target import 25135:18

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

PE-4# sh ip as-path-access-list 100

AS path access list 100

permit ^25000

permit ^$

PE-4# sh ip extcommunity-list

Extended community standard list 1

permit RT:1:1

permit RT:25135:133001804

„^‟ : means line which starts

with once space following by

route-target.

It selects BGP prefixes which in as-path attribute

value starts with the AS value 25000. (This means

the next AS hop to forward the path).

It selects BGP prefixes which in as-path attribute is

empty (This means only prefixes created in local-AS).

It selects MP-BGP prefixes which RT value is 1:1 or

25135:133001804



53

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

5 BGP extended community entries using 264 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 8579 total bytes of memory

BGP activity 37/4 prefixes, 100/21 paths, scan interval 15 secs

Neighbor 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

Neighbor capabilities:

Route refresh: advertised and received(new)

Address family IPv4 Unicast: advertised and received

[output omitted]

Any figures here

means the BGP

connection is being

established. Active or

Idle status means TCP

connection issue.

BGP capability been

negotiated during

Open sent and

confirmed state.



54

PE-4# sho ip bgp vpn all

BGP table version is 656741, local router ID is 172.17.0.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

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 ?

* i 172.17.0.7 96 100 0 ?

[output omitted]

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







*> 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 ?

*>i172.17.8.84/32 172.17.0.5 49 100 0 ?

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


RD created locally

as there is a vrf

assigned to it.

RD learnt from MP-

BGP neighbour as

there is no vrf

assigned to it.

Total of prefixes

adverstised to this

neighbour

Total of prefixes

learnt (and accept)

from this neighbour.



55

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

PE-4# sh ip ospf database

OSPF Router with ID (4.4.4.4) (Process ID 1)

Router Link States (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

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

10.33.31.3 4.4.4.4 1098 0x8000001D 0x15F4

10.33.31.3 5.5.5.5 726 0x8000001D 0xF60F

10.33.31.4 4.4.4.4 1618 0x8000001D 0xBFD

10.33.31.4 5.5.5.5 466 0x80000073 0x406E

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 0xC199

172.17.8.51 5.5.5.5 466 0x80000073 0xF60A

172.17.8.52 4.4.4.4 1618 0x8000001D 0xB7A2

172.17.8.52 5.5.5.5 466 0x80000073 0xEC13

Type-5 AS External Link States

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.

In P2P link we should

expect FULL state. In

broadcast link, if the local

router is neither a DR nor

BDR it could be 2-way

LSA 1 (router links), we should

expect one LSA per router in

an Area. The Link ID is the

router-id. In this case there are

4 routers in Area 0

LSA 2 (network links),

we this example there

is not network link in

area 0. If we have, it

would be one per

broadcast link. The

Link ID is the DR‟s

router-id.

LSA 3 (summary Net links),

we should expect one LSA per

prefix which comes from

another OSPF area.

Link-ID is the IP prefix

Adv Router is the ABR.

P.S.: Summary links DOES not

mean OSPF prefixes

summared.

LSA 5 (AS External links), we

should expect one LSA per

prefix which comes from

another IP routing process (via

redistribution command).

Link-ID is the IP prefix

Adv Router is the ASBR.



56

PE-4# sh ip ospf database router 172.17.8.83

OSPF Router with ID (4.4.4.4) (Process ID 1)

Router Link States (Area 0)

LS age: 1080

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 172.17.8.83

Advertising Router: 172.17.8.83

LS Seq Number: 80000075

Checksum: 0xCF4

Length: 84

Number of Links: 5

Link connected to: a Stub Network

(Link ID) Network/subnet number: 172.17.8.83

(Link Data) Network Mask: 255.255.255.255

Number of TOS metrics: 0

TOS 0 Metrics: 1

Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 172.17.8.84

(Link Data) Router Interface address: 10.40.31.1


TOS 0 Metrics: 48





TOS 0 Metrics: 48

Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 4.4.4.4

(Link Data) Router Interface address: 10.40.31.6


TOS 0 Metrics: 48





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.

Link count #1

Link count #2

Link count #3

Link count #4

Link count #5

Link type: There are 5 OSPF link types:

- Stub Link

- Broadcast Link

- Point-to-Point Link

- Virtual Link

- Loopback Link

All link type counts as one Link, except

Point-to-Point links counts as two

Links.

These two links are an

P2P interface

These two links are a

P2P interface.

These two links are an

P2P interface

These two links are a

P2P interface. In OSPF

the P2P interfaces

(such as PPP and

HDLC encapsulation)

will be account as 2

links: one to represent

the neighbour‟s ip

address and another for

sub-network and mask.

This is a loopback

interface.



57

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













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 ?

* i 172.17.0.7 144 100 0 ?

*>i10.33.31.8/30 172.17.0.7 0 100 0 ?

* i 172.17.0.6 144 100 0 ?

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

Total of VPNv4

prefixes received

by this neighbour.

From those 19

prefixes learnt

from this

neighbour

these are what

were imported

onto VRF

VPN.



58


*>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 ?

*>i10.33.31.8/30 172.17.0.6 144 100 0 ?

*>i172.17.8.51/32 172.17.0.6 49 100 0 ?

*>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, 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 ?

*> 172.17.8.84/32 10.40.31.6 97 32768 ?


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.

These are the

19 VPNv4

prefixes learnt

from the MP-

BGP

Total of VPNv4

prefixes advertised

to this neighbour.



59

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 ?


*>i10.33.31.4/30 172.17.0.6 0 100 0 ?

*>i10.33.31.8/30 172.17.0.6 144 100 0 ?

*>i172.17.8.51/32 172.17.0.6 49 100 0 ?

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

These are the

same 19 VPNv4

prefixes which

PE-4 learnt from

RR1 (see output

on previous

page).



60

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 ?

*>i172.17.8.84/32 172.17.0.4 97 100 0 ?


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

* i 172.17.0.5 100 100 0 i

*>i6.6.6.6/32 172.17.0.6 100 100 0 i

* i 172.17.0.6 100 100 0 i

*>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 ?

*>i10.33.31.0/24 172.17.0.7 0 100 0 1 i

* i 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.6 0 100 0 ?

* i 172.17.0.7 144 100 0 ?

* i 172.17.0.7 144 100 0 ?

Total of VPNv4

prefixes received from

this neighbour.

This prefix was learn via

RR1 and had a RD value 25135:133001806

This prefix was learn via

RR1 and had a RD value 25135:133001807

This prefix was

learn via RR2 and

had a RD value 25135:133001806

This prefix was

learn via RR2 and

had a RD value 25135:133001807



61

*>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 ?

* i172.17.8.84/32 172.17.0.5 49 100 0 ?

* i 172.17.0.5 49 100 0 ?

*> 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 ?

* 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 ?

*>i172.17.8.83/32 172.17.0.5 97 100 0 ?

* i 172.17.0.5 97 100 0 ?

*>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 ?

*>i10.33.31.4/30 172.17.0.6 0 100 0 ?

* i 172.17.0.6 0 100 0 ?

*>i10.33.31.8/30 172.17.0.6 144 100 0 ?

* i 172.17.0.6 144 100 0 ?

*>i172.17.8.51/32 172.17.0.6 49 100 0 ?

* 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

*>i 172.17.0.7 100 100 0 i

* i10.33.31.0/30 172.17.0.7 96 100 0 ?

*>i 172.17.0.7 96 100 0 ?

*>i10.33.31.0/24 172.17.0.7 0 100 0 1 i

* i 172.17.0.7 0 100 0 1 i

* i10.33.31.4/30 172.17.0.7 144 100 0 ?

*>i 172.17.0.7 144 100 0 ?

* i10.33.31.8/30 172.17.0.7 0 100 0 ?

*>i 172.17.0.7 0 100 0 ?

* 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 ?

This Prefixes are

from PE5‟s VPN

vrf. They were

exported with RT

25135:18 value.

This Prefixes are

from PE6‟s VPN

vrf. They were

exported with RT

25135:18 value.

This Prefixes are

from PE7‟s VPN

vrf. They were

exported with RT

25135:18 value.

Text blue are

prefixes

advertised by RR1

Text blue are

prefixes

advertised by RR1

Text blue are

prefixes

advertised by RR1

Text blue are

prefixes

advertised by RR1

Text blue are

prefixes

advertised by RR1

The blue text are

the prefixes

advertised by RR1

The green text are

the prefixes

advertised by RR2

The green text are

the prefixes

advertised by RR2

The green text are

the prefixes

advertised by RR2

The green text are

the prefixes

advertised by RR2

The green text are

the prefixes

advertised by RR2

The green text are

the prefixes

advertised by RR2



62

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




Flag: 0x800



172.17.0.6 (metric 30) from 172.17.0.8 (172.17.0.8)

Origin incomplete, metric 96, localpref 100, valid, internal, best






172.17.0.6 (metric 30) from 172.17.0.9 (172.17.0.9)







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)






Due to maximum-

path import

command we have

here two paths

imported for the

same VPNv4 prefix

25135:133001806

:10.33.31.0/30

Due to maximum-

path import

command we have

here two paths

imported for the

same VPNv4 prefix

25135:133001806

:10.33.31.0/30

RT value,

reason

why these

prefixes

were

imported

onto BGP

vrf VPN

table.

Finally, this appointed out what

is the path will be used on FIB

vrf table.

2nd

set of the

VPN prefixes

2nd

VPNv4

prefix. The blue

text was learnt

via router-

reflector 1

(172.17.0.8) and

the green text

was learnt via

router-reflector 2

(172.17.0.9)



63



Paths: (2 available, best #1, no table)

Flag: 0x800


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)






PE-4# sh ip route vrf VPN 10.33.31.0


Known via "bgp 25135", distance 200, metric 96, type internal

Redistributing via ospf 1

Advertised by ospf 1 metric 60 metric-type 1 subnets route-map vpn

Last update from 172.17.0.6 20:32:11 ago


* 172.17.0.6 (Default-IP-Routing-Table), from 172.17.0.8, 20:32:11 ago


AS Hops 0, BGP network version 0

This Prefixes are from PE6‟s

VPN vrf. They were exported

with RT 25135:18 value.

This Prefixes are from

PE7‟s VPN vrf. They

were exported with RT

25135:18 value.

BGP next-hop

(remote PE)

BGP neighbour which

adversited this prefix (RR1).



64

MPLS/TE and FRR

Identify the destination

Step 1. From a source PE identify the remote PE






Last update from 172.17.0.7 1d23h ago


* 172.17.0.7 (Default-IP-Routing-Table), from 172.17.0.8, 1d23h ago



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




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

Step 2. Checking the label stack in Data plane Database

PE-4# sh ip cef vrf VPN 172.17.8.52


0 packets, 0 bytes








Label in the Top of “Label

Stack” - MPLS/TE label

Leart via RSVP

Label in the Bottom of

“Label Stack” -

MPLS/VPN laabel

Leart via MP-BGP



65

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


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

Tun Sender: 172.17.0.4 LSP ID: 6053

Next Hop: 172.19.24.1 on Serial0/0

Label: 58 (outgoing)

. . .

[output omitted]





Flag: 0x800



172.17.0.7 (metric 670) from 172.17.0.8 (172.17.0.8)







172.17.0.7 (metric 670) from 172.17.0.9 (172.17.0.9)






. . .

[output omitted]

In MP-BGP database, you

have to look for what the

preferential path is. It will

be always identify with the

keyword “best”

RSVP Label, learnt via

RSVP neighbor

MPLS/VPN Label, learnt

via remote PE flooded via

MP-BGP neighbour (route-

reflector)

RSVP Label, learnt via

RSVP neighbor



66

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.



67

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



68

Step 4. Checking if “MPLS traffic-eng” and “MPLS Traffic-eng auto-tunnel” are 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.

Step 5. Checking if “MPLS traffic-eng” and “MPLS Traffic-eng auto-tunnel” are 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.



69

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*



70

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

Physical BW: 2048 kbits/sec

Reservable Global Pool BW: 155000 kbits/sec

Global Pool BW Unreserved:

[0]: 155000 kbits/sec, [1]: 155000 kbits/sec




Metric: 640 IS-Extended PE-5.00

Affinity: 0x00000000

Interface IP Address: 172.19.45.1




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 Sub Pool BW: 0 kbits/sec

Global Pool BW unreserved:

These figures show the amount

of Bandwidth available after

reservation for this priority and

lower.

Because of “tunnel mpls

traffic-eng auto-bw collect-

bw” command applied under

interface tunnel configuration,

Instead of reserving the

maximum bandwidth

(100Kbits) it is reserved the

amount of the traffic rate being

utilised per interface tunnel.

PS.: high number means low priority.



71





Sub Pool BW unreserved:





Affinity Bits: 0x00000000

Link[2]

Neighbor System ID: PE-5.00 (P2P link)






. . .

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






Reservable Sub Pool BW: 0 kbits/sec

Global Pool BW unreserved:





Sub Pool BW unreserved:





Affinity Bits: 0x00000000

. . .

[output omitted]




lower.

Because of “tunnel mpls


bw” command applied under

interface tunnel configuration,

Instead of reserving the

maximum bandwidth

(100Kbits) it is reserved the

amount of the traffic rate being

utilised per interface tunnel.





lower.

Results without “tunnel mpls


bw” command



72

Step 6. Checking RSVP status

PE-4# sh ip rsvp int

interface rsvp allocated i/f max flow max sub max

Se0/0 ena 300K 155M 155M 0

Se1/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

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.

PE-4# sh ip rsvp installed

RSVP: Serial0/0

BPS To From Protoc DPort Sport

0 172.17.0.2 172.17.0.5 0 60003 1

1K 172.17.0.5 172.17.0.4 0 1 478

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


PE-4# sh ip rsvp installed

RSVP: Serial0/0


0 172.17.0.2 172.17.0.6 0 60001 7514

0 172.17.0.3 172.17.0.6 0 60000 7514

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.

This value (bandwidth to be

considered in resource

reservation – “ip rsvp

bandwidth” interface

command) should be always

higher than the bandwidth

configured on interface tunnel

otherwise the reservation will

fail for this physical interface.

Here we can identify which

tunnels are using the

physical resource.

Case when “tunnel mpls

traffic-eng auto-bw

collect-bw” tunnel

interface command is NOT

applied.

Here we can identify which

tunnels are using the

physical resource.

Figures due to tunnel mpls

traffic-eng auto-bw

collect-bw tunnel interface

command is applied.



73

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)



74


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.



75

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.



76

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.



77

PE-4# sh mpl traffic-eng tunnels tunnel 1

Name: PE-4_t1 (Tunnel1) Destination: 172.17.0.5

Status:

Admin: up Oper: up Path: valid Signalling: connected

path option 1, type dynamic (Basis for Setup, path weight 1040)

Config Parameters:

Bandwidth: 100 kbps (Global) Priority: 4 4 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 100 bw-based

auto-bw: (86400/82153) 2 Bandwidth Requested: 100

Active Path Option Parameters:

State: dynamic path option 1 is active

BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -

OutLabel : Serial0/0, 51

FRR OutLabel : Tunnel60002, 59

RSVP Signalling Info:

Src 172.17.0.4, Dst 172.17.0.5, Tun_Id 1, Tun_Instance 9719

RSVP Path Info:

My Address: 172.17.0.4

Explicit Route: 172.19.24.1 172.19.12.1 172.19.30.2 172.16.130.2

172.19.53.10 172.17.0.5

Record Route: NONE

Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

RSVP Resv Info:

Record Route: 172.17.0.2(51) 172.17.0.1(59)

172.17.0.30(55) 172.17.0.31(43)

172.17.0.5(0)

Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

Shortest Unconstrained Path Info:

Path Weight: 640 (TE)

Explicit Route: 172.19.45.2 172.17.0.5

History:

Tunnel:

Time since created: 1 hours, 9 minutes

Time since path change: 1 hours, 9 minutes

Number of LSP IDs (Tun_Instances) used: 2

Current LSP:

Uptime: 1 hours, 9 minutes

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

First check: Check if this is the destination

you want to analyse.

Second check: Check the

status (up up).

Third check: Check if the path is valid.

Fourth check: Check if this is expected path (confirm

checking the topology).

Last check: Check outLabel to track the LSP (also the

FRR information such as Interface number

and label.

Fifth check: LSP labels end-to-end.

Additional check: Check how long this tunnel is

operational and the last path

changed.



78

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

bw[1]: 0 155000 0

bw[2]: 0 155000 0

bw[3]: 0 155000 0

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)





Bandwidth available after


lower.




79

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)











80

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




81

PE-4# sh mpl traffic-eng link-management bandwidth-allocation serial 1/0

System Information::

Links Count: 2

Bandwidth Hold Time: max. 15 seconds

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

Outbound Admission: allow-if-room

Admin. Weight: 640 (IGP)

IGP Neighbor Count: 1

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


PE-4# sh mpl traffic-eng link-management admission-control


Tunnels Count: 36

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



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.

It displays how many interfaces

are enabled on RSVP.

It shows the threshold when a

new LSP will be generated and

flooded to whole backbone

area.

“G” means global pool.

“R” means bandwidth is

reserved.

“H” means bandwidth is

temporarily being held

for a path message.

Tunnel id: <Head-

end IP address> +

<tunnel #>_<id>.

Upstream interface

Downstream interface

Total of the

tunnels this router

is aware of.

T



82

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


Res. Global BW: 155000 kbits/sec

Res. Sub BW: 0 kbits/sec

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


These figures should match with

“show mpls traffic-eng topology

igp-id isis <system-id>.00

command output.



83

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



84

Step 8. FAST REROUTE CHECKING

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.

N-Nhop means Link

protection.

If the state is “active” means

the primary tunnel is down and

the backup is being used.



85

PE-4# sh mpl traffic-eng tunnels tunnel 60002


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


InLabel : -




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


RSVP Resv Info:

Record Route: NONE




Explicit Route: 172.19.24.1 172.19.23.2 172.17.0.3

History:

Tunnel:


Time since path change: 3 hours, 1 minutes


Current LSP:

Uptime: 3 hours, 1 minutes

It shows the information of backup tunnel interface.

This is the Tail end of Backup tunnel.

In this case it is P3.

This is a node protection.

In this case the node protected is P2.

Path of Backup

Tunnel in case of

failures (failure link

between PE4 or node

failure, P2 node)

Path when there is

NO failure.



86

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



87

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




88

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



89

Tracing a LSP end to end

Firstly we will check will is the path taken from CE-1 to reach CE-4.

CE-1# trace 172.17.8.52

Type escape sequence to abort.

Tracing the route to 172.17.8.52

1 10.40.31.5 20 msec 20 msec 24 msec

2 172.19.24.1 28 msec 36 msec 12 msec

3 172.19.31.2 28 msec 20 msec 32 msec

4 172.19.131.2 20 msec 20 msec 20 msec

5 10.33.31.9 20 msec 20 msec 20 msec

6 10.33.31.10 20 msec * 20 msec

This path is: CE-1 PE4 P2 P31 P32 PE7 CE-4

Let‟s check this from PE4.

PE-4# trace vrf VPN 10.33.31.10



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

PE-4# sh ip cef vrf VPN 10.33.31.8


0 packets, 0 bytes








Let‟s check the VPN label. The subnetwork of 10.33.31.10 is 10.33.31.8/30.

VPN label (learn

via MP-BGP

LDP or RSVP label for

LSP tunnel from PE4- to

PE7.

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7 CE4

CE1

43 49 IP

40 49 IP

37 49 IP 49 IP IP

IP

VPN label (learn

via MP-BGP

LDP or RSVP label for

LSP tunnel from PE4- to

PE7.



90

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.



91

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





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)

172.17.0.32(37) 172.19.137.1(37)

172.17.0.7(0) 172.19.137.2(0)

[output ommitted]

You can also get the RSVP label from the following command:

This is the RSVP

label.

With this command you

can also get the LSP

tunnel from PE-4 to PE-

7. This set of label

should match with the

output shown in

traceroute 2 page before.



92

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

Let‟s to the same for the next hop, which is P31 (172.19.31.2).


31 16 172.17.0.4/32 336408 Se2/0 point2point

40 37 172.17.0.4 3 [5407] 486261 Se1/0 point2point

Label for incoming

labelled packet

This is the outgoing

label for this LSP.

Which should match

with the output in the

trace command.

Outgoing

label.

Incoming

label.



93

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.

Because P32 is the

PHP, we will have

here a pop tag

(explicit-null).



94

Part 5: Failure Scenarios

TM



95

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)




96

Checking in the diagram if this route is the expect path: PE4 P2 P3 PE6 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




Outbound: FRR Ready









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

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Head End

Tail End

Middle Point Middle Point Middle Points

This is a node protection

(NNHOP).

The node protected here is P2

(as the next hop is P3).

Look in the previous output to

understand why P2 is the node

protected.



97

Verify the Path used for this backup tunnel: PE4 PE5 P31 P32 PE7 PE6.

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





PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Node Protected

for this tunnel

PE-4 – T60002 Next-Next -Hop



98







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.



99

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




100

Checking in the diagram in this route the expect path: PE4 P2 P3 P32 PE7.

PE-4# sh mpl traffic-eng tunnels tu3 protect

PE-4_t3




Outbound: FRR Ready









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.

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Head End

Tail End Middle Point Middle Points Middle Points

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Node Protected

for this tunnel

PE-4 – T60002

Next-Next -Hop

This tunnel is a

Node protection.



101

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.

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Next-Hop Link Protected



102

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:












Explicit Route: 172.19.24.1 172.19.23.2 172.16.36.2 172.17.0.6

History:

Tunnel:


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

Status changed

after reducing

bandwidth

availablility in

the path.

Before, P2 was

allocating

bandwidth for

two tunnels:

PE4-PE7 and

PE4-PE7.

Now P2 has

capacity only for

one tunnel. So,

one of the

tunnels went

down.



103

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:












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.

It is trying to

find a path of

this tunnel.



104

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

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7



105

Let‟s check the RSVP status in P2 and P31.

P2# sh ip rsvp int


Se0/0 ena 0 0 0 0

Se1/0 ena 100K 100K 100K 0

Se2/0 ena 100K 100K 100K 0

Se3/0 ena 300K 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 ip rsvp installed

RSVP: Serial0/0 has no installed reservations

RSVP: Serial1/0


0 172.17.0.3 172.17.0.1 0 60000 1

0 172.17.0.3 172.17.0.31 0 60005 1

100K 172.17.0.6 172.17.0.4 0 2 8822

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


Se0/0 ena 300K 155M 155M 0

Se1/0 ena 0 0 0 0

Se2/0 ena 200K 155M 155M 0

Se3/0 ena 200K 155M 155M 0


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

S0/0 connects to P1

which does not have

RSVP enabled.

S1/0 connects to P3 and

has 100k bandwidth

allocated.

S2/0 connects to P31 and

has 100k bandwidth

allocated.

S0/0 does NOT have

bandwidth for RSVP

reservation.

S1/0 and S2/0 have full

filled all bandwidth

capacity for RSVP.

So, there is not a

bandwidth capacity

available for RSVP

reservation when

tunnel 3 has requested.

RSVP is not enabled in

S1/0 interface which

connects to P32.

Then, S0/0 interface

which connects to P30

is the best option.



106

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

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

P1



107

ISIS disabled for TE

PE-4# sh mpl tra tu tu3


Status:



Config Parameters:








InLabel : -




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:




Current LSP:

Uptime: 57 seconds


Prior LSP:


Removal Trigger: re-route path verification failed

Again, the Tunnel 3 is

not using the best path

we would expect.

Look at this time, the

unconstrained Path

Info does NOT show

the path we would

expect either. This

could be a sign at least

one of the routers in

the BEST path has not

ISIS enabled for TE.



108

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.

P2# sh mpl traffic-eng tunnels summary

Signalling Summary:

LSP Tunnels Process: not running, disabled

RSVP Process: running

Forwarding: enabled

Head: 7 interfaces, 0 active signalling attempts, 0 established

22 activations, 22 deactivations

Midpoints: 0, Tails: 0

auto-tunnel:

backup Enabled (7 ), id-range:60000-64000

onehop Disabled (0 ), id-range:65336-65435

mesh Enabled (0 ), id-range:1-999


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

This message indicates

that mpls traffic-eng

global command is not

enabled in this router.



109

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:

Interfaces:


LDP Id: 172.17.0.2:0

Serial1/0 (ldp): xmit

No LDP received on

Serial 1/0 interface



110

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



111

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

ip vrf VPN

ip vrf rrr


ip vrf forwarding VPN


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

Neither route-target import

nor import-map

Because there is at least a vrf importing

212.182.144.1:18 route-target, we can see these

prefixes on “global bgp database” otherwise the

BGP process will drop these prefixes.



112

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















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

*> 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 ?

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 ?


Local prefixes only:

learnt via local CE or

genered via local BGP

process (next-hop =

0.0.0.0)

It did not accept any

VPNv4 prefixes.

Reasons:

There isn‟t vrf import

prefixes which RT

value advertised by

these neighbours.

Or there is a inbound

filter denying all

prefixes, such as route-

map, prefix-list

assigned to these

neighbours.

Or RR is not

adversiting prefixes to

PE-4.



113

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













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















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

Only 172.17.0.9 is

configured as route-

reflector-client.

However this

neighbour is not

adversiting any

prefixes to RR1.

All other neighbours

now are normal

iBGP.

No prefixes

received/learnt/accept.



114

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:

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



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











Status as soon as PE7 reloads.











Loopback 0 of CE-4

Link between PE7 and CE-4

and CE-4

BGP next-hop:

PE-7

and CE-4

BGP next-hop:

PE-6



115

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:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

. . . [ output omitted ] Success rate is 99 percent (9998/10000), round-trip min/avg/max = 8/22/440 ms

Two packets were lost. However in real lab scenario there is not packet loss.

CE-1# sh ip route 172.17.8.52


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.

Tunnel which destines to

PE7 is down.



116

RR Node Failure

This case of failure will not affect TE as the Destination tunnel IP addresses are learnt via ISIS.

Status before RR failure: PE-4# sh ip route vrf VPN 172.17.8.52










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

Status as soon as RR failure:

PE-4# traceroute vrf VPN 172.17.8.52






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











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

RR1

RR2

Path did not

change after RR

failure

Path did not

change after RR

failure



117

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

Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%

Time source is NTP, 11:53:53.019 GMT Fri Mar 2 2007

Name: PE4-PEXKS01_t2 (Tunnel2) Destination: 172.17.0.7

Status:



Config Parameters:








InLabel : -

OutLabel : GigabitEthernet3/2, 82




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)

172.17.0.3(112) 172.19.32.1(112)

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:




Current LSP:


Prior LSP:


Removal Trigger: path option updated

Path: PE4 P2P3P32PE7

Tunnel

Operational

and Path

Valid

Check these labels with

trace mpls traffic-eng

command.



118

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



PE4-PEXKS01_t2




Outbound: FRR Ready


Tu60006: out i/f: Gi3/3, label: 249


Original: out i/f: Gi3/2, label: 82, nhop: 172.19.24.1





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.

Tail-end for this

backup tunnel (2

hops way from

PE4)



119

PE4-PEXKS01# sh mpl traf tu tu 60006




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.

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Node Protected

for this tunnel

PE-4 – T60006

Next-Next -Hop



120

Link failure between P2 and PE4:

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


path option 1 reoptimization in progress

Config Parameters:








InLabel : -


FRR OutLabel : Tunnel60006, 112 (in use)



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:

Record Route: 172.17.0.2(82) 172.19.23.1(82)

172.17.0.3(112) 172.19.32.1(112)

172.17.0.32(112) 172.19.137.2(112)

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:

Uptime: 1 seconds

Prior LSP:



2nd checking:

Status did NOT

change!

1st checking: Backup

tunnel in used. Check

the trace mpls

command output in the

next path.

3rd

checking: Check the

primary tunnel path did NOT

change even though the link

PE4 P2 is down.

When the backup tunnel is in

used we can NOT check the

full path in only one show

command.

4th

checking: In back ground it is

being calculated the new path for

primary tunnel. This occurs due

to the dynamic path configuration

and reoptimaztion path being

enabled.

4th

checking: In back ground it is

being calculated the new path for

primary tunnel. This occurs due

to the dynamic path configuration

and reoptimaztion path being

enabled.



121








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




! 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?

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.

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Next-Next -Hop

These 4 “112” value are the

same. It is in the bottom of the

label stack. It is being

encapsulated into backup

tunnel.

P3 node

The backup

tunnel label is

the top of label

stack.



122





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(25) 172.19.53.9(25)

172.17.0.31(81) 172.16.131.1(81)

172.17.0.32(86) 172.19.137.2(86)

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:



Prior LSP:


Removal Trigger: re-route path error

Tunnel NEVER

went down.

New path

New LSP labels

– Check with

previous

command (trace

mpls traffic-

eng).

PE4 P2 P3 PE6

P1

PE5 P31

P30

P32 PE7

Tunnel NEVER

went down.

These figures

can prove only

the path has

changed.



123

Link failure between P2 and P3





Status:






0x0/0xFFFF



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

No information this

backup tunnel being in

used.

In back ground it is being

calculated the new path for

primary tunnel.

In back ground it is being

calculated the new path for

primary tunnel.



124








0 172.19.24.2 MRU 4470 [Labels: 124 Exp: 0]

R 1 172.19.24.1 MRU 4466 [Labels: 84/96 Exp: 0/0] 4 ms

U 2 172.19.31.2 MRU 4474 [Labels: 96 Exp: 0] 1 ms


! 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?

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

The backup tunnel label

is the top of label stack.

P31 is PHP, so it is being

removed the backup

label of label stack.

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

Node protected. P1

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

P1



125





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)

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:



New Path information New Path information



126


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:








0 172.19.24.2 MRU 4470 [Labels: 141 Exp: 0]



U 3 172.16.36.2 MRU 4474 [implicit-null] 3 ms

! 4 172.16.67.2 4 ms

After reoptimisation:








0 172.19.24.2 MRU 4470 [Labels: 100 Exp: 0]




! 4 172.19.137.1 4 ms

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

P1

Because P32 is the last

node to reach PE7 for the

primary tunnel, we do

NOT see two labels in

label stack.

New Path PE4 P2 P31 P32 PE7



127

PE4-PEXKS01# sh mpl tra tu tu2




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

LSP labels before link

failure. The same result

as the first trace mpls

traffic-eng output in the

previous page.



128

Output during new path calculation, meanwhile the backup tunnel is be used:





Status:









As soon as the new path was defined: PE4-PEXKS01# sh mpl tra tu tu2




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

Record Route:


RSVP Resv Info:

Record Route: 172.17.0.2(100) 172.19.31.1(100)

172.17.0.31(97) 172.16.131.1(97)

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.31.2 172.16.131.2 172.19.137.1

172.17.0.7

History:

Tunnel:




Current LSP:

Uptime: 4 seconds


LSP labels new path

calculation due to link

failure. The same result

as the third trace mpls

traffic-eng output in two

page before.



129


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]





U 5 172.16.36.2 MRU 4474 [implicit-null] 3 ms

! 6 172.16.67.2 4 ms

Link P32 P3 twice.

Because P32 is PHP for

the primary tunnel, we

do NOT see two labels in

label stack.

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

P1



130

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:





131

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



132





Status:






0x0/0xFFFF



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



Even though it is running the path calculation the backup

tunnel is NOT in used. The data traffic is still using the

path via P2 as the line card did NOT go down yet. We can

NOT identify this behaviour using trace mpls command.

Even though in Data Plane the path can still

be used; Control Plane received a signal to

recalculate a new path. In the next pages there

are some debug commands to identify this

signal (ISIS flag; there is not RSVP flag for

this pariticula case.



133

After path calculation:








0 172.19.45.1 MRU 4470 [Labels: 26 Exp: 0]




! 4 172.19.137.1 2 ms

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

PE4 P2 P3 PE6

PE5 P31

P30

P32 PE7

P1



134

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]



135


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



136

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)



RSVP Path Info:


Explicit Route: 172.17.0.3 172.19.32.2 172.19.137.1 172.17.0.7

Record Route:


Backup tunnel in used.



137

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



138





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:





139

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



140

Figure 12 - Lab topology for LINK and NODE failures scenarios

0/2

0/2

3/2

3/0/2

3/2

3/0/2

3/0/3

3/3

3/2

3/0/0

2/0/

1

2/0/0

172.19.24.0/30

17

2.1

9.4

5.0

/30

172.19.53.8/30

172.19.23.0/30

172.19.131.0/30

172.

19.1

2.0/

30

172.16.36.0/30

172.19.137.0/30

172.1

6.6

7.0

/30

172.16.18.0/30

0/1

3/0 3/0

3/0

/0

3/0

/0

3/0

/3

10.5

9.9

5.8

2/3

0 G

n

3/3

3/3

3/3

3/0/0

3/0

/8

3/0

/9

1/15/8

5/8 1/1

1/2

2/2

2/21/1

1/1

1/2

2/2

1/22/2

5/13 5/14

2/0/2

4/0/1

3/2

3/2

3/03/1

2/0/4 2/0/4

2/1

/1

172.1

9.3

2.0

/30

172.1

9.3

1.0

/30

172.1

9.3

0.0

/30

172.16.132.0/30

.9 .10

172.19.13.0/302/0/3

0/2

0/20/1

3/0

.98 1

0.4

0.3

1.51

0.4

0.3

1.6

vla

n9

8

3/0

.98 1

0.3

3.3

1.5

10

.33

.31.6

vla

n9

8

10.40.31.10 vlan99

3/0/0.99 10.40.31.9

10.33.31.10 vlan99

3/0/0.99 10.33.31.9

POS STM1GE

POS STM16POS CHOC48

10GE

FE

3/1

3/0

/4Q

OS

test

targ

ets

AX4000packet generator

(to ports under test)5

3 1

stm

1/4

GE

FE

3/2

0

1/6

3/1

stm1/4

GE

FE

1/6

3/1

3/20

6

42

3/3

CHOC3-E1

STM1 or STM4

E1

3/0

PE4

172.17.0.4

PE5

172.17.0.5

6509-2

172.17.7.84

6509-1

172.17.7.83

RR1

172.17.0.86509-3

172.17.8.51

1/2

PE6

172.17.0.6

PE7

172.17.0.7

6509-4

172.17.8.52

P32

172.17.0.32

P31

172.17.0.31

P1

172.17.0.1

2/0/

1 2/0/3

P2

172.17.0.2

P3

172.17.0.3

P30

172.17.0.30

172.

16.1

30.0

/30

RR2

172.17.0.9

0/1172.19.29.8./30



141

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



142

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

Part 6: Appendix

TM



144

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>



145

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>



146

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



147

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-




148







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#





149


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



150

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



151



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:





152



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#





153

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



154

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



155

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



156

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.



157

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

ttcp-t: 0 sleeps (0 ms total) (0 ms average)

Connection state is ESTAB, I/O status: 1, unread input bytes: 0

Local host: 10.33.33.75, Local port: 32483

Foreign host: 10.40.31.2, Foreign port: 5001

Enqueued packets for retransmit: 4, input: 0 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

Total of time for

transmission. Sender

respective.



158

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

ttcp-r: 0 sleeps (0 ms total) (0 ms average)

Connection state is CLOSEWAIT, I/O status: 7, unread input bytes: 0

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

Total of time for

transmission.

Receiver respective.



159

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.

root@server01 # cat 172.17.0.5.mimic | more

.1.3.6.1.2.1.31.1.1.1.1.1: Et0

.1.3.6.1.2.1.31.1.1.1.1.2: PO0/0

.1.3.6.1.2.1.31.1.1.1.1.3: PO0/1

.1.3.6.1.2.1.31.1.1.1.1.4: PO0/2

.1.3.6.1.2.1.31.1.1.1.1.5: PO0/3

.1.3.6.1.2.1.31.1.1.1.1.6: AT1/0

.1.3.6.1.2.1.31.1.1.1.1.7: AT1/1

.1.3.6.1.2.1.31.1.1.1.1.8: AT1/2

.1.3.6.1.2.1.31.1.1.1.1.9: AT1/3

.1.3.6.1.2.1.31.1.1.1.1.10: AT1/4

.1.3.6.1.2.1.31.1.1.1.1.11: AT1/5

.1.3.6.1.2.1.31.1.1.1.1.12: AT1/6

<snip>

This is the

ifHCInOctest

This is the ifName

Note that each interface

has its own ifName

Interface of

index 3.

Value of the query

In this case it is ifName value

for interface index 9. In this

case it is the ATM 1/3



160

.1.3.6.1.2.1.31.1.1.1.6.1: 186302666

.1.3.6.1.2.1.31.1.1.1.6.2: 0

.1.3.6.1.2.1.31.1.1.1.6.3: 0

.1.3.6.1.2.1.31.1.1.1.6.4: 0

.1.3.6.1.2.1.31.1.1.1.6.5: 0

.1.3.6.1.2.1.31.1.1.1.6.6: 0

.1.3.6.1.2.1.31.1.1.1.6.7: 0

.1.3.6.1.2.1.31.1.1.1.6.8: 0

.1.3.6.1.2.1.31.1.1.1.6.9: 0

.1.3.6.1.2.1.31.1.1.1.6.10: 0

.1.3.6.1.2.1.31.1.1.1.6.11: 19342489088

.1.3.6.1.2.1.31.1.1.1.6.12: 0

.1.3.6.1.2.1.31.1.1.1.6.13: 0

.1.3.6.1.2.1.31.1.1.1.6.14: 6611579242127

.1.3.6.1.2.1.31.1.1.1.6.15: 4771349347637

.1.3.6.1.2.1.31.1.1.1.6.16: 1236953229021

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

Interface of

index 1.

Interface of

index 14.

Value of the query

In this case it is

ifHCInOctest value for

interface index 16.

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en



161

.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

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



162

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

!



163

key chain ISIS

key 1

key-string 7 1043101D0A10

!

interface Loopback0

ip address 172.17.0.4 255.255.255.255


!

interface Loopback1


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







164

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



165

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



166

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



167


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




168



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



169

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



170

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



171

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 /

Forwarding Plane

Where the actual forwarding occurs. This can only exist after the control plane has been

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



172

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.

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm



173

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

BGP Multipath Load Sharing in an MPLS-VPN

http://www.cisco.com/en/US/partner/products/ps6017/products_feature_guide09186a00804181b4.html

Configuring a MPLS TE using IS-IS

http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_configuration_example09186a0080093fcb.shtml











174

RSVP Extension for MPLS/TE Signalling - RFC3473

http://rfc.net/rfc3473.html

RSVP Extension for MPLS/TE Signalling - RFC4208


FRR - Fast ReRoute - Link and Node Protection

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/products_feature_guide09186a0080264560.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_guide09186a0080265adc.html

MPLS Traffic-eng configuration guide

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017cf43.html

http://www.cisco.com/en/US/products/ps6922/products_command_reference_chapter09186a00806c0fd1.html#wp1021058















175

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

Documents

Transcript of MPLS - Troubleshooting Guide