1974_chp4ONLa.

fm Page 657 Tuesday, November 14, 2006 9:51 AM

1974_chp4ONLa.fm Page 658 Tuesday, November 14, 2006 9:51 AM

SUPPLEMENT
CHAPTER 4
Label Distribution Protocol

LDP Graceful Restart specifies a mechanism for Label Distribution Protocol (LDP) peers to
preserve the MPLS forwarding state on the label switching routers (LSRs) when the LDP
session goes down. When the LDP session goes down, the LDP Graceful Restart enables the
nonstop forwarding of labeled traffic for the LSPs through the LSRs by using the previously
learned labels by LDP. The nonstop forwarding of labeled traffic through the affected LDP peers
can continue until the LDP session is reestablished or the LDP neighbors are declared down.

LDP Graceful Restart

The LDP Graceful Restart mechanism is described in RFC 3478.

It is important to note that MPLS LDP Graceful Restart can operate in two modes:

■ MPLS LDP Graceful Restart in SSO/NSF mode

■ MPLS LDP Graceful Restart in Helper mode

SSO/NSF mode stands for Stateful Switchover/NonStop Forwarding mode. SSO refers to the
capability of transparent failover of Layer 2 protocols when a route processor fails. NSF refers
to the capability to keep forwarding traffic when the active route processor fails and the standby
route processor takes over. While the IGP adjacencies are rebuilt, the forwarding information
base/label forwarding information base (FIB/LFIB) remains in place, and the forwarding of
traffic is not interrupted. Both SSO and NSF are part of the Cisco High Availability initiative.
An LSR that is running MPLS LDP Graceful Restart in SSO/NSF mode is capable of
forwarding the labeled traffic in the data plane while LDP is restarting in the control plane. An
LSR that is running LDP Graceful Restart in Helper mode is not capable of forwarding labeled
traffic while LDP restarts, but it helps the neighboring LDP router in its LDP Graceful Restart.

When the LDP Graceful Restart feature is enabled on the LSR, a Fault Tolerant (FT) Session
TLV is sent as an optional parameter in the LDP Initialization message.
1974_chp4ONLa.fm Page 659 Tuesday, November 14, 2006 9:51 AM

659 Chapter 4: Label Distribution Protocol

NOTE RFC 3479, “Fault Tolerance for the Label Distribution Protocol (LDP),” defines the
FT Session TLV.

Figure 4-1 shows the encoding of the FT Session TLV.

Figure 4-1 FT Session TLV Encoding

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

1 0 FT Session TLV (0 0503) Length (=12)

FT Flags Reserved

FT Reconnect Timeout (In Milliseconds)

Recovery Time (In Milliseconds)

The FT Flags field is defined in Figure 4-2.

Figure 4-2 FT Flags Field Encoding

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

R Reserved S A C L

The flags are as follows:

■ R: FT Reconnect flag

■ S: Save State flag

■ A: All-Label Protection Required

■ C: Check-Pointing flag

■ L: Learn from Network flag

1974_chp4ONLa.fm Page 660 Tuesday, November 14, 2006 9:51 AM

LDP Graceful Restart 660

All other bits in this field are currently reserved and should be set to zero on transmission and
ignored upon receipt. All flags—except the L-flag—have no meaning to MPLS LDP Graceful
Restart, so they are not explained here. The L flag is the Learn from Network flag. It is set to 1 if
the Fault Recovery procedures of RFC 3478 are to be used to relearn the state from the network.

The two parameters in the FT Session TLV that are important for Graceful Restart are FT
Reconnect Timeout and Recovery Time. The FT Reconnect Timeout is the time that the sender of
this parameter would like the receiver to wait before giving up on this LDP neighborship
completely. The Recovery Time is the time that the LDP peer is willing to keep the MPLS
forwarding state while the LDP neighborship is restarting. When the LDP session is in restart, the
label bindings are preserved but are in a stale state. When the LDP session recovers, the stale
bindings are recovered or new bindings are learned.

Figure 4-3 shows the LDP Graceful Restart procedure between two LDP peers.

Figure 4-3 LDP Graceful Restart Procedure

LDP Session Breaks

LDP Session Lost LDP Session Lost

LDP Hellos
Reconnect Timer Reconnect Timer
Started Started

Active/Passive Negotiation

TCP Connection Established Reconnect

Timer
Reconnect
Timer
FT Se
ssion
TLV, L
earn F
lag Se Reconnect Timer
t
Stopped
Learn F lag Set Recovery Timer
Reconnect Timer ion TLV,
Stopped FT Sess Started
Recovery Timer
Started
Recovery
Address Messages Timer
Recovery
Timer
Label Mapping Messages
Recovery Timer Recovery Timer
Stopped Stopped
1974_chp4ONLa.fm Page 661 Tuesday, November 14, 2006 9:51 AM

661 Chapter 4: Label Distribution Protocol

In Cisco IOS, the command to enable LDP Graceful Restart is mpls ldp graceful-restart. In
addition, three timers can be set for LDP Graceful Restart:

mpls ldp graceful-restart timers forwarding-holding secs

This command specifies the amount of time that the MPLS forwarding state should
be preserved after the control plane restarts. In other words, it is the amount of time
that the entries in the LFIB (marked as “stale” in the LIB) that are pointing to an LDP
peer of which the LDP session is restarting should remain. The value specified can
be between 30 and 600 seconds; the default is 600 seconds.
mpls ldp graceful-restart timers max-recovery secs

This command specifies the amount of time that the stale label bindings should be
kept on the router after the LDP session has been reestablished. The value specified
can be between 15 and 600 seconds; the default value is 120 seconds.
mpls ldp graceful-restart timers neighbor-liveness secs

This command specifies the amount of time that the router will wait for the LDP
session to be re-established. The actual time the router will wait for the re-
established LDP session is the minimum value of the configured neighbor-liveness
and the received value of the FT Reconnect Timeout in the FT Session TLV. The
configured neighbor-liveness is a value between 5 and 300 seconds; the default value
is 120 seconds. If the router cannot re-establish the LDP session within that time, the
router deletes all the stale LDP bindings received from that LDP neighbor.
Example 4-1 shows that LDP label bindings can be marked as stale when LDP Graceful Restart
is enabled on the LSR. All label bindings from 10.200.254.5 (router madrid) are marked as stale.

Example 4-1 Stale Label Bindings

sydney#show mpls ldp bindings detail
lib entry: 0.0.0.0/0, rev 40, chkpt: none
remote binding: lsr: 10.200.254.5:0, label: imp-null stale
lib entry: 10.10.100.33/32, rev 38, chkpt: none
remote binding: lsr: 10.200.254.6:0, label: imp-null
lib entry: 10.48.70.0/24, rev 39, chkpt: none
remote binding: lsr: 10.200.254.5:0, label: imp-null stale
lib entry: 10.200.211.0/24, rev 14, chkpt: none
local binding: label: 18 (owner LDP)
Advertised to:
10.200.254.3:0 10.200.254.6:0
remote binding: lsr: 10.200.254.3:0, label: imp-null
remote binding: lsr: 10.200.254.6:0, label: 17
remote binding: lsr: 10.200.254.5:0, label: 17 stale
1974_chp4ONLa.fm Page 662 Tuesday, November 14, 2006 9:51 AM

LDP Graceful Restart 662

Example 4-2 shows the Graceful Restart debug information when an LDP neighbor goes down
and recovers.

Example 4-2 Example of LDP Graceful Restart: LDP Neighbor Going Down and Recovering
sydney#debug mpls ldp graceful-restart
LDP Graceful Restart events debugging is on
sydney#
LDP GR: GR session 10.200.254.5:0:: lost
LDP GR: down nbr 10.200.254.5:0:: created [1 total]
%LDP-5-GR: GR session 10.200.254.5:0 (inst. 3): interrupted--recovery pending
LDP GR: GR session 10.200.254.5:0:: bindings retained
LDP GR: down nbr 10.200.254.5:0:: state change (None -> Reconnect-Wait)
LDP GR: down nbr 10.200.254.5:0:: reconnect timer started [120000 msecs]
LDP GR: down nbr 10.200.254.5:0:: added to bindings task queue [1 entries]
%LDP-5-NBRCHG: LDP Neighbor 10.200.254.5:0 is DOWN
LDP GR: Tagcon querying for up to 12 bindings update tasks [table 0]
LDP GR: down nbr 10.200.254.5:0:: requesting bindings MARK for {10.200.254.5:0, 3}
LDP GR: down nbr 10.200.254.5:0:: removed from bindings task queue [0 entries]
LDP GR: Requesting 1 bindings update tasks [0 left in queue]
sydney#

sydney#show mpls ldp graceful-restart

LDP Graceful Restart is enabled
Neighbor Liveness Timer: 120 seconds
Max Recovery Time: 120 seconds
Forwarding State Holding Time: 600 seconds
Down Neighbor Database (1 records):
VRF default:
Peer LDP Ident: 10.200.254.5:0 [inst 3], Local LDP Ident: 10.200.254.4:0
Status: waiting for reconnection (89 seconds left)
Address list contains 3 addresses:
10.200.215.2 10.200.254.5 10.200.216.1
Graceful Restart-enabled Sessions:

sydney#
LDP GR: Received FT Sess TLV from 10.200.254.5:0 (fl 0x1, rs 0x0, rconn 120000, rcov 120000)
LDP GR: searching for down nbr record (10.200.254.5:0, 10.200.216.1)
LDP GR: search for down nbr record (10.200.254.5:0, 10.200.216.1) returned 10.200.254.5:0
LDP GR: Added FT Sess TLV (Rconn 120000, Rcov 120000) to INIT msg to 10.200.254.5:0
LDP GR: GR session 10.200.254.5:0:: allocated instance, 1
LDP GR: GR session 10.200.254.5:0:: established
LDP GR: GR session 10.200.254.5:0:: found down nbr 10.200.254.5:0
LDP GR: down nbr 10.200.254.5:0:: reconnect timer stopped
LDP GR: down nbr 10.200.254.5:0:: state change (Reconnect-Wait -> Recovering)
LDP GR: down nbr 10.200.254.5:0:: recovery timer started [120000 msecs]
%LDP-5-GR: GR session 10.200.254.5:0 (inst. 1): starting graceful recovery
%LDP-5-NBRCHG: LDP Neighbor 10.200.254.5:0 is UP
continues
1974_chp4ONLa.fm Page 663 Tuesday, November 14, 2006 9:51 AM

663 Chapter 4: Label Distribution Protocol

Example 4-2 Example of LDP Graceful Restart: LDP Neighbor Going Down and Recovering (Continued)
%OSPF-5-ADJCHG: Process 1, Nbr 10.200.254.5 on Serial5/0 from LOADING to FULL, Loading Done

sydney#show mpls ldp graceful-restart

LDP Graceful Restart is enabled
Neighbor Liveness Timer: 120 seconds
Max Recovery Time: 120 seconds
Forwarding State Holding Time: 600 seconds
Down Neighbor Database (1 records):
VRF default:
Peer LDP Ident: 10.200.254.5:0 [inst 3], Local LDP Ident: 10.200.254.4:0
Status: recovering (68 seconds left)
Address list contains 0 addresses:
Graceful Restart-enabled Sessions:
VRF default:
Peer LDP Ident: 10.200.254.5:0, State: estab
sydney#

LDP GR: down nbr 10.200.254.5:0:: recovery timer expired

%LDP-5-GR: GR session 10.200.254.5:0 (inst. 1): completed graceful recovery
LDP GR: down nbr 10.200.254.5:0:: destroying record [0 left]
LDP GR: down nbr 10.200.254.5:0:: state change (Recovering -> Delete-Wait)
LDP GR: down nbr 10.200.254.5:0:: added to bindings task queue [1 entries]
LDP GR: Tagcon querying for up to 12 bindings update tasks [table 0]
LDP GR: down nbr 10.200.254.5:0:: requesting bindings DEL for {10.200.254.5:0, 3}
LDP GR: down nbr 10.200.254.5:0:: removed from bindings task queue [0 entries]
LDP GR: Requesting 1 bindings update tasks [0 left in queue]
LDP GR: GR session 10.200.254.5:0:: released instance, 3

It is easy to see if an LSR is running MPLS LDP Graceful Restart in SSO/NSF mode or in Helper
mode. An LSR that is running MPLS LDP Graceful Restart in Helper mode does not have the
command mpls ldp graceful-restart timers forwarding-holding secs. It can also be seen in the
output of the command show mpls ldp graceful-restart. The LSR that is running MPLS LDP
Graceful Restart in Helper mode does not display a “Forwarding State Holding Time” when you
type the command show mpls ldp graceful-restart. The router that is running MPLS LDP
Graceful Restart signals its LDP peers that it is in Helper mode by setting the Reconnect Timeout
1974_chp4ONLa.fm Page 664 Tuesday, November 14, 2006 9:51 AM

LDP Graceful Restart 664

to 0. Look at Example 4-3. You can see that the router sydney runs MPLS LDP Graceful Restart
in SSO/NSF mode, and router rome runs it in Helper mode.

Example 4-3 LDP Graceful Restart: Helper Mode Versus SSO/NSF Mode
sydney#show mpls ldp graceful-restart
LDP Graceful Restart is enabled
Neighbor Liveness Timer: 120 seconds
Max Recovery Time: 120 seconds
Forwarding State Holding Time: 600 seconds
Down Neighbor Database (0 records):
Graceful Restart-enabled Sessions:
VRF default:
Peer LDP Ident: 10.200.254.3:0, State: estab
Peer LDP Ident: 10.200.254.5:0, State: estab

sydney(config)#mpls ldp graceful-restart timers ?

forwarding-holding Forwarding State Holding time
max-recovery Max-Recovery time
neighbor-liveness Neighbor-Liveness time

rome#show mpls ldp graceful-restart

LDP Graceful Restart is enabled
Neighbor Liveness Timer: 120 seconds
Max Recovery Time: 120 seconds
Down Neighbor Database (0 records):
Graceful Restart-enabled Sessions:
VRF Default-IP-Routing-Table:
Peer LDP Ident: 10.200.254.4:0, State: estab
Peer LDP Ident: 10.200.254.2:0, State: estab

rome#
rome(config)#mpls ldp graceful-restart timers ?
max-recovery Max-Recovery time
neighbor-liveness Neighbor-Liveness time
rome#
LDP GR: Added FT Sess TLV (Rconn 0, Rcov 120000) to INIT msg to 10.200.254.4:0
1974_chp7ONLa.fm Page 665 Tuesday, November 14, 2006 9:54 AM
1974_chp7ONLa.fm Page 666 Tuesday, November 14, 2006 9:54 AM

SUPPLEMENT
CHAPTER 7
MPLS VPN

This online supplement of Chapter 7 focuses on two important MPLS VPN developments. The
first one is Inter-Autonomous MPLS VPN. Inter-Autonomous MPLS VPN is a concept whereby
two MPLS VPN service provider networks interconnect to provide a seamless VPN service to
their MPLS VPN customers, even though the customers have VPN sites that are connected to
different MPLS VPN service providers. The second important MPLS VPN development is
Carrier’s Carrier (CsC). With CsC, one MPLS VPN service provider exists, and it has other
service providers as MPLS VPN customers. These other service providers in turn provide
Internet services or MPLS VPN services to their customers.

At the end of this supplement, you will see an interesting feature called VRF Selection, whereby
the CE-facing interface on the provider edge (PE) router no longer belongs to just one virtual
routing/forwarding (VRF) instance. First, however, this supplement discusses Border Gateway
Protocol (BGP) sending IPv4 prefixes with an MPLS label.

BGP Advertising IPv4 Prefixes with a Label

In Cisco IOS, BGP advertises labels by default for vpnv4 prefixes only. Labels are not
advertised by default for IPv4 (and IPv6) routes via either iBGP or eBGP. If labels are to be
advertised for anything other than vpnv4 routes, you need to configure the send-label keyword
on the BGP neighbor command. Example 7-1 shows the send-label keyword being used.
Labels are sent for IPv4 routes to BGP neighbor 10.200.254.2.

Example 7-1 BGP neighbor Command with send-label Keyword

!
router bgp 1
bgp log-neig hbor-changes
neighbor 10 .200.254.2 remote-as 1
nei ghbor 10.200.254.2 update -source Loopback0
!
addres s-family ipv4
neighbor 10 .200.254.2 activate
neigh bor 10.200.254.2 send-lab el
no auto-summary
no sync hronization
exit-address- family
!
1974_chp7ONLa.fm Page 667 Tuesday, November 14, 2006 9:54 AM

667 Chapter 7: MPLS VPN

Note the following on using an outbound route map to limit the number of routes that BGP
advertises. This is something that you can do when deploying Inter-Autonomous MPLS VPN (see
the next section, “Inter-Autonomous MPLS VPN”) or CsC (see the section “CsC”). On an external
BGP (eBGP) session, you might want to filter certain routes and prevent them from being sent to
the eBGP neighbor. If the routes are Interior Gateway Protocol (IGP) routes that are being
redistributed into BGP, you can filter when redistributing the IGP into BGP. However, if you
deploy the filtering on the eBGP session outbound with a route map, you must ensure that the label
that is associated with the prefix is also sent. When you are deploying an outbound route map on
an eBGP neighbor and you allow certain prefixes through, these prefixes do not have a label by
default. For the label to be advertised along with the prefix when the conditions are matched in an
outbound route map, use the set mpls-label command in the route map. Otherwise, the prefix
might get through, but without the associated label. Look at Example 7-2. The idea is to only
advertise the prefix 10.10.100.3/32. The set mpls-label command in the route map ensures that
the prefix 10.10.100.3/32 is sent with an MPLS label.

Example 7-2 BGP neighbor Command with Outbound Route Map

!
router bgp 65002
no synch ronization
bgp log-neighb or-changes
network 10.10. 100.3 mask 255.255.255.25 5
neighbor 10.10.4.1 remot e-as 1
neighbor 10.10.4.1 route-map label out
neig hbor 10.10.4.1 send-label
no auto-summary
!
access-li st 1 permit 10.10.100.3
ro ute-map label permit 10
m atch ip address 1
set mpl s-label
!

When advertising IPv4 prefixes with a label, BGP by default sends an implicit NULL label for
directly connected prefixes. This means that penultimate hop popping (PHP) also occurs with BGP
as the label advertisement protocol. To have BGP advertise an explicit NULL label instead of an
implicit NULL label, configure neighbor ip-address send-label explicit-null. You might want to
have the explicit NULL label as opposed to the implicit NULL label for quality of service (QoS)
reasons. Refer to Chapter 12, “MPLS and Quality of Service,” to learn how you can use the
explicit NULL label to transport the QoS of the labeled packet.

Inter-Autonomous MPLS VPN

VPN sites might not be connected to just one MPLS VPN network. An MPLS VPN network is one
autonomous system (AS) because internal BGP runs between all the PE routers. It might be that
one VPN has sites connecting to different autonomous systems, meaning different service
1974_chp7ONLa.fm Page 668 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 668

providers. In that case, the MPLS VPN service becomes Inter-Autonomous MPLS VPN. Two or
more autonomous systems have to be interconnected at some point to provide connectivity for the
VPN sites in the different autonomous systems. The two routers that provide the connectivity
between the two autonomous systems are called the autonomous system boundary routers
(ASBRs). With MPLS VPN, all the PE routers must have a peering via internal BGP (iBGP).
Obviously, because Inter-Autonomous MPLS VPN deals with more than one service provider, this
is not possible. Service providers do not run an iBGP session to BGP peers outside of their
autonomous system. The next sections show the solutions that provide connectivity for the VPNs
across more than one AS. Three solutions provide an Inter-Autonomous MPLS VPN service.

NOTE The three solutions are described in section 10 of RFC 4364. They are often referred
to as Inter-Autonomous MPLS VPN option 10a, 10b, and 10c. They are presented here in this
order.

VRF-to-VRF
With the VRF-to-VRF solution, the ASBRs that connect the two autonomous systems must be PE
routers. They are connected via a (sub)interface that is a VRF interface on both PE routers for each
VPN that is shared between the two service providers. Therefore, the VRFs are connected back to
back on the ASBRs. Figure 7-1 shows a schematic overview of this solution.

Figure 7-1 VRF-to-VRF

CE CE
Green Green
VRF VRF

MPLS VPN MPLS VPN

Green VRF

CE Red VRF CE
Blue VRF
Red PE PE Red
VRF PE-ASBR PE-ASBR VRF

Autonomous Autonomous
System 1 System 2

CE CE
Blue Blue
VRF VRF
1974_chp7ONLa.fm Page 669 Tuesday, November 14, 2006 9:54 AM

669 Chapter 7: MPLS VPN

Because the interfaces between the two ASBRs are VRF interfaces, the traffic between the ASBRs
is plain, unlabeled IP traffic. As with regular MPLS VPN, routing needs to occur across the VRF
interface. This can be any routing protocol that regular MPLS VPN supports, as the PE-CE routing
protocol. However, because the routing serves to exchange routes across the autonomous system
border, service providers prefer eBGP, which is most likely to be seen in this solution. This
solution is simple and easy to understand, but it is not very scalable because you must use a
(sub)interface for each shared VPN; therefore, it requires some work to set it up.

You do not need new functionality for this solution. The software that offers regular MPLS VPN
provides Inter-Autonomous MPLS VPN with this solution. In fact, the ASBR has no knowledge
that it is doing Inter-Autonomous MPLS VPN. The ASBR sees the other ASBR as a CE router,
because the interface toward the other ASBR is a regular VRF interface.

eBGP Distribution of vpnv4 Routes with Label from AS to Neighboring AS

Between Directly Connected eBGP Peers
With this solution, the ASBR routers use external BGP to exchange vpnv4 or VPN-IPv4 routes
with labels between them; they are directly connected to each other at the border of their AS. The
border routers must hold the vpnv4 routes, so they need to be PE routers. If they are not PE routers,
they must be route reflectors (RR). RRs hold the vpnv4 routes without having the VRF routing
tables. Look at Figure 7-2 for a schematic overview of this solution.

Figure 7-2 eBGP Distribution of vnpv4 Routes and Label

iBGP for iBGP for

VPNv4 + Label eBGP for VPNv4 + Label
VPNv4 + Label

MPLS VPN MPLS VPN

CE CE
PE ASBR ASBR PE
Red Red
VRF Autonomous Autonomous VRF
System 1 System 2

The ASBRs do not need to have the VRF routing tables as long as they have the vpnv4 routes in
the BGP table. The packets between the ASBRs are no longer IP packets; they are labeled.
Therefore, a label switched path (LSP) needs to exist between the ingress PE in the first AS to the
egress PE router in the second AS. That is why the vpnv4 routes are exchanged with labels on the
1974_chp7ONLa.fm Page 670 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 670

eBGP session between the ASBRs. Because eBGP takes care of the label exchange, Label
Distribution Protocol (LDP) does not need to run between the ASBRs. It is not necessary to have
mpls ip configured on the interface toward the other ASBR.

For this scenario to work, the ASBR routers must run eBGP distribution of vpnv4 routes with a
label. eBGP sends vpnv4 routes with a label by default in Cisco IOS. That means you do not need
to configure the send-label keyword on the eBGP neighbor command for the ASBR. You just need
to configure the BGP neighbor command for the eBGP neighbor under the address family vpnv4
of the router bgp process and activate the peer. Figure 7-3 shows the packet forwarding between
autonomous systems with this solution.

Figure 7-3 Packet Forwarding: eBGP Distribution of vnpv4 Routes and Label

IGP Label IGP Label

VPN Label VPN Label VPN Label

IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet

MPLS VPN MPLS VPN

CE CE
PE ASBR ASBR PE
Red Red
VRF Autonomous Autonomous VRF
System 1 System 2

The VPN label that AS 2 uses is the label that the ASBR in AS 1 assigns, which is the next hop for
the vpnv4 routes that are advertised from AS 1 to AS 2. This is so unless next-hop-self is used on
the ASBR of AS 2. In that case, the ASBR in AS 2 assigns a new VPN label to the vpnv4 route and
advertises this VPN label to the PE routers in AS 2. Therefore, the VPN label used in AS 2 is either
a label that the ASBR in AS 2 assigns or a label that the ASBR in AS 1 assigns, depending on
whether next-hop-self is used on the ASBR of AS 2.

Missing VRF Problem on ASBR

By default, a PE router drops the vpnv4 route if no attached VRF is importing the vpnv4 route on
that PE router. This is a nice behavior for regular MPLS VPN because unwanted vpnv4 routes are
not stored on PE routers if no VRF imports the vpnv4 prefixes according to the route targets (RT)
on the PE. This behavior improves scalability in the MPLS VPN network. However, for Inter-
Autonomous MPLS VPN, the ASBRs need to have all the vpnv4 routes because some of them
need to be advertised to the ASBR in the other AS, regardless of whether the ASBR has a VRF
1974_chp7ONLa.fm Page 671 Tuesday, November 14, 2006 9:54 AM

671 Chapter 7: MPLS VPN

attached that is importing the vpnv4 route. In Example 7-3, you can see the BGP debug message
when a PE router receives a vpnv4 prefix when no attached VRF is importing the vpnv4 prefix.

Example 7-3 Denying a vpnv4 Route

sydney#debug ip bgp vpnv4 unicast updates in
BGP updates debugging is on (inbound) for address family: VPNv4 Unicast

sydney#
BGP(2): 10.200.254.2 rcvd UPDATE w/ attr: nexthop 10.200.254.2, origin ?, localpref
100, metric 0, extended community RT:2:2
BGP(2): 10.200.254.2 rcvd 2:2:10.140.1.1/32 -- DENIED due to: extended community not
supported;

Figure 7-4 shows a network with two autonomous systems exchanging red VPN routes. The ASBR
in autonomous system 1 rejects red VPN routes because it does not have a VRF that imports the
red vpnv4 routes. The reason is that the ASBR does not connect to a red VPN site. You can solve
the problem by configuring no bgp default route-target filter on the ASBR. As soon as you
configure this command, the ASBR accepts and stores all vpnv4 routes. Of course, if the ASBR
does have a VRF importing the red VRF routes, the problem is not apparent for this VRF.

Figure 7-4 Missing VRF Problem

No Red VRF Attached

To This ASBR

iBGP For iBGP for

VPNv4 + Label eBGP for VPNv4 + Label
VPNv4 + Label

MPLS VPN MPLS VPN

CE CE
PE ASBR ASBR PE
Red Red
VRF Autonomous Autonomous VRF
System 1 System 2

RCVD VPNv4 RD:X --- DENIED Due To

Extended Community Not Supported
1974_chp7ONLa.fm Page 672 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 672

VRF interfaces are allowed on the ASBR, but they are not needed. You need to configure a specific
VRF when the ASBR is also a PE router for a specific VPN in the autonomous system.

Next-Hop-Self and eBGP Peer Neighbor Route

On the ASBRs, you have the choice of whether to run next-hop-self. When you run next-hop-self
toward the iBGP neighbors in the AS, the ASBR must assign a label to all vpnv4 routes and
advertise this label to the iBGP peers, or PE routers. When you are not doing next-hop-self toward
the iBGP neighbors, the next hop of the vpnv4 routes is the ASBR in the neighboring AS.
Therefore, the next-hop IP address of the neighboring ASBR must be known in the local AS. Cisco
IOS helps by automatically creating a /32 connected route on the local ASBR for the IP address
of the common link on the neighboring ASBR. This automatically created route is called the eBGP
peer neighbor route and is created as soon as the eBGP neighbor under address family vpnv4 is
configured. Figure 7-5 shows the generation of this /32 route.

Figure 7-5 Generation of eBGP Peer Neighbor Route

iBGP for iBGP for

VPNv4 + Label eBGP for VPNv4 + Label
VPNv4 + Label

MPLS VPN MPLS VPN

CE CE
PE ASBR ASBR PE
Red Red
x.x.x.x
VRF Autonomous Autonomous VRF
System 1 System 2

Generates a
x.x.x.x./32 Route

You must make sure that the IGP advertises this route in the local autonomous system. You can do
this by including the link in the IGP and making the interface toward the other ASBR passive, or
you can configure redistribute connected under the IGP. Of course, when you have next-hop-self
on the local ASBR, the IGP does not need to advertise this route.

The advantage of not doing next-hop-self (and the peer neighbor route) is that the local ASBR does
not put the VPN label for every vpnv4 route it receives from the remote ASBR, in its LFIB. This
improves scalability. The outgoing label in the local ASBR is the implicit NULL label for all
vpnv4 routes from the remote AS. Also, the local ASBR does not need to assign a local label for
each vpnv4 route because it is not the next hop for these vpnv4 routes.
1974_chp7ONLa.fm Page 673 Tuesday, November 14, 2006 9:54 AM

673 Chapter 7: MPLS VPN

Multihop eBGP Distribution of vpnv4 Routes with Label Between Source

and Destination Autonomous Systems, with eBGP Distribution of IPv4
Routes with Label from AS to Neighboring AS
The routers that are exchanging the vpnv4 routes with eBGP can be RRs that are connected to each
other across an eBGP multihop session. The ASBRs do not need to be involved with exchanging
or even storing vpnv4 prefixes anymore. In fact, the two autonomous systems do not need to be
directly connected anymore; another autonomous system can exist between the two autonomous
systems that exchange the vpnv4 prefixes. Directly connected autonomous systems or not, the
ingress PE and egress PE need to have an LSP between them. That means that between
autonomous systems, the packets must be labeled at all times. Therefore, you need to advertise the
/32 IPv4 prefixes that represent the PE routers (the BGP next hops) to the other autonomous
system with a label. The /32 IPv4 prefix that is the BGP next hop address of the PE router is usually
the loopback IP address of the PE router. An IGP can exchange these /32 IPv4 PE prefixes that
build the end-to-end LSP or ingress-PE-to-egress-PE LSP between the autonomous systems. LDP
can take care of the label exchange in that case. However, service providers do not like to run an
IGP between their AS and the other AS. They also dislike running LDP to the other AS. That is
why eBGP with label exchange for IPv4 prefixes comes in handy here. BGP has proven to be
successful and scalable for interdomain routing.

The ASBRs exchange the /32 IPv4 PE loopback prefixes and associated label. However, because
an LSP needs to exist from each PE in the local AS to each PE in the remote AS, you need to
advertise the remote /32 IPv4 PE loopback prefixes to all the PE routers in the local AS. To achieve
this, advertise the /32 IPv4 prefixes to the IGP of the local AS. To limit the redistribution from
eBGP into the IGP to the /32 IPv4 PE loopback prefixes, configure route maps on the ASBRs.
Figure 7-6 shows a schematic overview of the solution, where the IPv4 /32 PE prefixes are
redistributed from IGP into eBGP and vice versa on the ASBRs.
1974_chp7ONLa.fm Page 674 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 674

Figure 7-6 Multihop eBGP Distribution of vpnv4 Prefixes and Label

Multihop eBGP For + Next -hop-unchanged

VPNv4 + Label

iBG
v4

RR RR
La VPN

eBGP For IPv4 +

P f Labe
Label
l

or
be
or

VP
Pf

Nv
iBG

l
4+
CE PE ASBR ASBR PE CE

Red VRF Red VRF

MPLS VPN MPLS VPN
Autonomous System 1 Autonomous System 2

Redistribution of /32 IPv4 PE

Loopback Prefixes From eBGP
Into IGP and Vice Versa

Another way to get the /32 IPv4 PE loopback prefixes to all the PE routers is to advertise the /32
IPv4 PE loopback prefixes (and a label) via iBGP. This means that iBGP must send IPv4 prefixes
with a label. The advertisement of these prefixes and the label via iBGP is most likely the preferred
way of getting the IPv4 prefixes from another AS into your own AS. Advertising external prefixes
into your AS via BGP is much more acceptable than advertising them into your own IGP.
1974_chp7ONLa.fm Page 675 Tuesday, November 14, 2006 9:54 AM

675 Chapter 7: MPLS VPN

Look at Figure 7-7 for a schematic overview of the solution where iBGP advertises the IPv4 /32
PE prefixes (and label) in the other autonomous systems.

Figure 7-7 Multihop eBGP Distribution of vpnv4 Prefixes and Label with iBGP for IPv4 and Label

Multihop eBGP For + Next-hop-unchanged

VPNv4 + Label
+

iBG
v4

RR RR
La VPN

eBGP For IPv4 +

P f Labe
Label
l

or
be
or

VP
Pf

Nv
iBG

l
4+
CE PE ASBR ASBR PE CE

Red VRF Red VRF

iBGP For IPv4 + iBGP For IPv4 +
Label Label

MPLS VPN MPLS VPN

Autonomous System 1 Autonomous System 2

This second solution has the following four features:

iBGP for vpnv4 + label (the default for MPLS VPN)

eBGP for vpnv4 + label
eBGP for IPv4 + label
iBGP for IPv4 + label
For the third and fourth features, you need to configure the send-label keyword on the BGP
neighbor command. The first two features do not need it, because BGP enables advertising of the
label by default for vpnv4 routes.
1974_chp7ONLa.fm Page 676 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 676

Note, too, that the RRs have an eBGP session between them to exchange the vpnv4 prefixes. By
default—as usual for external BGP—the RRs set the next hop of the vpnv4 prefixes to themselves.
That means the RRs assign a label to the vpnv4 routes, and all inter-autonomous traffic passes
through them. RRs are usually routers that have the specific function of reflecting routes and not
forwarding traffic. To prevent the RRs from setting the next hop to themselves, configure the
keyword next-hop-unchanged on the route reflectors on the BGP neighbor command under the
vpnv4 address family to the multihop eBGP neighbor. The result is that the next hop of the vpnv4
BGP prefixes will be the originating PE router.

Figure 7-8 shows the packet forwarding in the solution where the /32 IPv4 prefixes of the PE
routers are redistributed into the IGP of the other AS.

Figure 7-8 Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prefixes and Label

IGP Label eBGP Label IGP Label

VPN Label VPN Label VPN Label

IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet

RR RR

CE PE ASBR ASBR PE CE

Red VRF Red VRF

MPLS VPN MPLS VPN
Autonomous System 1 Autonomous System 2

The top label—either the IGP label or the eBGP assigned label—is always the label that is bound
to the /32 prefix of the egress PE router. You can see that the packets have two labels at all times.
1974_chp7ONLa.fm Page 677 Tuesday, November 14, 2006 9:54 AM

677 Chapter 7: MPLS VPN

Figure 7-9 shows the packet forwarding in the solution where iBGP advertises the /32 IPv4
prefixes of the PE routers in the other autonomous system.

Figure 7-9 Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prefixes and Label with iBGP for
IPv4 and Label

IGP Label

IGP Label eBGP Label iBGP Label

VPN Label VPN Label VPN Label

IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet

RR RR

CE PE ASBR ASBR PE CE

Red VRF Red VRF

MPLS VPN MPLS VPN
Autonomous System 1 Autonomous System 2

The packet has two labels in the remote AS to get it correctly to its destination. However, the
packet in the local AS has three labels. The bottom label is the usual VPN label that the egress PE
router assigns, because the RRs did not change the next hop of the vpnv4 route. The middle label
is the label that the ASBR assigns (which ASBR depends on whether the next-hop-self is set); it
gets the packet to the egress PE router. The top label is the IGP label in the local AS that gets the
packet to the ASBRs. If you want to avoid having three labels in the local autonomous system, you
must distribute the /32 IPv4 prefixes into the IGP of the local autonomous system. In that case, all
the provider (P) routers in the local AS know about the route (the next hop route of the egress PE)
and have a label binding for it. Then the packets need only two labels in the local AS, because
every P router knows the second (now the top) label. However, if you do not want the /32 prefixes
of the other AS in your IGP, you need the iBGP for IPv4 + label feature and to have packets with
three labels in the local AS.
1974_chp7ONLa.fm Page 678 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 678

Finally, you can have autonomous systems that share the same VPN but that are not directly
connected to each other. Another MPLS provider might exist between the autonomous systems.
For this to work, you need the following:

■ An LSP from the ingress PE router to the egress PE router

■ The /32 IPv4 loopback PE prefixes advertised into the remote autonomous system (preferably
carried by iBGP and not by the IGP)

Again, the /32 IPv4 PE loopback prefixes can be redistributed into the IGP of the other
autonomous systems or they can be advertised by iBGP for IPv4 + label. Figure 7-10 shows the
schematic overview of the solution where iBGP for IPv4 + label is used. Note that the middle AS
(AS 3) runs only MPLS, not MPLS VPN.

Figure 7-10 Multihop eBGP Distribution of vpnv4 Prefixes and Label Through an MPLS Network

MPLS
Autonomous System 3 iBGP For IPv4 +
Label

ASBR ASBR

eBGP for IPv4 + eBGP for IPv4 +

Label Label

Multihop eBGP For

VPNv4 + Label
iBG
be 4 +

ASBR + Next-hop-unchanged ASBR

La r IPv

P f abel
or
L
l
o

IPv
Pf
iBG

+4

CE PE RR RR PE CE
Red VRF Red VRF

iBGP for VPNv4 + iBGP for VPNv4 +

Label Label

MPLS VPN MPLS VPN

Autonomous System 1 Autonomous System 2
1974_chp7ONLa.fm Page 679 Tuesday, November 14, 2006 9:54 AM

679 Chapter 7: MPLS VPN

In Figure 7-11, you can see the packet forwarding in this solution.

Figure 7-11 Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prefixes and Label Through an
MPLS Network

IGP Label

MPLS iBGP Label

Autonomous System 3
VPN Label
ASBR ASBR
IPv4 Packet

eBGP Label eBGP Label

IGP Label

VPN Label VPN Label

IGP Label iBGP Label

IPv4 Packet IPv4 Packet

VPN Label ASBR ASBR VPN Label

IPv4 Packet IPv4 Packet

CE PE RR RR PE CE
Red VRF Red VRF

IPv4 Packet MPLS VPN MPLS VPN IPv4 Packet

Autonomous System 1 Autonomous System 2

Because iBGP for IPv4 + label is used here, the packets have three labels until they reach the
destination autonomous system. Again, if the /32 IPv4 PE loopback prefixes are not redistributed
from eBGP into the IGP of the other autonomous system, you need three labels instead of two.
The top label in the label stack of every packet is the label that gets the packet to the exit point (the
ASBR) of the autonomous system.

Nondirectly Connected eBGP Peers

The ASBRs can be directly connected over several links in parallel. If you want to use more than
one link to forward labeled traffic between the ASBRs, the eBGP session must be between the
loopback IP addresses of the BGP peers. The eBGP session, however, is not directly connected
1974_chp7ONLa.fm Page 680 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 680

anymore; it becomes a multihop session. The local ASBR has to be able to reach the loopback IP
address of the other ASBR. Because you probably do not want to run an IGP between the two
service providers, you can just configure static routes for the remote loopback IP address. You
must configure one such static route per link between the ASBRs, because you want to use each
link to forward traffic on. The eBGP multihop session can be for vpnv4 prefixes and label or for
IPv4 prefixes and label. Therefore, you can use the eBGP multihop session in all of the previously
explained solutions. Figure 7-12 shows an example of two ASBRs with two links between them
and an eBGP peering session for vpnv4 prefixes and label. You can find the configuration for this
in Example 7-4. To make it work, configure disable-connected-check for the eBGP neighbor and
mpls bgp forwarding on the interfaces toward the other ASBR.

Figure 7-12 Multihop eBGP Session for vpnv4 Prefixes and Label Between ASBRs

eBGP Multihop For

VPNv4 + Label

MPLS VPN Loopback 0 Loopback 0

MPLS VPN
10.10.100.1/32 10.10.100.3/32
Eth 1/2 Eth 1
10.10.90.2 10.10.90.1

PE 10.10.91.2 10.10.91.1 PE
ASBR Eth 1/1 Eth 0 ASBR
london-ASBR-1 sydney-ASBR-1

Autonomous Autonomous
System 65001 System 2

Example 7-4 Configuration for Nondirectly Connected eBGP Peers

!
hostname london-asbr-1
!
interface Loopback0
ip address 10.10.100.1 255.255.255.255
!
interface Ethernet1/1
ip address 10.10.91.2 255.255.255.0
mpls bgp forwarding
!
interface Ethernet1/2
ip address 10.10.90.2 255.255.255.0
mpls bgp forwarding
!
continues
1974_chp7ONLa.fm Page 681 Tuesday, November 14, 2006 9:54 AM

681 Chapter 7: MPLS VPN

Example 7-4 Configuration for Nondirectly Connected eBGP Peers (Continued)

router bgp 65001
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 10.10.100.3 remote-as 2
neighbor 10.10.100.3 disable-connected-check
neighbor 10.10.100.3 update-source Loopback0
!
!
address-family ipv4
neighbor 10.10.100.3 activate
neighbor 10.10.100.3 send-community
no auto-summary
no synchronization
network 10.10.100.1 mask 255.255.255.255
exit-address-family
!
address-family vpnv4
neighbor 10.10.100.3 activate
neighbor 10.10.100.3 send-community both
exit-address-family
!
ip route 10.10.100.3 255.255.255.255 Ethernet1/2 10.10.90.1
ip route 10.10.100.3 255.255.255.255 Ethernet1/1 10.10.91.1
!
hostname sydney-asbr-1
!
interface Loopback0
ip address 10.10.100.3 255.255.255.255
!
interface Ethernet0
ip address 10.10.91.1 255.255.255.0
mpls bgp forwarding
!
interface Ethernet1
ip address 10.10.90.1 255.255.255.0
mpls bgp forwarding
!
router bgp 2
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 10.10.100.1 remote-as 65001
neighbor 10.10.100.1 disable-connected-check
neighbor 10.10.100.1 update-source Loopback0
!
1974_chp7ONLa.fm Page 682 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 682

Example 7-4 Configuration for Nondirectly Connected eBGP Peers (Continued)

address-family ipv4
neighbor 10.10.100.1 activate
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.100.1 activate
neighbor 10.10.100.1 send-community both
exit-address-family
!
!
ip route 10.10.100.1 255.255.255.255 Ethernet1 10.10.90.2
ip route 10.10.100.1 255.255.255.255 Ethernet0 10.10.91.2
!

Example 7-5 shows that BGP is the label advertising protocol on the interfaces between the two
ASBRs. The VRF cust-one prefix 10.99.1.2/32 learned on the london-asbr-1 router is recursive to
the loopback IP address 10.10.100.3 of the sydney-asbr-1 router.

Example 7-5 Verifying Nondirectly Connected eBGP Peers

show mpls interfaces
sydney-asbr-1#s deta il
Interface Ethernet0:
IP labeling not enabled
LSP Tunnel labeling not enabled
BGP labeling enabled
MPLS operational
Fast Switching Vectors:
IP to MPLS Fast Switching Vector
MPLS Turbo Vector
MTU = 1500
Interface Ethernet1:
IP labeling not enabled
LSP Tunnel labeling not enabled
BGP labeling enabled
MPLS operational
Fast Switching Vectors:
IP to MPLS Fast Switching Vector
MPLS Turbo Vector
MTU = 1500

show ip bgp vpnv4 rd 1:1 1 0.99.1.2

london-asbr-1#s
BGP routing table entry for 1:1:10.99.1.2/32, version 89
Paths: (1 available, best #1, table cust-one)
continues
1974_chp7ONLa.fm Page 683 Tuesday, November 14, 2006 9:54 AM

683 Chapter 7: MPLS VPN

Example 7-5 Verifying Nondirectly Connected eBGP Peers (Continued)

Advertised to update-groups:
1
2 1
10.10.100.3 from 10.10.100.3 (10.10.100.33)
Origin incomplete, localpref 100, valid, external, best
Extended Community: RT:1:1 0x8800:32768:0 0x8801:42:128000
0x8802:65280:256 0x8803:65281:1514,
mpls labels in/out 34/26

show ip cef vrf cust-one 1 0.99.1.2

london-asbr-1#s
10.99.1.2/32, version 26, epoch 0, per-destination sharing
0 packets, 0 bytes
tag information set, all rewrites owned
local tag: 34
fast tag rewrite with
Recursive rewrite via 10.10.100.3/32, tags imposed {26}
via 10.10.100.3, 0 dependencies, recursive
next hop 10.10.90.1, Ethernet1/2 via 10.10.100.3/32 (Default)
valid adjacency
tag rewrite with
Recursive rewrite via 10.10.100.3/32, tags imposed {26}
Recursive load sharing using 10.10.100.3/32.

RT Rewrite
When two service providers perform Inter-Autonomous MPLS VPN, they need to synchronize
and agree on the RTs that are used on the vpnv4 routes they exchange. This can be tedious,
especially if one or both parties need to change the RTs used in their network. The RT Rewrite
feature is a nice workaround to the problem because the RT is simply replaced on the ASBR router.
As such, each service provider can keep its own policy regarding the RT assignment. The service
provider needs to configure a route map toward the other service provider. This route map allows
deletion of the RT and replacement with a new one. RT rewrite is supported both in the inbound
and outbound directions. Therefore, you can use an inbound or an outbound route map to replace
the RT. The set extcomm-list extended-community-list-number delete command and the set
extcommunity rt extended-community-value [additive] command replace the RT. Look at
Example 7-6 and Figure 7-13, where the sydney ASBR in AS 1 rewrites the RT 1:1 to 2:1 toward
the eBGP neighbor 10.10.4.2 in AS 2. On the sydney ASBR in AS 2, the RT on the vpnv4 prefix
is 2:1.
1974_chp7ONLa.fm Page 684 Tuesday, November 14, 2006 9:54 AM

Inter-Autonomous MPLS VPN 684

Figure 7-13 RT Rewrite

iBGP for eBGP for iBGP for

VPNv4 + Label VPNv4 + Label VPNv4 + Label

MPLS VPN MPLS VPN

PE ASBR ASBR PE
Rewrite RT
sydney-as-1 1:1 to RT 2:1 sydney-as-2

10.10.100.1/32 10.10.100.1/32 10.10.100.1/32

RT 1:1 RT 2:1 RT 2:1

Autonomous Autonomous
System 1 System 2

Example 7-6 RT Rewrite

!
hostname sydney-as-1
!
router bgp 1
!
address-family vpnv4
neighbor 10.10.4.2 activate
neighbor 10.10.4.2 send-community both
neighbor 10.10.4.2 route-map to-as-2 out
neighbor 10.200.254.3 activate
neighbor 10.200.254.3 send-community both
exit-address-family
!
!
ip extcommunity-list 2 permit rt 1:1
!
route-map to-as-2 permit 10
match extcommunity 2
set extcomm-list 2 delete
set extcommunity rt 2:1 additive
!

continues
1974_chp7ONLa.fm Page 685 Tuesday, November 14, 2006 9:54 AM

685 Chapter 7: MPLS VPN

Example 7-6 RT Rewrite (Continued)

show ip bgp vpnv4 all 10.1 0.100.1
sydney-as-1#s
BGP routing table entry for 1:1:10.10.100.1/32, version 8
Paths: (1 available, best #1, table cust-one)
Advertised to update-groups:
3
65001
10.200.254.2 (metric 3) from 10.200.254.3 (194.68.129.9)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1
Originator: 10.200.254.2, Cluster list: 194.68.129.9,
mpls labels in/out 33/45

show ip bgp vpnv4 all 10.1 0.100.1

sydney-as-2#s
BGP routing table entry for 1:1:10.10.100.1/32, version 10
Paths: (1 available, best #1, no table)
Flag: 0xA00
Not advertised to any peer
1 65001
10.10.4.1 from 10.10.4.1 (192.168.99.1)
Origin IGP, localpref 100, valid, external, best
Extended Community: RT:2:1,
mpls labels in/out nolabel/33

CsC
CsC is a solution involving a carrier (named the Carrier’s Carrier) providing MPLS VPN services
to other carriers or service providers. This can be done by using regular MPLS VPN. However,
because every service provider is carrying a huge number of customer routes and the CsC is to
provide MPLS VPN service to the smaller carriers, scaling is a problem. To solve the scaling
problem, MPLS is extended by at least one hop. In other words, MPLS is extended by including
the carrier CE router (CSC-CE) in the MPLS domain. Figure 7-14 has an overview of CsC.
1974_chp7ONLa.fm Page 686 Tuesday, November 14, 2006 9:54 AM

CsC 686

Figure 7-14 Overview of CsC

Carrier’s Carrier (CSC)

MPLS VPN Network

MPLS
CSC-PE CSC-PE

CSC-CE CSC-CE

Carrier 1 Carrier 1
Site A BGP Site B

ASBR ASBR

Customer 1 Customer 2 Customer 1 Customer 2

Site A Site A Site B Site B

MPLS is extended to the customer edge (CE) router, which means a label distribution protocol is
needed between the PE—across the VRF interface—and the CE routers. This can be achieved by
any IGP that is supported on VRF interfaces together with LDP for the label distribution, or it can
be eBGP for IPv4 routes with label exchange.
1974_chp7ONLa.fm Page 687 Tuesday, November 14, 2006 9:54 AM

687 Chapter 7: MPLS VPN

You can see one larger carrier, the CsC, providing MPLS VPN services to the smaller carriers and
MPLS extended to include the CE routers of the smaller carriers. More routers from the carriers
might be running MPLS. This is discussed further in the later section “CsC Scenarios.” The
customer sites are attached to the sites of the carriers by interfacing with ASBRs. The carriers
carry the customer routes in BGP, because these routes are external to the carrier’s networks. The
BGP sessions between the sites of a carrier are usually iBGP if one AS number is used for one
carrier. It could technically be eBGP, too, but then one carrier needs to use multiple AS numbers.
For instance, one AS number can be used for each site of one carrier.

MPLS Across the VRF Interface

The great benefit of CsC comes from running MPLS between the CSC-PE and CSC-CE. The
CSC-PE router no longer needs to look up the destination IP addresses in the VRF routing table
because now it is label-switching traffic to and from the CSC-CE router. The carriers are carrying
their customer prefixes in BGP. If the BGP next-hop addresses are advertised into their IGP (they
should be), they are known to the CsC and are in the carrier VRF routing table on the CSC-PE
routers. The label switching of the customer traffic of the carriers is done based on the label that
is assigned to the BGP next-hop prefixes. Therefore, the CsC does not need to carry the customer
BGP routes of the carriers in the VRF routing tables on the PE routers, but only the BGP next-hop
prefixes. This makes CsC a scalable solution and provides hierarchy.

Routing and Label Exchange Between CSC-PE and CSC-CE

The routing and label exchange between the CSC-PE and CSC-CE can be a supported IGP that
can run across a VRF interface, with LDP taking care of the label distribution. Alternatively, it can
be eBGP advertising IPv4 routes with labels across the VRF interface. The choice is yours, but the
Cisco IOS software on the CSC-PE must support MPLS on the VRF interface. Furthermore, the
CSC-CE must also support MPLS.

Because you now have a VRF interface on the CSC-PE router on which to receive and forward
labeled packets, some enhancements were needed on top of the regular MPLS VPN solution.

LDP Across the VRF Interface

LDP was enhanced so that it can run on the VRF interface on the PE router. You enable LDP by
configuring mpls ip on the VRF interface toward the CSC-CE router. (You must enable LDP on
the CSC-CE router too, of course.) The show mpls ldp commands have been enhanced with the
1974_chp7ONLa.fm Page 688 Tuesday, November 14, 2006 9:54 AM

CsC 688

VRF keyword. Look at Example 7-7 for the output of the LDP commands when LDP is
configured on a VRF interface.

Example 7-7 Example of LDP Commands for CsC

!
hostname london
!
interface Ethernet0/1/2
ip vrf for warding cust-one
ip addre ss 10.10.2.2 255.255.255. 0
mpls ip
!
show mpls ldp neighbor vrf cust-one
london#s
Peer LDP Ident: 10.10.100.1:0; Local LDP Ident 10.99.1.1:0
TCP connection: 10.10.100.1.646 - 10.99.1.1.12229
State: Oper; Msgs sent/rcvd: 6/8; Downstream
Up time: 00:00:15
LDP discovery sources:
Ethernet0/1/2, Src IP addr: 10.10.2.1
Addresses bound to peer LDP Ident:
10.10.2.1 10.10.100.1 192.168.1.1 10.88.1.1

show mpls ldp bindings vrf cust-one

london#s
lib entry: 10.10.2.0/24, rev 2
local binding: label: 46
remote binding: lsr: 10.10.100.1:0, label: imp-null
lib entry: 10.10.100.1/32, rev 4
local binding: label: 45
remote binding: lsr: 10.10.100.1:0, label: imp-null
lib entry: 10.10.101.1/32, rev 8
remote binding: lsr: 10.10.100.1:0, label: 16
lib entry: 10.88.1.1/32, rev 7
remote binding: lsr: 10.10.100.1:0, label: imp-null
lib entry: 10.99.1.1/32, rev 6
local binding: label: 32
lib entry: 192.168.1.0/24, rev 9
remote binding: lsr: 10.10.100.1:0, label: imp-null

show mpls ldp discovery vr f cust-one

london#s
Local LDP Identifier:
10.99.1.1:0
Discovery Sources:
continues
1974_chp7ONLa.fm Page 689 Tuesday, November 14, 2006 9:54 AM

689 Chapter 7: MPLS VPN

Example 7-7 Example of LDP Commands for CsC (Continued)

Interfaces:
Ethernet0/1/2 (ldp): xmit/recv
LDP Id: 10.10.100.1:0

show mpls interfaces vrf c ust-one detail

london#s

VRF cust-one:
Interface Ethernet0/1/2:
IP labeling enabled (ldp)
LSP Tunnel labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1500

eBGP Across the VRF Interface

If you choose eBGP for IPv4 and label distribution between the CSC-PE and CSC-CE, you must
configure the send-label keyword on the eBGP peer neighbor command under the address family
IPv4 VRF under the router bgp process. Look at Example 7-8, where eBGP and label distribution
are enabled on the london PE and CE routers. The CE prefix 10.10.100.1/32 is now showing an
outgoing label of Pop Label toward the CE in the label forwarding information base (LFIB) on the
PE router. The remote VRF prefix 10.99.1.2/32 is now showing an outgoing label 33 on the CE
router. The show mpls interfaces command shows that BGP is taking care of the label distribution
between the PE and CE and not LDP.

Example 7-8 eBGP for IPv4 and Label on a VRF Interface

!
hostname london
!
router bg p 1
…
!
address-family ipv4 vrf cust-one
redistribut e connected
neighbor 10.1 0.2.1 remote-as 65001
neig hbor 10.10.2.1 activate
n eighbor 10.10.2.1 send-la bel
exit-address-family
!

show mpls interfaces vrf c ust-one detail

london#s

VRF cust-one:
Interface Ethernet0/1/2:
IP labeling not enabled
1974_chp7ONLa.fm Page 690 Tuesday, November 14, 2006 9:54 AM

CsC 690

Example 7-8 eBGP for IPv4 and Label on a VRF Interface (Continued)
LSP Tunnel labeling not enabled
BGP labeling enabled
MPLS operational
MTU = 1500

show ip bgp 10.99.1.2 255. 255.255.255

london-ce#s
BGP routing table entry for 10.99.1.2/32, version 45
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
1
10.10.2.2 from 10.10.2.2 (10.200.254.2)
Origin incomplete, localpref 100, valid, external, best,
mpls labels in/out nolabel/33

show mpls forwarding-table vrf cust-one 10.10.100.1

london#s
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
45 Pop Label 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1

LFIB
When you deploy CsC, the LFIB shows that packets are forwarded labeled instead of unlabeled
on the outgoing VRF interface on the PE router. Also, the packets arriving from the CSC-CE router
are already labeled. The outgoing label stack for packets toward the remote PE is two labels—as
usual with MPLS VPN. The packets from the CSC-CE, arriving on the VRF interface on the CSC-
PE, are forwarded by a lookup in the LFIB table on the CSC-PE router, as they are labeled. The
top label is the label that is associated with the VRF prefix, advertised from the PE to the CE by
LDP or eBGP. With regular MPLS VPN, the packets from the CE router were always IP packets,
so the forwarding was done based on an IP lookup of the destination IP address in the appropriate
VRF routing table. Example 7-9 shows LFIB entries on the CSC-PE router for VRF prefixes. For
the VRF prefix 10.10.100.1/32 learned from the London CSC-CE router, the outgoing label is now
Pop Label. With regular MPLS VPN, the outgoing label was No Label. The Pop Label is the result
of PHP, which is on by default between the CSC-PE and CSC-CE.

You can also see in Example 7-9 that packets are sent labeled from the CSC-CE router toward the
CSC-PE router. The prefix 10.99.1.2/32 shows up in the CEF table on the CSC-CE router with an
outgoing label of 33. Regular MPLS VPN had no outgoing label toward the PE router. The
outgoing label stack on the ingress CSC-PE router for this VRF prefix consists of two labels.

Example 7-9 LFIB Entries on the CSC-PE

show mpls forwarding-table vrf cust-one
london#s
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
18 Pop Label 10.10.2.1/32[V] 0 Et0/1/2 10.10.2.1
continues
1974_chp7ONLa.fm Page 691 Tuesday, November 14, 2006 9:54 AM

691 Chapter 7: MPLS VPN

Example 7-9 LFIB Entries on the CSC-PE (Continued)

32 Aggregate 10.99.1.1/32[V] 0 cust-one
33 22 10.99.1.2/32[V] 0 PO4/0/0 point2point
45 Pop Label 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1
46 Aggregate 10.10.2.0/24[V] 0 cust-one

show mpls forwarding-table vrf cust-one 10.10.100.1

london#s
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
45 Pop Label 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1

show ip cef 10.99.1.2

london-ce#s
10.99.1.2/32, version 648, epoch 0, cached adjacency 10.10.2.2
0 packets, 0 bytes
tag information set
local tag: BGP route head
fast tag rewrite with Et1/1, 10.10.2.2, tags imposed: {33}
via 10.10.2.2, 0 dependencies, recursive
next hop 10.10.2.2, Ethernet1/1 via 10.10.2.2/32
valid cached adjacency
tag rewrite with Et1/1, 10.10.2.2, tags imposed: {33}

show mpls forwarding-table vrf cust-one 10.99.1.2 d etail

london#s
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
33 22 10.99.1.2/32[V] 0 PO4/0/0 point2point
MAC/Encaps=4/12, MRU=4466, Label Stack{19 22}
0F008847 0001300000016000
VPN route: cust-one
No output feature configured

Anti-Label Spoofing Mechanism

When a VRF interface of a PE router that is running Cisco IOS receives a labeled packet, the PE
checks whether the label was a locally assigned label for that VRF. If it was not, the labeled packet
is dropped. With CsC, the packets from customers arriving on the PE router can be labeled, so it
is important to check whether that label was indeed assigned to that VRF. This effectively prevents
one customer from spoofing packets with labels that are assigned to another customer, both
connected to the same service provider.
1974_chp7ONLa.fm Page 692 Tuesday, November 14, 2006 9:54 AM

CsC 692

CsC Scenarios
The possible CsC scenarios can be classified into three categories:

■ Only the CE routers run MPLS.

■ All carrier C routers run MPLS.

■ There is hierarchical MPLS VPN.

The first two scenarios differ from each other in the way that MPLS and BGP are deployed in the
carrier networks. In the third scenario, the carriers also run MPLS VPN. Because the CsC and the
carriers run MPLS VPN, this third scenario is commonly referred to as the Hierarchical MPLS
VPN scenario. No matter what scenario you deploy, the characteristic feature of CsC is that the
VRF interface of the CSC-PE router must have labeled traffic. Remember that for all three
scenarios, an IGP and LDP can exist between the CSC-PE and CSC-CE, or eBGP and label
distribution can exist between the CSC-PE and CSC-CE.

Only the CE Routers Run MPLS

In this scenario, only the CSC-CE routers run MPLS. All the customer routes are BGP routes. For
the C routers of the carrier network to forward the customer traffic, they must run BGP. Therefore,
all the C routers of the carrier network run iBGP, not just the border routers. This is because every
router in the carrier network is still forwarding IP packets. Figure 7-15 shows that MPLS is
extended to include the CSC-CE routers only. iBGP runs between the sites of the carrier to
advertise the customer (BGP) routes.

Figure 7-15 Schematic Overview of Information Exchange in the First CsC Scenario

MPLS

Carrier 1 IGP Carrier 1 IGP

Routes + Label Routes + Label

CsC
Carrier 1 Site A Carrier 1
Site B
iBGP iBGP
ASBR CSC-CE CSC-PE CSC-PE CSC-CE ASBR

iBGP VPNv4 Routes + Label

iBGP VPNv4 Routes

1974_chp7ONLa.fm Page 693 Tuesday, November 14, 2006 9:54 AM

693 Chapter 7: MPLS VPN

For an overview of the packet forwarding in this scenario, check out Figure 7-16. The packets have
two MPLS labels in the CsC network. This is no different from regular MPLS VPN. However, the
packets on the links between the CSC-PE and CSC-CE now have one label. The result of this is
that the CSC-PE does not need to perform an IP lookup of the destination IP address in the IP
header anymore. When a packet arrives on the VRF interface of the CSC-PE, it looks up the label
in the LFIB and forwards the packet accordingly.

Figure 7-16 Schematic Overview of the Packet Forwarding in the First CsC Scenario

CsC
Carrier 1 Site A Carrier 1
Site B
iBGP iBGP
ASBR CSC-CE CSC-PE CSC-CE CSC-PE ASBR

IGP CSC
Label

IGP Carrier 1 CSC VPN IGP Carrier 1

Label Label Label

IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet

All Carrier C Routers Run MPLS

In this scenario, all the carrier C routers run MPLS. Therefore, the carrier C routers forward traffic
to the customers by performing a label lookup in the LFIB, not by performing an IP lookup.
Because the customer routes in the carrier network are known as BGP routes, and because the
labeled traffic can be forwarded based on the label that is assigned to the BGP next hop, only the
edge routers in the carrier network need to be running BGP. This is already a great improvement
over the first CsC scenario, in which all C routers were required to run BGP. Look at Figure 7-17
for the schematic overview of this scenario.
1974_chp7ONLa.fm Page 694 Tuesday, November 14, 2006 9:54 AM

CsC 694

Figure 7-17 Schematic Overview of Information Exchange in the Second CsC Scenario

MPLS

Carrier 1 IGP Carrier 1 IGP

Routes + Label Routes + Label

CsC
Carrier 1 Site A Carrier 1
Site B

ASBR CSC-CE CSC-PE CSC-PE CSC-CE ASBR

iBGP VPNv4 Routes + Label

iBGP IPv4 Routes

Because all routers in the carrier network run MPLS, only the ASBR routers need to run BGP.
Figure 7-18 shows the packet forwarding in this scenario.

Figure 7-18 Schematic Overview of the Packet Forwarding in the Second CsC Scenario

CsC
Carrier 1 Site A Carrier 1
Site B

ASBR CSC-CE CSC-PE CSC-PE CSC-CE ASBR

IGP CSC
Label

IGP Carrier 1 IGP Carrier 1 CSC VPN IGP Carrier 1 IGP Carrier 1
Label Label Label Label Label

IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet

The difference between this and the first scenario is that the packets in the carrier network are
labeled throughout the network.
1974_chp7ONLa.fm Page 695 Tuesday, November 14, 2006 9:54 AM

695 Chapter 7: MPLS VPN

Hierarchical MPLS VPN

In this scenario, all the carrier C routers run MPLS, and there is MPLS VPN. The carriers in turn
have their own PE routers interfacing with their customer routers through a VRF interface. The
benefit of this scenario over the second CsC scenario is that now the customer routes are in their
own VRF in the carrier network. This is hierarchical MPLS VPN because the carriers are VPN
customers of the CsC, and the customers are VPN customers of the carriers. Figure 7-19 shows
the schematic overview of this scenario.

Figure 7-19 Schematic Overview of Information Exchange in the Third CsC Scenario

MPLS

Carrier 1 IGP Carrier 1 IGP

Routes + Label Routes + Label

CsC
Carrier 1 Site A Carrier 1
Site B

ASBR CSC-CE CSC-PE CSC-PE CSC-CE ASBR

(PE) iBGP VPNv4 Routes + Label (PE)

iBGP IPv4 Routes + Label

As with the second CsC scenario, MPLS is extended throughout the carrier network. In this third
scenario, the carriers provide MPLS VPN services toward their customers. Therefore, the ASBR
routers need to be PE routers. The PE routers have VRF interfaces toward the CE routers of the
customers. As the carrier runs MPLS VPN, the carrier PE routers need to run iBGP, exchanging
vpnv4 routes with a label. From the carrier perspective, he is not doing anything else except
running MPLS VPN. From the perspective of the CsC, he is running MPLS VPN and label
distribution across the VRF interfaces toward the carriers.
1974_chp7ONLa.fm Page 696 Tuesday, November 14, 2006 9:54 AM

VRF Selection Based on Source IP Address 696

You can see an overview of the packet forwarding in this scenario in Figure 7-20.

Figure 7-20 Schematic Overview of the Packet Forwarding in the Third CsC Scenario

CsC
Carrier 1 Site A Carrier 1
Site B

ASBR CSC-CE CSC-PE CSC-PE CSC-CE ASBR

(PE) (PE)
IGP CSC
Label

IGP Carrier 1 IGP Carrier 1 CSC VPN IGP Carrier 1 IGP Carrier 1
Label Label Label Label Label

Carrier 1 Carrier 1 Carrier 1 Carrier 1 Carrier 1

VPN Label VPN Label VPN Label VPN Label VPN Label

IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet

In the carrier network, the customer packets have two labels. This is expected, because this is
regular MPLS VPN. In the CsC network, however, the packets have three labels. The bottom label
is the label that forwards the packet on the egress PE router. The middle label is the CSC VPN
label that forwards the packet out of the correct VRF interface on the CSC-PE router. The top label
is the IGP CSC label that forwards the packet to the correct egress CSC-PE router in the CsC
network.

VRF Selection Based on Source IP Address

When packets from the CE router enter the PE router with MPLS VPN, they are seen as coming
from one and only one VRF. This is based on the VRF configuration on the interface of the PE
router toward the CE. If the service provider, for example, has a cable broadband access network
toward the CE routers, all CE routers can be in only one VRF. If the cable provider wants to
provide a service whereby he offers the opportunity for customers to get to the Internet via
different Internet service providers (ISPs), he has to put an extra CE router in front of the PE router
and route the traffic based on the source IP address to a different interface on the PE router. This
routing based on the source IP address can be done with policy-based routing (PBR) in Cisco IOS.
It entails that a PBR CE router sits in front of the PE router. Multiple physical interfaces can exist
between the PBR CE and the PE router. However, an easier and cheaper method is to have multiple
1974_chp7ONLa.fm Page 697 Tuesday, November 14, 2006 9:54 AM

697 Chapter 7: MPLS VPN

VLAN interfaces from the PBR CE router to the PE router and map a VRF to each VLAN
interface. This solution does require an extra CE router for the PBR, though. Figure 7-21 gives an
overview of this PBR solution.

Figure 7-21 PBR to PE Router

ISP 1
Broadband
Access
Network
CE
VRF
AS 1 cust-one

10.10.1.103
Policy-Based PE ISP 2
Routing to VLAN
Interfaces
VLAN 10 VRF cust-one
VLAN 11 VRF cust-two CE
VLAN 12 VRF cust-three
10.10.1.77 PE VRF
CE PE cust-two

PE ISP 3
MPLS VPN

10.10.1.10
CE
VRF
cust-three

The traffic from the three hosts on the broadband access network is policy-routed onto the
corresponding VRF interface of the PE router. The traffic is then routed on the PE through regular
MPLS VPN toward one ISP in one VPN.

Another solution, VRF selection, offers the same functionality without the need for the extra router
for the PBR in front of the PE router. With that solution, the hosts on the broadband access network
are directly connected to the PE router. The interface on the PE router toward the hosts is put in
the global routing table instead of a VRF. However, that interface is configured with VRF
selection, which enables the PE router to route the traffic to a particular VRF based on the source
IP address. Figure 7-22 shows the same network as Figure 7-21, but now with VRF Selection.
1974_chp7ONLa.fm Page 698 Tuesday, November 14, 2006 9:54 AM

VRF Selection Based on Source IP Address 698

Figure 7-22 VRF Selection

ISP 1
Broadband
Access
Network
CE
VRF
AS 1 cust-one

10.10.1.103
PE ISP 2

VRF Selection CE
Based On
10.10.1.77 Source IP PE VRF
Address PE cust-two

PE ISP 3
MPLS VPN

10.10.1.10
CE
VRF
cust-three

After the traffic is routed to the chosen VRF, it is forwarded according to the VRF routing table on
the PE router. The traffic is then forwarded as regular MPLS VPN traffic in the backbone, with two
labels on the packet as usual.

The interface on the PE router toward the hosts (or CE routers) is in the global routing table.
Therefore, the return traffic from the Internet (or the VRF sites) is forwarded according to the
global routing table in the MPLS VPN network. The traffic can be sent back by having the network
statement of BGP cover the IP subnet of that broadband access interface on the PE router. On the
remote PE router, a static route in the VRF with a global next-hop IP address enables the traffic to
be forwarded back to this PE router where VRF Selection is enabled. Example 7-10 shows a
sample configuration for VRF Selection based on source IP address. The traffic from source IP
address 10.10.1.103 is forwarded into VRF cust-one, and the traffic from source IP address
10.10.1.10 is forwarded into VRF cust-two. The command to enable VRF Selection on the
customer-facing interface is ip vrf select source. The command to map source IP addresses to
1974_chp7ONLa.fm Page 699 Tuesday, November 14, 2006 9:54 AM

699 Chapter 7: MPLS VPN

VRFs is vrf selection source source-IP-address source-IP-mask vrf vrf_name. The command
show ip vrf select demonstrates the configured VRF Selection policy.

Example 7-10 VRF Selection Based on Source IP Address

!
hostname london

!
ip vrf cust-one
rd 1:1
route-target export 1:1
route-target import 1:1
!
ip vrf cust-two
rd 2:2
route-target export 2:2
route-target import 2:2
!
interface Ethernet0/1/2
ip vrf select source
ip address 10.10.1.1 255.255.255.0
!
vrf selection source 10.10.1.103 255.255.255.255 vrf cust-one
vrf selection source 10.10.1.10 255.255.255.255 vrf cust-two
!
router bgp 1
…
!
address-family ipv4 vrf cust-two
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf cust-one
redistribute connected
no auto-summary
no synchronization
exit-address-family
!

show ip vrf select

london#s
VRF Selection Information
Source IP-Address Mask Selected VRF Table
10.10.1.103 255.255.255.255 cust-one
10.10.1.10 255.255.255.255 cust-two
1974_chp7ONLa.fm Page 700 Tuesday, November 14, 2006 9:54 AM

VRF Selection Based on Source IP Address 700

You can configure ip vrf receive vrf_name on the VRF Selection interface to announce the subnet
directly into the VRF routing table. In this way, the return traffic does not need to be routed back
to this PE router according to the global routing table, because the subnet prefix is advertised as a
vpnv4 prefix. Example 7-11 shows how the command ip vrf receive is applied to announce the
subnet 10.10.1.0/24 in the VRFs cust-one and cust-two of Example 7-10.

Example 7-11 Announcement of the Interface Subnet into the VRFs

!
interface Ethernet0/1/2
i p vrf select source
ip vr f receive cust-one
ip vrf receive cust-two
ip addr ess 10.10.1.1 255.255.255. 0
!

Traffic with an unknown source IP address from a VRF Selection interface is forwarded according
to the global routing table on the PE router. This allows malicious traffic if the source IP address
is spoofed. To prevent this, you can configure a VRF on the PE router to drop such traffic. To drop
this potentially malicious traffic, the VRF can route it to a NULL interface on the PE router with
a static route. Example 7-12 shows the extra VRF named drop configured on the PE router, which
serves as a bucket to drop packets with an unknown source IP address.

Example 7-12 Drop VRF for Unknown Source IP Addresses

!
ip vrf drop
rd 9999:9999
!
vrf selection source 10.1 0.1.103 255.255.255.255 v rf cust-one
vrf selection source 10.10.1.10 255.255. 255.255 vrf cust-two
vrf s election source 0.0.0.0 0 .0.0.0 vrf drop
!
ip route vrf drop 0.0.0.0 0.0.0.0 N ull0
!

show ip route vrf drop

london#s

Routing Table: drop

Codes: C - connected, S - static, 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, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S* 0.0.0.0/0 is directly connected, Null0

1974_chp8ONLba.fm Page 701 Tuesday, November 14, 2006 9:58 AM
1974_chp8ONLba.fm Page 702 Tuesday, November 14, 2006 9:58 AM

SUPPLEMENT
CHAPTER 8
MPLS Traffic Engineering

This online supplement of Chapter 8 deals with a few advanced traffic engineering (TE) topics.
Ensure that you have read Chapter 8 in the book before you read this supplement. This
supplement first covers some Resource Reservation Protocol (RSVP) enhancements that were
developed for MPLS TE, and then it discusses some bandwidth options for TE tunnels.

An important new advancement is MPLS TE auto tunnels. Although they are regular TE tunnels,
they are special in one way: Cisco IOS automatically creates them. As such, the operator is
saved from the tedious task of having to configure many TE tunnels in the network. DiffServ-
aware TE tunnels are briefly explained in this supplement. You will learn how they differ from
the kind of TE tunnels that have been covered so far. All the TE tunnels that you have seen so
far have been tunnels inside one area, or intra-area TE tunnels. Here, you learn how to
implement interarea TE tunnels. This online supplement finishes with a brief overview on how
to troubleshoot MPLS TE.

RSVP Enhancements
RFC 2961, “RSVP Refresh Overhead Reduction Extensions,” specifies mechanisms to reduce
the number of RSVP packets sent and to enhance the scalability and reliability of RSVP. RSVP
is a chatty protocol that sends periodic refreshes. This is why RSVP is often referred to as being
a soft-state protocol. If no refreshes were to be received for some time, the reservation state
would be removed. PATH and RESV messages are sent periodically—more or less every 30
seconds. This enhancement makes RSVP more reliable by introducing acknowledgements and
makes it more scalable by bundling several messages into one packet and by summarizing
refresh messages. To enable RSVP refresh reduction, you need to configure the following global
command:

ip rsvp signalling refresh reduction

The default refresh interval for RSVP messages is 30 seconds. You can change this with the
following command:

ip rsvp signalling refresh interval interval-value

1974_chp8ONLba.fm Page 703 Tuesday, November 14, 2006 9:58 AM

703 Chapter 8: MPLS Traffic Engineering

If four successive refreshes are lost, RSVP removes the state. You can change this default with the
following command:

ip rsvp signalling refresh misses msg-count

The msg-count value is a value between 2 and 10.

RSVP Hello
Normally, when a link failure occurs, it is detected immediately or at least quickly. At that point,
RSVP signals the problem by sending a Path Error to the head end router, and the Interior Gateway
Protocol (IGP) advertises it. However, when the two label switching routers (LSR) are connected
through a Layer 2 switched network, it is possible for the failure in Layer 3 communication
between the two routers to remain undetected for some time, because the links on both sides
remain in the up state. RSVP hellos can bring a faster means of detecting a failure between LSRs.
The command to enable RSVP hellos is this:

ip rsvp signalling hello

Every interval, a Hello Request is sent to the neighboring router. This neighboring router responds
by sending a Hello Ack back. If four intervals pass without receiving a Hello Ack, the router
declares the neighbor down.

The following command lets you change the interval for sending RSVP Hello packets:

ip rsvp signalling hello refresh interval interval-value

The interval-value is a number between 1000 and 30,000 that is in milliseconds. By default, an
RSVP Hello packet is sent every 10 seconds.

You can also change the number of missed acknowledgement packets before declaring the
neighbor down with the following command:

ip rsvp signalling hello refresh misses msg-count

The msg-count value is a value between 4 and 10.

IP RSVP Debugging
Example 8-1 demonstrates some show ip rsvp commands that can be helpful in troubleshooting
RSVP. Notice that you can use these commands to show the reserved bandwidth by TE tunnels
and their attributes.

Example 8-1 show ip rsvp Commands

brussels#show ip rsvp neighbor
10.200.193.1 RSVP
10.200.194.2 RSVP
1974_chp8ONLba.fm Page 704 Tuesday, November 14, 2006 9:58 AM

IP RSVP Debugging 704

Example 8-1 show ip rsvp Commands (Continued)

10.200.210.1 RSVP
10.200.211.2 RSVP
10.200.212.2 RSVP
10.200.213.2 RSVP
10.200.254.5 Unknown

brussels#show ip rsvp interface

interface rsvp allocated i/f max flow max sub max
PO10/0 ena 0 155M 155M 10M
PO10/1 ena 0 155M 155M 10M
PO10/2 ena 0 155M 155M 10M
PO10/3 ena 100M 155M 155M 10M
PO14/0 ena 0 155M 155M 0
Tu1000 ena 0 0 0 0
Tu2000 ena 0 0 0 0

brussels#show ip rsvp interface detail

PO10/3:
RSVP: Enabled
Bandwidth:
Curr allocated: 100M bits/sec
Max. allowed (total): 155M bits/sec
Max. allowed (per flow): 155M bits/sec
Max. allowed for LSP tunnels using sub-pools: 10M bits/sec
Set aside by policy (total): 0 bits/sec
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled

brussels#show ip rsvp reservation

To From Pro DPort Sport Next Hop I/F Fi Serv BPS
10.200.254.5 10.200.254.2 0 1 5846 10.200.211.2 PO10/3 SE LOAD 100M
10.200.254.5 10.200.254.3 0 1000 420 10.200.212.2 PO10/1 SE LOAD 0

brussels#show ip rsvp reservation detail

Reservation:
Tun Dest: 10.200.254.5 Tun ID: 1 Ext Tun ID: 10.200.254.2
Tun Sender: 10.200.254.2 LSP ID: 5846
Next Hop: 10.200.211.2 on POS10/3
Label: 0 (outgoing)
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 100M bits/sec, Maximum Burst is 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
RRO:
10.200.211.2/32, Flags:0x0 (No Local Protection)
Label subobject: Flags 0x1, C-Type 1, Label 0
continues
1974_chp8ONLba.fm Page 705 Tuesday, November 14, 2006 9:58 AM

705 Chapter 8: MPLS Traffic Engineering

Example 8-1 show ip rsvp Commands (Continued)

Resv ID handle: 1A000413.
Status:
Policy: Accepted. Policy source(s): MPLS/TE

brussels#show ip rsvp sender detail

PATH:
Tun Dest: 10.200.254.5 Tun ID: 1 Ext Tun ID: 10.200.254.2
Tun Sender: 10.200.254.2 LSP ID: 5846
Path refreshes:
arriving: from PHOP 10.200.210.1 on PO10/2 every 30000 msecs
sent: to NHOP 10.200.211.2 on POS10/3
Session Attr:
Setup Prio: 7, Holding Prio: 7
Flags: (0x7) Local Prot desired, Label Recording, SE Style
Session Name: paris_t1
ERO: (incoming)
10.200.210.2 (Strict IPv4 Prefix, 8 bytes, /32)
10.200.211.2 (Strict IPv4 Prefix, 8 bytes, /32)
10.200.254.5 (Strict IPv4 Prefix, 8 bytes, /32)
ERO: (outgoing)
10.200.211.2 (Strict IPv4 Prefix, 8 bytes, /32)
10.200.254.5 (Strict IPv4 Prefix, 8 bytes, /32)
RRO:
10.200.210.1/32, Flags:0x0 (No Local Protection)
Traffic params - Rate: 100M 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: Tu1000 (label 0)
Bkup Sender Template:
Tun Sender: 10.200.212.1 LSP ID: 5846
Bkup FilerSpec:
Tun Sender: 10.200.212.1, LSP ID: 5846
Path ID handle: 45000406.
Incoming policy: Accepted. Policy source(s): MPLS/TE
Status:
Output on POS10/3. Policy status: Forwarding. Handle: F5000415

Path Option Selection with Bandwidth Override

You configure the bandwidth that a TE tunnel requires with the tunnel mpls traffic-eng
bandwidth command. This can be overridden by specifying a bandwidth on a specific path option.
When the TE label switched path (LSP) is signaled by that specific path option, the bandwidth that
is associated with the path option is signaled, not the configured bandwidth with the command
1974_chp8ONLba.fm Page 706 Tuesday, November 14, 2006 9:58 AM

Bandwidth Protection on Backup Tunnels 706

tunnel mpls traffic-eng bandwidth. This can be handy when you are configuring several path
options for a TE tunnel, when you know that each path has a specific maximum bandwidth.
Alternatively, you can use it for several path options, with a decreasing bandwidth requirement for
each path option, because the TE LSP did not successfully signal with the previous path option
because of the lack of bandwidth. Example 8-2 shows a demonstration
of this.

Example 8-2 Path Option Selection with Bandwidth Override

!
interface Tunnel1
ip unnumbered Loopback0
tunnel destination 10.200.254.7
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 550000
tunnel mpls traffic-eng path-option 10 explicit name london-rome
tunnel mpls traffic-eng path-option 20 explicit name london-rome-2 bandwidth 250000
tunnel mpls traffic-eng path-option 30 dynamic bandwidth 150000
tunnel mpls traffic-eng path-option 40 dynamic bandwidth 0

This tunnel first tries to establish an LSP with a bandwidth of 550 Mbps by using the path option
10. If this fails, the tunnel tries path-option 20. This path option specifies a bandwidth requirement
of only 250 Mbps for the tunnel. If this fails, too, the tunnel tries the dynamic path option 30, with
a bandwidth of 150 Mbps. Finally, if this fails, the tunnel tries a dynamic path option without
reserving bandwidth.

Bandwidth Protection on Backup Tunnels

You can assign a bandwidth requirement to backup tunnels. You might deploy this in a typical
scenario in which you have voice traffic that needs a guaranteed service. When the point of local
repair (PLR) assigns the TE LSP to the backup tunnel, it checks whether the bandwidth of the
backup tunnel is sufficient for the reroutable TE LSP. The command to assign bandwidth to the
backup tunnel is tunnel mpls traffic-eng backup-bw. You can either assign the required
bandwidth or configure unlimited. Unlimited indicates that the backup tunnel can carry all and
every LSP, because it virtually has unlimited bandwidth. The PLR tries to optimize when
assigning TE LSPs to backup tunnels to optimize the protected bandwidth, but it selects next-next-
hop (NNHOP) backup tunnels before next-hop (NHOP) backup tunnels. When the PLR assigns
TE LSPs to backup tunnels, it might want to check that the current choice of assigning a TE LSP
to a backup tunnel is still the best choice. The condition for a change might be the bandwidth
change of the backup tunnel or the appearance or disappearance of backup tunnels. The PLR can
perform this check immediately if the event is the appearance or disappearance of a backup tunnel,
1974_chp8ONLba.fm Page 707 Tuesday, November 14, 2006 9:58 AM

707 Chapter 8: MPLS Traffic Engineering

or the PLR can perform it periodically. A TE LSP that is being assigned to a new backup tunnel is
called promotion. By default, the periodic check is every 5 minutes, but you can change it with the
command mpls traffic-eng fast-reroute timers promotion.

When the tunnel has the command tunnel mpls traffic-eng backup-bw, it has a higher priority
than tunnels without bandwidth protection. This tunnel can then preempt these other tunnels. It is
said that these other tunnels are demoted. By default, Cisco IOS minimizes the number of demoted
TE LSPs to provide enough bandwidth. You can change this by configuring mpls traffic-eng fast-
reroute backup-prot-preemption optimize-bw on the routers. The behavior then minimizes the
amount of wasted bandwidth when demoting the TE LSPs. In the first behavior, larger TE LSPs
are demoted, and more bandwidth is wasted. In the latter behavior, more and smaller TE LSPs are
demoted. The backup tunnel indicates that bandwidth protection is desired by setting the
bandwidth protection desired flag in the SESSION_ATTRIBUTE object.

Auto Tunnels
LSRs can automatically create auto tunnels. Therefore, you do not have to configure them, and
they do not show up in the configuration of the router. However, the path calculation and the
signaling of the TE LSPs are no different from regular TE tunnels. These auto tunnels have the
following characteristics:

■ 0 bandwidth

■ Setup and holding priority of 7

■ Affinity bits 0x0/0xFFFF

You can see the created auto tunnels with the command show mpls traffic-eng tunnels brief.

Backup Auto Tunnels

The sections on fast rerouting for link and node protection must have made it clear to you that to
protect the TE LSPs completely, you must configure several backup tunnels. This is a tedious task,
and it is easy to make errors. That is why backup auto tunnels are created automatically for TE
tunnels that have fast rerouting enabled. Both NHOP and NNHOP backup auto tunnels are created
to protect links and nodes. The backup auto tunnels are created as soon as the following occurs:

■ The first RSVP RESV message is seen.

■ A PATH message requesting protection for an established TE LSP is seen.

■ The RRO changes.

1974_chp8ONLba.fm Page 708 Tuesday, November 14, 2006 9:58 AM

Auto Tunnels 708

Look at Figure 8-1. Assuming that backup auto tunnels is only enabled on the router brussels and
one TE tunnel is set up from the router brussels to the router rome, brussels creates one NHOP and
NNHOP backup auto tunnel, protecting the link brussels-berlin and the node berlin. Example 8-3
shows an example of these two backup auto tunnels. To enable backup auto tunnels, configure the
global command mpls traffic-eng auto-tunnel backup.

Figure 8-1 Backup Auto Tunnels Example

NNHOP Backup Tunnel

NHOP Backup Tunnel

10.200.212.2
Loopback 0
10.200.254.5/32
frankfurt 10.20 Loopback 0
0.214
POS 10/1 .2 10.200.254.6/32

10.200.210.2 POS 10/3 10.200.211.2 10.200.215.2 10.200.202.2

paris brussels berlin rome sydney

Example 8-3 Example of Backup Auto Tunnels

mpls traffic-eng auto-tunnel backup

brussels#show mpls traffic-eng tunnels brief

Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
auto-tunnel:
backup Enabled (2 ), id-range:65436-65535
onehop Disabled (0 ), id-range:65336-65435
mesh Disabled (0 ), id-range:64336-65335

Periodic reoptimization: every 3600 seconds, next in 3371 seconds

Periodic FRR Promotion: Not Running
Periodic auto-tunnel:
backup notinuse scan: every 3600 seconds, next in 2940 seconds
Periodic auto-bw collection: disabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
brussels_t1 10.200.254.6 - PO10/3 up/up
brussels_t1000 10.200.254.5 - unknown admin-down
brussels_t2000 10.200.254.6 - unknown admin-down
brussels_t65436 10.200.254.5 - PO10/1 up/up
brussels_t65437 10.200.254.6 - PO10/1 up/up
Displayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tails
continues
1974_chp8ONLba.fm Page 709 Tuesday, November 14, 2006 9:58 AM

709 Chapter 8: MPLS Traffic Engineering

Example 8-3 Example of Backup Auto Tunnels (Continued)

show mpls traffic-eng tunn els tunnel 65436
brussels#s

Name: brussels_t65436 (Tunnel65436) Destination: 10.200.254.5

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

path option 1, type explicit __dynamic_tunnel65436 (Basis for Setup, path weight 11)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -
OutLabel : POS10/1, 25
RSVP Signalling Info:
Src 10.200.254.3, Dst 10.200.254.5, Tun_Id 65436, Tun_Instance 1
RSVP Path Info:
My Address: 10.200.254.3
Explicit Route: 10.200.212.2 10.200.213.2 10.200.254.5
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 1 (TE)
Explicit Route: 10.200.211.2 10.200.254.5
History:
Tunnel:
Time since created: 11 minutes, 24 seconds
Time since path change: 11 minutes, 25 seconds
Current LSP:
Uptime: 11 minutes, 25 seconds

By default, high tunnel numbers (65,436 to 65,535) are chosen for the backup auto tunnels. If you
wish, you can change the range for the backup auto tunnels with the command mpls traffic-eng
auto-tunnel backup tunnel-num min num max num.

For every link that at least one TE tunnel crosses with fast rerouting enabled, an NHOP backup
auto tunnel is created to protect the link. For every node that at least one TE tunnel crosses with
fast rerouting enabled, an NNHOP backup auto tunnel is created to protect the node. You can
specify that you want only NHOP backup auto tunnels to be created with the command mpls
1974_chp8ONLba.fm Page 710 Tuesday, November 14, 2006 9:58 AM

Auto Tunnels 710

traffic-eng auto-tunnel backup nhop-only. That way, backup auto tunnels do not provide FRR
node protection.

Backup auto tunnels do not have autoroute announce enabled. This ensures that they are used only
for link or node protection and do not attract traffic.

Primary Auto Tunnels

Primary auto tunnels are one-hop-only tunnels that the LSR creates automatically for each link
where MPLS TE is enabled. These tunnels have autoroute announce enabled, so they attract IP
traffic. Because these are one-hop tunnels, the outgoing label is always implicit NULL. No label
is imposed upon the traffic that is forwarded into the tunnel. The global command to enable
primary auto tunnels is mpls traffic-eng auto-tunnel primary onehop. Because these tunnels are
one-hop only, they map exactly to the link. As such, the routing is no different from when these
primary tunnels are not there. Primary auto tunnels request FRR protection. Therefore, when
primary auto tunnels are combined with backup auto tunnels, the primary auto tunnels are
protected by NHOP backup auto tunnels, providing FRR link protection. Example 8-4 shows
primary auto tunnels. Because two outgoing links (pos 10/1 and pos 10/3) are enabled for MPLS
TE, there are two primary auto tunnels. Because backup auto tunnels is also enabled, there is one
backup auto tunnel for each primary auto tunnel.

Example 8-4 Primary Auto Tunnels

mpls traffic-eng auto-tunn el backup
mpls traffic-eng auto-tunnel primary oneh op

show mpls traffic-eng tunn els brief

brussels#s
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
auto-tunnel:
backup Enabled (3 ), id-range:65436-65535
onehop Enabled (2 ), id-range:65336-65435
mesh Disabled (0 ), id-range:64336-65335

Periodic reoptimization: every 3600 seconds, next in 1086 seconds

Periodic FRR Promotion: Not Running
Periodic auto-tunnel:
primary establish scan: every 10 seconds, next in 9 seconds
primary rm active scan: disabled
backup notinuse scan: every 3600 seconds, next in 1678 seconds
Periodic auto-bw collection: disabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
brussels_t1 10.200.254.6 - PO10/1 up/up
brussels_t1000 10.200.254.5 - unknown admin-down
continues
1974_chp8ONLba.fm Page 711 Tuesday, November 14, 2006 9:58 AM

711 Chapter 8: MPLS Traffic Engineering

Example 8-4 Primary Auto Tunnels (Continued)

brussels_t2000 10.200.254.6 - unknown admin-down
brussels_t65336 10.200.254.5 - PO10/3 up/up
brussels_t65337 10.200.254.4 - PO10/1 up/up
brussels_t65436 10.200.254.4 - PO10/3 up/up
brussels_t65437 10.200.254.5 - PO10/1 up/up
brussels_t65438 10.200.254.6 - PO10/3 up/up
Displayed 8 (of 8) heads, 0 (of 0) midpoints, 0 (of 0) tails

Example 8-5 shows that the primary auto tunnel 65336 has autoroute announce on and that the
backup auto tunnel 65437 protects it. Notice that the outgoing label is implicit NULL for the
primary auto tunnel.

Example 8-5 Protection of Primary Auto Tunnel

show mpls traffic-eng tunn els tunnel 65336
brussels#s

Name: brussels_t65336 (Tunnel65336) Destination: 10.200.254.5

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

path option 1, type explicit __dynamic_tunnel65336 (Basis for Setup, path weight 1)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -
OutLabel : POS10/3, implicit-null
RSVP Signalling Info:
Src 10.200.254.3, Dst 10.200.254.5, Tun_Id 65336, Tun_Instance 1
RSVP Path Info:
My Address: 10.200.254.3
Explicit Route: 10.200.211.2 10.200.254.5
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: 10.200.211.2(0)
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 1 (TE)
Explicit Route: 10.200.211.2 10.200.254.5
History:
Tunnel:
1974_chp8ONLba.fm Page 712 Tuesday, November 14, 2006 9:58 AM

Auto Tunnel Mesh Groups 712

Example 8-5 Protection of Primary Auto Tunnel (Continued)

Time since created: 1 minutes, 17 seconds
Time since path change: 1 minutes, 17 seconds
Current LSP:
Uptime: 1 minutes, 17 seconds

show mpls traffic-eng tunn els tunnel 65336 protection

brussels#s
brussels_t65336
LSP Head, Tunnel65336, Admin: up, Oper: up
Src 10.200.254.3, Dest 10.200.254.5, Instance 1
Fast Reroute Protection: Requested
Outbound: FRR Ready
Backup Tu65437 to LSP nhop
Tu65437: out i/f: PO10/1, label: 25
LSP signalling info:
Original: out i/f: PO10/3, label: implicit-null, nhop: 10.200.211.2
With FRR: out i/f: Tu65437, label: implicit-null
LSP bw: 0 kbps, Backup level: any-unlim, type: any pool

By default, high numbers (65,336 to 65,435) are chosen for the primary auto tunnels. If you want
to, you can change the range for the primary auto tunnels with the command mpls traffic-eng
auto-tunnel primary tunnel-num min num max num.

Because primary auto tunnels are one-hop tunnels, only NHOP backup tunnels, not NNHOP
backup tunnels, can protect them.

Auto Tunnel Mesh Groups

The feature Auto Tunnel Mesh Groups makes it possible to build a mesh of TE tunnels between
LSRs, with minimal configuration. LSRs are configured to be part of a mesh group by means of
an access list. The TE tunnels are not created individually, but an auto-template interface is
created. All TE tunnels that are part of the mesh group inherent their features from this template.
(This means they are cloned from the template interface.) The great benefit of this feature is that
when a new LSR is configured to be part of this mesh, you do not need to configure TE tunnels to
all the other LSRs, which are part of the mesh. The TE tunnels are created automatically as they
are cloned from the template interface. To make an LSR member of a mesh group, you must
perform the following three steps:

■ Enable auto tunnel mesh groups.

■ Create an access list.

■ Create the auto-template.

1974_chp8ONLba.fm Page 713 Tuesday, November 14, 2006 9:58 AM

713 Chapter 8: MPLS Traffic Engineering

You must globally enable mesh groups with the command mpls traffic-eng auto-tunnel mesh.
The access list is a standard access list, indicating MPLS TE router IDs (tunnel destination IP
addresses) of LSRs that are part of the mesh group. The router must try to establish auto tunnels
to the LSRs for which their MPLS TE router ID matches the access list. The auto-template
interface is an interface that you must configure on the router and assign the TE features of
bandwidth, affinity, and so on to. After the TE tunnels are created, their characteristics are cloned
from this interface. Example 8-6 shows a mesh group. The brussels, paris, and london routers are
part of an auto tunnel mesh group. Each router is the head end of two TE tunnels, one toward each
other router in the mesh group.

Example 8-6 Auto Tunnel Mesh Group

mpls traffic-eng auto-tunn el mesh
!
interfac e Auto-Template1
ip unnum bered Loopback0
tunnel de stination access-list 99
t unnel mode mpls traffic-e ng
tunnel mpls traffic-en g autoroute announce
tunn el mpls traffic-eng path-o ption 1 dynamic
!
access-li st 99 permit 10.200.254.0 0.0.0.3

show mpls traffic-eng tunn els brief

paris#s
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
auto-tunnel:
backup Disabled (0 ), id-range:65436-65535
onehop Disabled (0 ), id-range:65336-65435
mesh Enabled (2 ), id-range:64336-65335

Periodic reoptimization: every 3600 seconds, next in 3291 seconds

Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 291 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
paris_t64336 10.200.254.1 - Et1/1 up/up
paris_t64337 10.200.254.3 - PO4/0 up/up
london_t64336 10.200.254.2 Et1/1 - up/up
london_t64337 10.200.254.3 Et1/1 PO4/0 up/up
brussels_t64336 10.200.254.1 PO4/0 Et1/1 up/up
brussels_t64337 10.200.254.2 PO4/0 - up/up
Displayed 2 (of 2) heads, 2 (of 2) midpoints, 2 (of 2) tails

show mpls traffic-eng auto -tunnel mesh

paris#s
1974_chp8ONLba.fm Page 714 Tuesday, November 14, 2006 9:58 AM

Automatic
Automatic Bandwidth
Bandwidth Adjustment for
Adjustment for TE Tunnels 714
TE Tunnels

Example 8-6 Auto Tunnel Mesh Group (Continued)

Auto-Template1:

Using access-list 99 to clone the following tunnel interfaces:

Destination Interface
----------- ---------

10.200.254.1 Tunnel64336
10.200.254.3 Tunnel64337

Mesh tunnel interface numbers: min 64336 max 65335

By default, high numbers (64,336 to 65,335) are chosen for the mesh group auto tunnels. If you
wish, you can change the range for the mesh group auto tunnels with the command mpls traffic-
eng auto-tunnel mesh tunnel-num min num max num.

Automatic Bandwidth Adjustment for TE Tunnels

The required bandwidth for a TE tunnel is 0, or a value you configure on the tunnel head end
router. You can also let Cisco IOS decide dynamically what the required bandwidth of the tunnel
is. This is done by letting the head end router sample the average output load of the TE tunnel
during a period of time. The command to configure this on the TE tunnel interface is as follows:

mpls traffic-eng auto-bw [c

Router(config)#m collect-bw] [f
frequency sec] [m
max-bw n][m
m in -
bw n]

The default interval is 300 seconds, or 5 minutes. You can change it by configuring a different
frequency. To limit the range of bandwidth, you can specify a minimum and maximum amount of
bandwidth in kilobits per seconds to apply to the tunnel. The collect-bw keyword enables you to
specify that the average output rate should be collected without having Cisco IOS actually
changing the bandwidth of the TE tunnel. You can run the TE tunnels like this for days or weeks
before letting the head end routers change the bandwidth automatically. Example 8-7 shows a TE
tunnel where bandwidth adjustment is enabled. Note that the configuration on the TE tunnel
interface (the mpls traffic-eng bandwidth command) changes to reflect the actual bandwidth
reserved. This change is in the running configuration, but not in startup configuration.

Example 8-7 Configuration of Automatic Bandwidth Adjustment

!
interface Tunnel1
ip unnu mbered Loopback0
tunnel d estination 10.200.254.5
t unnel mode mpls traffic-e ng
tunnel mpls traffic-eng autoroute announce
1974_chp8ONLba.fm Page 715 Tuesday, November 14, 2006 9:58 AM

715 Chapter 8: MPLS Traffic Engineering

Example 8-7 Configuration of Automatic Bandwidth Adjustment

tunnel mpls traffic-eng bandwidth 435
tunnel mpls traffic-eng path-option 1 explicit name paris-rome
tunnel mpls traffic-eng fast-reroute
tunnel mpls traffic-eng auto-bw frequency 30

show mpls traffic-eng tunn els tunnel 1

paris#s

Name: paris_t1 (Tunnel1) Destination: 10.200.254.5

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit paris-rome (Basis for Setup, path weight 2)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 435 bw-based
auto-bw: (30/144) 0 Bandwidth Requested: 435
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

show mpls traffic-eng link -management admission-con trol pos 10/3

brussels#s
System Information::
Tunnels Count: 3
Tunnels Selected: 1
TUNNEL ID UP IF DOWN IF PRIORITY STATE BW (kbps)
10.200.254.2 1_805 PO10/2 PO10/3 7/7 Resv Admitted 435 RG

NOTE The traffic is not policed if the rate of the traffic that is going into the tunnel is higher
than the signaled bandwidth of the tunnel. This is true for an automatic bandwidth adjusted
tunnel and for any other TE tunnel.

DiffServ-Aware TE
The TE tunnels that have been discussed so far are also called global pool TE tunnels. Sub-pool
tunnels are another kind. Sub-pool tunnels are differentiated from global pool TE tunnels in the
fact that the traffic they carry requires a stricter quality of service. This traffic is such that, for
example, it needs a strict delay or jitter along the total path or requires that no more than 20 percent
of the link bandwidth carries this traffic to ensure the correct level of quality of service (QoS) on
1974_chp8ONLba.fm Page 716 Tuesday, November 14, 2006 9:58 AM

DiffServ-Aware TE 716

the links. This 20 percent is then the sub-pool of the global pool of bandwidth that is reservable
on a link. This traffic might be voice traffic or leased line traffic with specific QoS requirements.
You might have TE-enabled links that do not meet this QoS requirement and are therefore not
entitled to carry sub-pool tunnels even though they can still carry global pool tunnels.

Because the sub-pool tunnels can be routed in a different way from the global pool tunnels, they
can guarantee a particular QoS level. However, because the traffic needing this QoS requirement
is routed into a special sub-pool tunnel, it can inherit a particular DiffServ value. The Experimental
(EXP) bits in the labels of the traffic that is going into the sub-pool versus the global pool tunnels
can be set differently on the head end routers. You can use policy-based routing or Modular QoS
Command Line Interface (MQC) to perform this task. Then you can use the EXP bits value on the
routers to provide the proper QoS treatment on every link. For example, you can ensure that the
sub-pool TE traffic uses one particular DiffServ queue that no other traffic does. To recap: The
proper usage of sub-pool tunnels entails the following:

■ The traffic that is requiring the guaranteed QoS treatment is steered into the sub-pool tunnels
at the head end router.

■ The EXP bits are set to a particular value for the traffic using the sub-pool tunnels.

■ The sub-pool bandwidth values are set to a relative small value of the total bandwidth value
on the links.

By default, the interfaces that are enabled for MPLS TE and used for global pool tunnels have
reservable bandwidth advertised only for the global pool tunnels. You must use the ip rsvp
bandwidth command with the sub-pool keyword on the TE-enabled links to advertise bandwidth
for sub-pool tunnels:

ip rsvp bandwidth kbps [s

sub-pool kpbs]

To configure the TE tunnel to be a sub-pool tunnel instead of a global pool tunnel, you must
configure the following command on the tunnel interface and specify the required bandwidth in
kbps:

tunnel mpls traffic-eng bandwidth sub-pool bandwidth

For a global pool tunnel, you can specify 0 as the required bandwidth. For a sub-pool tunnel, the
required bandwidth must be something other than 0.
1974_chp8ONLba.fm Page 717 Tuesday, November 14, 2006 9:58 AM

717 Chapter 8: MPLS Traffic Engineering

Example 8-8 shows how to configure a bandwidth of 10000 kpbs for sub-pool tunnels on an
interface. The IGP then advertises this available sub-pool bandwidth.

Example 8-8 Configuring Bandwidth for Sub-Pool Tunnels

int pos 4/0
paris(config)#i
ip rsvp bandwidth 155000 s ub-pool 10000
paris(config-if)#i

show mpls traffic-eng link -management interfaces po s 4/0

paris#s
System Information::
Links Count: 2
Link ID:: PO4/0 (10.200.210.1)
Link Status:
SRLGs: None
Physical Bandwidth: 155000 kbits/sec
Max Res Global BW: 155000 kbits/sec (reserved: 0% in, 0% out)
Max Res Sub BW: 10000 kbits/sec (reserved: 0% in, 0% out)
MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded
Inbound Admission: allow-all
Outbound Admission: allow-if-room
Admin. Weight: 1 (IGP)
IGP Neighbor Count: 1
IGP Neighbor: ID 10.200.254.3, IP 10.200.210.2 (Up)
Flooding Status for each configured area [1]:
IGP Area[1]: ospf 1 area 0: flooded

Example 8-9 shows the tunnel configuration for a sub-pool tunnel.

Example 8-9 Configuring a Sub-Pool Tunnel

show running-config interf ace tunnel 1
paris#s
!
interface Tu nnel1
ip unnumbered Loop back0
tunnel destination 1 0.200.254.5
tunnel mode mp ls traffic-eng
tunnel mpl s traffic-eng autoroute a nnounce
tunnel mpls traff ic-eng priority 7 7
tunnel mpls traffic-eng bandwid th sub-pool 1000
tunnel m pls traffic-eng path-opti on 1 explicit name paris-r ome
tunnel mpls traffic-e ng fast-reroute
!

show mpls traffic-eng tunn els tunnel 1

paris#s

Name: paris_t1 (Tunnel1) Destination: 10.200.254.5

Status:
Admin: up Oper: up Path: valid Signalling: connected
1974_chp8ONLba.fm Page 718 Tuesday, November 14, 2006 9:58 AM

Interarea TE 718

Example 8-9 Configuring a Sub-Pool Tunnel (Continued)

path option 1, type explicit paris-rome (Basis for Setup, path weight 2)

Config Parameters:
Bandwidth: 1000 kbps (Sub) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 1000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

NOTE For more information on QoS with MPLS, refer to Chapter 12, “MPLS and Quality of
Service.”

Interarea TE
Up until now, all TE tunnels discussed here have been TE tunnels in one area of a link state routing
protocol. The reason is that routers have only the complete picture of the area they are in, because
a link state routing protocol has a link state database per area. A router in an area does not have
the complete view of the network outside of that area.

So far, the path option for a TE tunnel has been either a dynamic one or a complete explicit path,
where all the hops of the TE tunnel had to be specified. Also available was a semi-dynamic TE
tunnel path option whereby you could use an explicit path and exclude certain IP addresses. One
more possibility exists. This fourth possibility, loose next hops, will be used for interarea TE.
Loose next hops are specified as loose next-addresses in an explicit path option. An explicit path
option with loose next hops is a list of IP addresses of LSRs that the TE tunnel must cross.
However, the list does not need to be the complete list of all the LSRs that the TE tunnel will cross.
The list of LSRs is only the LSRs that the TE tunnel must cross. The missing LSRs in between can
be any LSRs that the head end router finds to be on a feasible path toward the loose next hop in
the list.

The solution to build a TE tunnel that can span multiple areas is to specify the area border routers
(ABRs) as loose next hops in the explicit path. The head end router of the TE tunnel must
dynamically build a path to the first ABR that is specified in the explicit path. This path becomes
the explicit route object (ERO) carried in the RSVP Path messages. That ABR must expand the
loose route from itself to the next ABR that is specified in the explicit path, and so on. Therefore,
the ABR turns a loose route into an explicit one. When areas have multiple ABRs between them,
you can specify different path options with different loose next hops so that you can have backup
paths in case one ABR fails. However, you have one big disadvantage of using an interarea TE
tunnel. Because the head end router does not have the TE database of the other areas, it cannot
1974_chp8ONLba.fm Page 719 Tuesday, November 14, 2006 9:58 AM

719 Chapter 8: MPLS Traffic Engineering

deduce which prefixes are behind the tail end router, if the tail end router is in another area than
the head end router. Therefore, autoroute announce is not supported on interarea TE tunnels. Other
features that are not supported on interarea tunnels are setting of the affinity bits on the tunnel,
forwarding adjacency, and reoptimization. These limits are the result of the inability of the head
end router to look inside other areas. The TE features of the links are advertised only inside an
area.

To configure an interarea TE tunnel, you must specify the IP addresses of the ABRs in the explicit
path as a loose next hop with the following command:

next-address loose A.B.C.D.

Router(cfg-ip-expl-path)#n

Figure 8-2 shows an example of an interarea TE tunnel in an OSPF domain with three areas.

Figure 8-2 Interarea TE Tunnel

Area 1

Loopback 0 Loopback 0 Loopback 0

10.200.254.1 10.200.254.2 10.200.254.3

ABR
10.200.200.1 10.200.210.1

london paris 10.200.212.1 brussels

Loopback 0
10.200.254.4

TE Tunnel 1

10.200.213.1 frankfurt

Loopback 0 Loopback 0 Loopback 0

10.200.254.7 10.200.254.6 10.200.254.5

ABR
10.200.202.2 10.200.215.2 10.200.215.1

sydney rome berlin

Area 2 Area 0
1974_chp8ONLba.fm Page 720 Tuesday, November 14, 2006 9:58 AM

Interarea TE 720

The TE tunnel head end router is router london in area 1, and the tail end router is router sydney
in area 2. The two area border routers are brussels and berlin. These two ABRs are configured as
loose next hops in the explicit path for the interarea TE tunnel. It is the task of router london to
calculate a path to the ABR brussels, and it is the task of router brussels to calculate a path in OSPF
area 0 to the ABR berlin. Finally, the router berlin must calculate a path in area 2 toward the tail
end router sydney. Example 8-10 shows the configuration of this interarea TE tunnel on router
london.

Example 8-10 Interarea Tunnel

!
interface Tunnel1
ip unnu mbered Loopback0
tunnel d estination 10.200.254.7
t unnel mode mpls traffic-e ng
tunnel mpls traffic-eng path-option 10 explicit name inter-area
!
ip expli cit-path name inter-area e nable
next-address loose 1 0.200.254.3
next-address loose 10.200.254.5
!
show mpls traffic-eng tunn el tunnel 1
london#s

Name: london_t1 (Tunnel1) Destination: 10.200.254.7

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit inter-area (Basis for Setup, path weight 21)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -
OutLabel : Ethernet0/0/0, 35
RSVP Signalling Info:
Src 10.200.254.1, Dst 10.200.254.7, Tun_Id 1, Tun_Instance 18
RSVP Path Info:
My Address: 10.200.200.1
Explicit Route: 10.200.200.2 10.200.210.2 10.200.254.3 10.200.254.5*
Record Route:
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: 10.200.210.1 10.200.212.1 10.200.213.1 10.200.215.1
1974_chp8ONLba.fm Page 721 Tuesday, November 14, 2006 9:58 AM

721 Chapter 8: MPLS Traffic Engineering

Example 8-10 Interarea Tunnel (Continued)

10.200.202.2 10.200.202.1
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: UNKNOWN
Explicit Route: UNKNOWN
History:
Tunnel:
Time since created: 15 minutes, 10 seconds
Time since path change: 1 minutes, 28 seconds
Current LSP:
Uptime: 1 minutes, 29 seconds
Selection: reoptimization
Prior LSP:
ID: path option 10 [16]
Removal Trigger: label reservation removed

Notice that the Shortest Unconstrained Path Info cannot show anything because the TE database
is missing a piece of the topology for the complete path of this tunnel. The ERO is the path up to
the first ABR. The next loose hop is indicated by the star next to the IP address. You can see the
complete path that the TE tunnel takes by looking at the Record Route section in the output.

You can also use a verbatim TE tunnel (see the next section) if the TE tunnel spans multiple IGP
areas. With verbatim, the TE topology database verification is completely omitted at the head end
router. RSVP is used to signal the LSP and the path must then be completely specified as an
explicit path.

Verbatim
Verbatim is an option for an explicit TE tunnel LSP whereby the tunnel head end router bypasses
the TE topology database verification before signaling the TE LSP via RSVP. This is useful when
some TE nodes do not support the TE IGP extensions, but they do support RSVP with the TE
extensions. Because the TE topology database is not verified, the verbatim option cannot be used
for dynamic TE tunnels, but only for TE tunnels that have the explicitly routed path option.
Example 8-11 shows an example of a verbatim TE tunnel.

Example 8-11 Verbatim Tunnel

!
interface Tunnel1
ip unnu mbered Loopback0
tunnel d estination 10.200.254.5
t unnel mode mpls traffic-e ng
1974_chp8ONLba.fm Page 722 Tuesday, November 14, 2006 9:58 AM

MPLS
MPLS TE LSP
TE LPS Attributes 722
ATTRIBUTES

Example 8-11 Verbatim Tunnel (Continued)

tunnel mpls traffic-eng a utoroute announce
tunnel mpls traffic-eng path-opt ion 1 explicit name paris -rome verbatim
tunnel mpls traffic-eng fast-reroute

show mpls traffic-eng tunn els tunnel 1

paris#s

Name: paris_t1 (Tunnel1) Destination: 10.200.254.5

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type explicit (verbatim) paris-rome (Basis for Setup, path weight 0)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: enabled

InLabel : -
OutLabel : POS4/0, 17
RSVP Signalling Info:
Src 10.200.254.2, Dst 10.200.254.5, Tun_Id 1, Tun_Instance 5799
RSVP Path Info:
My Address: 10.200.254.2
Explicit Route: 10.200.210.2 10.200.211.2
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: 10.200.211.1(17) 10.200.211.2(0)
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: UNKNOWN
Explicit Route: UNKNOWN

MPLS TE LSP Attributes

You can assign LSP attributes to a TE tunnel per path option. Therefore, depending on the path
that the TE tunnel takes, the attributes of the TE LSP (hence, the TE tunnel) can change. The
attributes that the path option assigns take precedence over any configured attributes on the tunnel
interface.
1974_chp8ONLba.fm Page 723 Tuesday, November 14, 2006 9:58 AM

723 Chapter 8: MPLS Traffic Engineering

Example 8-12 demonstrates the usage of LSP attributes. Two path options are configured for
tunnel 1, each with a set of attributes. In addition, you can see which attributes you can use.

Example 8-12 LSP Attributes

!
interface Tunnel1
ip unnu mbered Loopback0
tunnel d estination 10.200.254.6
t unnel mode mpls traffic-e ng
tunnel mpls traffic-eng autoroute announce
tunne l mpls traffic-eng path-o ption 1 dynamic attribute s attributes-1
tunnel mpls traffic-eng path-option 2 explicit name paris-rom e attributes attributes-2
!
mpls traffic-eng lsp attr ibutes attributes-1
auto- bw
protection fast-rerout e
lockdown
!
mpls traffic-e ng lsp attributes attribut es-2
bandwidth 500000
rec ord-route
!
mpls traffic-eng lsp attri butes attributes-1
paris(config)#m
?
paris(config-lsp-attr)#?
Attribute List configuration commands:
affinity Specify attribute flags for links comprising LSP
auto-bw Specify automatic bandwidth configuration
bandwidth Specify LSP bandwidth
exit Exit from attribute list configuration mode
list Re-list all of the attribute list entries
lockdown Lockdown the LSP--disable reoptimization
no Disable a specific attribute
priority Specify LSP priority
protection Enable failure protection
record-route Record the route used by the LSP

Path Protection
The protection schemes covered so far (link and node protection) are local. Recently, a global
protection scheme was added to MPLS TE: Path Protection. In MPLS TE Path Protection, one TE
LSP backs up another. This backup or protection TE LSP is established in advance by the same
head end LSR to back up the primary TE LSP. As soon as the head end knows that there is failure
along the path of the primary TE LSP, it switches the traffic onto the backup TE LSP. The head
end is aware of a failure along the path when it receives a PathErr from an LSR along the primary
TE LSP. The further away the failure from the head end LSR, the longer it takes for the PathErr to
reach the head end LSR. This means that the switchover from primary to backup TE LSP on the
head end LSR is a bit slower than the local switchover that happens with link or node protection.
1974_chp8ONLba.fm Page 724 Tuesday, November 14, 2006 9:58 AM

Path Protection 724

It is, however, still faster than rerouting the primary TE LSP onto another path. That is because
this involves resignaling the LSP, whereas with path protection, the backup TE LSP is already
established at the time of the failure.

Each path option of a TE tunnel can be backed up by a protection LSP. The configuration needed
is a path option with the protect keyword. Look at Figure 8-3 to see an example of path protection.

Figure 8-3 Path Protection Example

TE Tunnel 1
Backup LSP

10.200.212.2
Loopback 0
10.200.254.5/32
frankfurt 10.20 Loopback 0
0.214
POS 10/1 .2 10.200.254.6/32

POS 10/3 10.200.211.2 10.200.215.2 10.200.202.2

brussels berlin rome sydney

TE Tunnel 1
Primary LSP

The tunnel 1 has one primary and one backup LSP. Example 8-13 shows the tunnel configuration
for Figure 8-3.

Example 8-13 Path Protection

!
interface Tunnel1
ip unnu mbered Loopback0
tunnel d estination 10.200.254.7
t unnel mode mpls traffic-e ng
tunnel mpls traffic-en g autoroute announce
tunne l mpls traffic-eng path-o ption 10 explicit name to -sydney
tunnel mpls traffi c-eng path-option protect 10 explicit name to-sydn ey-backup
!

!
ip explicit-pa th name to-sydney enable
n ext-address 10.200.211.2
next-address 10.200.215.2
next-address 10.200.202.2
!
ip explicit-path name to-sydney-backup enable
continues
1974_chp8ONLba.fm Page 725 Tuesday, November 14, 2006 9:58 AM

725 Chapter 8: MPLS Traffic Engineering

Example 8-13 Path Protection (Continued)

next-address 10.200.212.2
next-address 10.200.214.2
next-address 10.200.202.2
!

show mpls traffic-eng tunn els tunnel 1

brussels#s

Name: brussels_t1 (Tunnel1) Destination: 10.200.254.7

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit to-sydney (Basis for Setup, path weight 3)
Path Protection: 1 Common Link(s) , 1 Common Node(s)
path protect option 10, type explicit to-sydney-backup (Basis for Protect, path
weight 3)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -
OutLabel : Serial3/0, 32
RSVP Signalling Info:
Src 10.100.254.3, Dst 10.200.254.7, Tun_Id 1, Tun_Instance 36
RSVP Path Info:
My Address: 10.100.254.3
Explicit Route: 10.200.211.2 10.200.215.2 10.200.202.2 10.200.254.7
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 3 (TE)
Explicit Route: 10.200.212.2 10.200.214.2 10.200.202.2 10.200.254.7

show mpls traffic-eng tun nels tunnel 1 protection

brussels#s
brussels_t1
LSP Head, Tunnel1, Admin: up, Oper: up
Src 10.100.254.3, Dest 10.200.254.7, Instance 36
Fast Reroute Protection: None
Path Protection: 1 Common Link(s) , 1 Common Node(s)
Primary lsp path:10.200.211.2 10.200.215.2
1974_chp8ONLba.fm Page 726 Tuesday, November 14, 2006 9:58 AM

Troubleshooting MPLS TE 726

Example 8-13 Path Protection (Continued)

10.200.202.2 10.200.254.7

Protect lsp path:10.200.212.2 10.200.214.2

10.200.202.2 10.200.254.7

Path Protect Parameters:

Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
InLabel : -
OutLabel : Serial2/0, 32
RSVP Signalling Info:
Src 10.100.254.3, Dst 10.200.254.7, Tun_Id 1, Tun_Instance 42
RSVP Path Info:
My Address: 10.100.254.3
Explicit Route: 10.200.212.2 10.200.214.2 10.200.202.2 10.200.254.7
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits

Cisco IOS does not make sure that the primary TE LSP and backup TE LSP are diverse when using
dynamaic path options. Both LSPs might share many links or nodes, which defeats the purpose of
path protection. Therefore, you must make sure that the paths of the primary TE LSP and backup
TE LSP are diverse, or as diverse as possible. You do this by configuring an explicit path option
for both the primary TE LSP and the backup TE LSP. The command show mpls traffic-eng
tunnels tunnel-interface [brief] protection shows the number of common links and nodes
between the primary and backup TE LSPs.

Troubleshooting MPLS TE
The most frequent problem with MPLS TE is a tunnel that is not set up. The tunnel interface does
not come up if the TE tunnel LSP is not set up. That is easy enough to notice. But why does the
TE tunnel not come up? Much can already be seen by looking at the tunnel with the command
show mpls traffic-eng tunnel tunnel tunnel-number. Other common troubleshooting techniques
involve looking at the TE database and enabling debug ip rsvp signaling and debug mpls traffic-
eng path spf.
1974_chp8ONLba.fm Page 727 Tuesday, November 14, 2006 9:58 AM

727 Chapter 8: MPLS Traffic Engineering

Example 8-14 shows a tunnel that is down. The TE tunnel is the tunnel 1 on the router paris, with
the router rome being the tail end of the TE LSP. The path option of the tunnel only specifies to
exclude the router berlin from the path CSPF calculation.

Example 8-14 Troubleshooting MPLS TE Tunnel Path

paris#
!
interface Tunnel1
ip unnu mbered Loopback0
tunnel d estination 10.200.254.6
t unnel mode mpls traffic-e ng
tunnel mpls traffic-eng autoroute announce
tunn el mpls traffic-eng prior ity 7 7
tunnel mpls traffi c-eng bandwidth 155000
tu nnel mpls traffic-eng pat h-option 10 explicit name not-router-berlin
!
ip exp licit-path name not-router -berlin enable
exclude-ad dress 10.200.254.5
!

show mpls traffic-eng tunn els tunnel 1

paris#s

Name: paris_t1 (Tunnel1) Destination: 10.200.254.6

Status:
Admin: up Oper: down Path: not valid Signalling: Down
path option 10, type explicit not-router-berlin

Config Parameters:
Bandwidth: 155000 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 155000 bw-based
auto-bw: disabled

Shortest Unconstrained Path Info:

Path Weight: 4 (TE)
Explicit Route: 10.200.210.2 10.200.211.2 10.200.215.2 10.200.254.6
History:
Tunnel:
Time since created: 1 days, 51 minutes
Time since path change: 51 seconds
Prior LSP:
ID: path option 10 [676]
Removal Trigger: path error
Last Error: PCALC:: No path to destination, 10.200.254.6
1974_chp8ONLba.fm Page 728 Tuesday, November 14, 2006 9:58 AM

Troubleshooting MPLS TE 728

The debug in Example 8-15 tells you that the reservable bandwidth on LSR brussels
(10.200.254.3) is too small.

Example 8-15 Troubleshooting MPLS TE Tunnel Path

debug mpls traffic-eng pat h spf
paris#d
MPLS traffic-eng path calculation spf events debugging is on
paris#
*Apr 5 02:47:27.749: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding 10.200.254.5
*Apr 5 02:47:27.749: TE-PCALC_SPF: 10.200.254.2 aw 0 min_bw 18446744073709551615,
prev_node(NULL)
*Apr 5 02:47:27.749: TE-PCALC_SPF: 10.200.254.2
*Apr 5 02:47:27.749: TE-PCALC_SPF: REJECT(max_bw too small) node 10.200.254.2,
ip_address 10.200.200.2 bw 10000
*Apr 5 02:47:27.749: TE-PCALC_SPF: 10.200.254.3 aw 2 min_bw 155000,
prev_node(10.200.254.2)
*Apr 5 02:47:27.749: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list:
*Apr 5 02:47:27.749: node(62)=(aw=2, min_bw=155000, hops=1)
*Apr 5 02:47:27.753: TE-PCALC_SPF: 10.200.254.3
*Apr 5 02:47:27.753: TE-PCALC_SPF: REJECT(bw available too small)

After you correct that problem by specifying the correct bandwidth with the ip rsvp bandwidth
155000 command on interface pos 10/1 on router brussels, you can see the next problem in
Example 8-16. The attribute flags on the link with IP address 10.200.214.1 (router Frankfurt) do
not match with the affinity bits and mask that are configured on the TE tunnel.

Example 8-16 Troubleshooting MPLS TE Tunnel Path

brussels(config-if)#
int pos 10/1
brussels(config-if)#i
ip rsvp bandwidth 155000
brussels(config-if)#i
paris#

*Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_node_exclude: excluding 10.200.254.5

*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.2 aw 0 min_bw 18446744073709551615,
prev_node(NULL)
*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.2
*Apr 5 02:48:21.893: TE-PCALC_SPF: REJECT(max_bw too small) node 10.200.254.2,
ip_address 10.200.200.2 bw 10000
*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.3 aw 2 min_bw 155000,
prev_node(10.200.254.2)
*Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list:
*Apr 5 02:48:21.893: node(62)=(aw=2, min_bw=155000, hops=1)
*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.3
*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.4 aw 3 min_bw 155000,
prev_node(10.200.254.3)
1974_chp8ONLba.fm Page 729 Tuesday, November 14, 2006 9:58 AM

729 Chapter 8: MPLS Traffic Engineering

Example 8-16 Troubleshooting MPLS TE Tunnel Path (Continued)

*Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list:
*Apr 5 02:48:21.893: node(64)=(aw=3, min_bw=155000, hops=2)
*Apr 5 02:48:21.893: TE-PCALC_SPF: 10.200.254.4
*Apr 5 02:48:21.893: TE-PCALC_SPF: REJ(no attribute flags) node 10.200.254.4, ip_address
10.200.214.1

*Apr 5 02:48:21.893: tunnel_affinity_bits 0x0,

*Apr 5 02:48:21.893: tunnel_affinity_mask 0xFFFF,
*Apr 5 02:48:21.893: link_attribute_flags 0xFFFF
*Apr 5 02:48:21.893: TE-PCALC_SPF: rrr_pcalc_dump_tentitive list:

After changing the affinity bits and mask on the TE tunnel to 0x00000000 and 0x00000000
respectively, the TE tunnel CSPF calculation succeeds and the TE tunnel is signaled, as you can
see in Example 8-17.

Example 8-17 Troubleshooting MPLS TE Tunnel Path

tunnel mpls traffic-eng af finity 0x00000000 mask 0x00000000
paris(config-if)#t

show mpls traffic-eng tunn els tunnel 1

paris#s

Name: paris_t1 (Tunnel1) Destination: 10.200.254.6

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type explicit not-router-berlin (Basis for Setup, path weight 4)

Config Parameters:
Bandwidth: 155000 kbps (Global) Priority: 7 7 Affinity: 0x0/0x0
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 155000 bw-based
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 10 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

InLabel : -
OutLabel : POS4/0, 25
RSVP Signalling Info:
Src 10.200.254.2, Dst 10.200.254.6, Tun_Id 1, Tun_Instance 715
RSVP Path Info:
My Address: 10.200.254.2
Explicit Route: 10.200.210.2 10.200.212.2 10.200.214.2 10.200.254.6
Record Route: NONE
1974_chp8ONLba.fm Page 730 Tuesday, November 14, 2006 9:58 AM

Troubleshooting MPLS TE 730

Example 8-17 Troubleshooting MPLS TE Tunnel Path (Continued)

Tspec: ave rate=155000 kbits, burst=1000 bytes, peak rate=155000 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=155000 kbits, burst=1000 bytes, peak rate=155000 kbits
Shortest Unconstrained Path Info:
Path Weight: 4 (TE)
Explicit Route: 10.200.210.2 10.200.212.2 10.200.214.2 10.200.254.6
1974_chp9ONLa.fm Page 731 Tuesday, November 14, 2006 10:06 AM
1974_chp9ONLa.fm Page 732 Tuesday, November 14, 2006 10:06 AM

SUPPLEMENT
CHAPTER 9
IPv6 over MPLS

This online supplement of Chapter 9 gives you a brief overview of how to deploy 6VPE across
more than one autonomous system that is running MPLS. You can deploy 6VPE over multiple
autonomous systems in the same way as described in Chapter 7, “MPLS VPN”: Inter-
Autonomous MPLS VPN or Carrier’s Carrier.

Inter-Autonomous Systems 6VPE

Spanning the 6VPE solution across multiple autonomous systems is specified in RFC 4364. You
can use three methods that are discussed in Chapter 7 to provide inter-as support for 6VPE:

■ Virtual routing/forwarding (VRF)-to-VRF connections between autonomous system (AS)

border routers

■ MP-eBGP exchanging vpnv6 prefixes + label between AS border routers

■ MP-eBGP exchanging vpnv6 prefixes + label between PE routers or route reflectors (RR)
and exchanging IPv4 prefixes + label for the PE IPv4/32 prefixes

In the first option, you can have AS border routers (ASBR) from different autonomous systems
exchange the IPv6 prefixes directly over VRF interfaces. The two ASBRs must have one link in
common between them for each VPN for which they are exchanging prefixes. These links can
be (sub)interfaces with vrf forwarding configured on them. The packets that cross the links
between the two ASBRs are unlabeled IPv6 packets. The second option is to have ASBRs from
different autonomous systems exchange vpnv6 prefixes and labels. The packets that cross the
links between the ASBRs are labeled packets. The third option is to have the vpnv6 prefixes and
labels exchanged between PE routers or RRs from different autonomous systems. However, a
labeled IPv4 path needs to exist between the PE routers or RRs from the different autonomous
systems. Therefore, an IPv4 prefixes + label exchange must take place between the ASBRs for
the PE IPv4/32 prefixes. These PE IPv4/32 prefixes + label can be advertised via MP-eBGP or
via an Interior Gateway Protocol (IGP) and Label Distribution Protocol (LDP). If the RRs from
different autonomous systems exchange the vpnv6 prefixes, they must leave the BGP next-hop
field unchanged.
1974_chp9ONLa.fm Page 733 Tuesday, November 14, 2006 10:06 AM

733 Chapter 9: IPv6 over MPLS

Carrier’s Carrier Through 6VPE

Because LDP for IPv6 is not available, Carrier’s Carrier (CsC) for IPv6 is a bit different from CsC
for IPv4. You learned from Chapter 7 that CsC involves sending labeled packets over a VRF
interface of the PE router. The same is true for CsC for IPv6. Two scenarios are possible for
transporting IPv6 with a CsC solution:

■ 6VPE over IPv4 MPLS network

■ CsC network is MPLS VPN for IPv4

In the first scenario, 6VPE over IPv4 MPLS network, you have a regular 6VPE network running
over an IPv4 MPLS backbone. The IPv6 packets switched between the PE and CE routers are now
labeled. Because LDP for IPv6 is not available, the only option is to run MP-eBGP for IPv6 + label
between the PE and CE routers. You do this by configuring the send-label keyword for the eBGP
neighbor on the PE and CE router. Figure 9-1 shows the CsC 6VPE over IPv4 MPLS network
scenario in a schematic form.

Figure 9-1 6VPE over IPv4 MPLS Network

MP-iBGP for vpnv6 + Label

VPN Red VPN Red

MPLS for IPv4
MP-eBGP for IPv6 MP-eBGP for IPv6
+ Label + Label

CsC-PE CsC-PE
Site 1

Site 2
VRF VRF

IPv4 MPLS Backbone

The second scenario, CsC network is MPLS VPN for IPv4, is a regular CsC MPLS VPN for the
IPv4 network, meaning that the CsC is running MPLS VPN for IPv4 with IPv4 prefixes + label
exchange between the CsC PE and the carrier’s CE routers. The carrier network is running MPLS
IPv4 end to end in its network and has 6VPE configured on the PEs only. The PE IPv4/32 prefixes
are the prefixes from the carrier’s network that must be labeled. On the PE routers of the carrier’s
network is MP-eBGP for IPv6 + label configured toward the CE routers to carry the customer
prefixes. Figure 9-2 shows the second scenario in a schematic form.
1974_chp9ONLa.fm Page 734 Tuesday, November 14, 2006 10:06 AM

Carrier’s Carrier Through 6VPE 734

Figure 9-2 CsC Network Is MPLS VPN for IPv4

MP-iBGP for vpnv6 + Label

MPLS VPN for IPv4

MP-eBGP for IPv4 + Label IPv4 + Label MP-eBGP for

IPv6 + Label IPv6 + Label

VPN Red VPN Red

CE PE CsC-PE CsC-PE PE CE
VRF VRF VRF VRF

Carrier Network Site 1 Carrier Network Site 2

MPLS VPN for IPv4 Network
Customer Customer
Network Network
Carrier’s Carrier Network
Site 1 Site 1

NOTE To better understand the operation of CsC, refer to the section “Carrier’s Carrier” in
Chapter 7.