supplemental content chp7

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


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

CHAPTER
SUPPLEMENT

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
VRF

Green
VRF
MPLS VPN

MPLS VPN

Green VRF
Red VRF

CE
Red
VRF

CE

Blue VRF

PE

PE
PE-ASBR
Autonomous
System 1

PE-ASBR

Red
VRF

Autonomous
System 2

CE

CE

Blue
VRF

Blue
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
VPNv4 + Label

iBGP for
VPNv4 + Label

eBGP for
VPNv4 + Label

MPLS VPN

CE
Red
VRF

PE

MPLS VPN

ASBR
Autonomous
System 1

ASBR

PE
Autonomous
System 2

CE
Red
VRF

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

IPv4 Packet

VPN Label

VPN Label

VPN Label

IPv4 Packet

IPv4 Packet

IPv4 Packet

MPLS VPN

CE
Red
VRF

PE

MPLS VPN

ASBR
Autonomous
System 1

IPv4 Packet

ASBR

PE
Autonomous
System 2

CE
Red
VRF

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 InterAutonomous 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
VPNv4 + Label

eBGP for
VPNv4 + Label

MPLS VPN
CE
Red
VRF

PE

ASBR
Autonomous
System 1

RCVD VPNv4 RD:X --- DENIED Due To
Extended Community Not Supported

iBGP for
VPNv4 + Label

MPLS VPN

ASBR
Autonomous
System 2

PE

CE
Red
VRF


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
VPNv4 + Label

eBGP for
VPNv4 + Label

MPLS VPN

CE
Red
VRF

PE

iBGP for
VPNv4 + Label

MPLS VPN

ASBR
Autonomous
System 1

ASBR
x.x.x.x

Autonomous
System 2

PE

CE
Red

VRF

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

Figure 7-6

674

Multihop eBGP Distribution of vpnv4 Prefixes and Label

RR

CE

4+

iBG

eBGP For IPv4 +
Label

Nv
VP
l
or
P f Labe

RR

+ Next -hop-unchanged

iBG

Pf
or
La VPN
be
v4
l
+

Multihop eBGP For
VPNv4 + Label

PE

ASBR

ASBR

PE

Red VRF

CE
Red VRF

MPLS VPN
Autonomous System 1

MPLS VPN
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.
Multihop eBGP Distribution of vpnv4 Prefixes and Label with iBGP for IPv4 and Label

Multihop eBGP For
VPNv4 + Label

+ Next-hop-unchanged

eBGP For IPv4 +
Label

RR

iBG

4+

PE

CE

Nv
VP
l
or
P f Labe

RR

iBG

Pf
or
La VPN
be
v4
l
+

Figure 7-7

ASBR

ASBR

PE

Red VRF

CE

Red VRF

iBGP For IPv4 +
Label

MPLS VPN
Autonomous System 1

iBGP For IPv4 +
Label

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

IPv4 Packet

IGP Label

eBGP Label

IGP Label

VPN Label

VPN Label

VPN Label

IPv4 Packet

IPv4 Packet

IPv4 Packet

RR

RR

CE

PE

IPv4 Packet

ASBR

ASBR

PE

Red VRF

CE
Red VRF

MPLS VPN
Autonomous System 1

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

IPv4 Packet

IGP Label

eBGP Label

iBGP Label

VPN Label

VPN Label

VPN Label

IPv4 Packet

IPv4 Packet

IPv4 Packet

RR

RR

CE

PE

IPv4 Packet

ASBR

ASBR

PE

Red VRF

CE
Red VRF

MPLS VPN

Autonomous System 1

MPLS VPN
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 +
Label

eBGP for IPv4 +
Label

+ Next-hop-unchanged

CE

+

iBG

ASBR

4
IPv
or
P f abel
L

ASBR

iBG

Pf
o
La r IPv
be 4 +
l

Multihop eBGP For
VPNv4 + Label

PE

RR

RR

PE

Red VRF

CE
Red VRF

iBGP for VPNv4 +
Label

MPLS VPN
Autonomous System 1

iBGP for VPNv4 +
Label

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

iBGP Label

MPLS
Autonomous System 3

VPN Label

ASBR

ASBR
IPv4 Packet

eBGP Label

eBGP Label

VPN Label

VPN Label

IPv4 Packet

IPv4 Packet

IGP Label

IGP Label

iBGP Label

VPN Label

VPN Label

ASBR

ASBR

IPv4 Packet

IPv4 Packet

PE

CE

RR

RR

PE

Red VRF
IPv4 Packet

CE
Red VRF

MPLS VPN
Autonomous System 1

MPLS VPN
Autonomous System 2

IPv4 Packet

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.
Multihop eBGP Session for vpnv4 Prefixes and Label Between ASBRs

Figure 7-12

eBGP Multihop For
VPNv4 + Label

MPLS VPN

Loopback 0
10.10.100.1/32

PE
ASBR
london-ASBR-1

Loopback 0
10.10.100.3/32

Eth 1/2
10.10.90.2

Eth 1
10.10.90.1

10.10.91.2
Eth 1/1

10.10.91.1
Eth 0

PE
ASBR
sydney-ASBR-1

Autonomous
System 65001

Example 7-4

MPLS VPN

Autonomous
System 2

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

Example 7-4

682

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

RT Rewrite

Figure 7-13

iBGP for
VPNv4 + Label

eBGP for
VPNv4 + Label

MPLS VPN

PE

ASBR
sydney-as-1
10.10.100.1/32
RT 1:1

MPLS VPN

Rewrite RT
1:1 to RT 2:1
10.10.100.1/32
RT 2:1

Autonomous
System 1

Example 7-6

iBGP for
VPNv4 + Label

ASBR
sydney-as-2

PE

10.10.100.1/32
RT 2:1

Autonomous
System 2

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

Figure 7-14

686

Overview of CsC

Carrier’s Carrier (CSC)
MPLS VPN Network
MPLS
CSC-PE

CSC-PE

CSC-CE

CSC-CE

Carrier 1
Site A

Carrier 1
Site B

BGP

ASBR

Customer 1
Site A

ASBR

Customer 2
Site A

Customer 1
Site B

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