1974 chp7ONLa

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

C

H

A

P

T

E

R

S

U

P

P

L

E

M

E

N

T

7

This online supplement of Chapter 7 focuses on two important MPLS VPN developments. The
rst 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
Carriers 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 prexes with an MPLS label.

BGP Advertising IPv4 Prexes with a Label

In Cisco IOS, BGP advertises labels by default for vpnv4 prexes 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 congure 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

!!! !
rrr rooo ouuu uttt teee errr r bbb bggg gppp p 111 1
bbb bggg gppp p lll looo oggg g--- -nnn neee eiii iggg ghhh hbbb booo orrr r--- -ccc chhh haaa annn nggg geee esss s
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .222 2000 0000 0... .222 2555 5444 4... .222 2 rrr reee emmm mooo ottt teee e--- -aaa asss s 111 1
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .222 2000 0000 0... .222 2555 5444 4... .222 2 uuu uppp pddd daaa attt teee e--- -sss sooo ouuu urrr rccc ceee e LLL Looo oooo oppp pbbb baaa accc ckkk k000 0
!!! !
aaa addd dddd drrr reee esss ssss s--- -fff faaa ammm miii illl lyyy y iii ippp pvvv v444 4
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .222 2000 0000 0... .222 2555 5444 4... .222 2 aaa accc cttt tiii ivvv vaaa attt teee e
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .222 2000 0000 0... .222 2555 5444 4... .222 2 sss seee ennn nddd d--- -lll laaa abbb beee elll l
nnn nooo o aaa auuu uttt tooo o--- -sss suuu ummm mmmm maaa arrr ryyy y
nnn nooo o sss syyy ynnn nccc chhh hrrr rooo onnn niii izzz zaaa attt tiii iooo onnn n
eee exxx xiii ittt t--- -aaa addd dddd drrr reee esss ssss s--- -fff faaa ammm miii illl lyyy y
!!! !

MPLS VPN

1974_chp7ONLa.fm Page 666 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 lter 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 lter when redistributing the IGP into BGP. However, if you
deploy the ltering on the eBGP session outbound with a route map, you must ensure that the label
that is associated with the prex is also sent. When you are deploying an outbound route map on
an eBGP neighbor and you allow certain prexes through, these prexes do not have a label by
default. For the label to be advertised along with the prex when the conditions are matched in an
outbound route map, use the

set mpls-label

command in the route map. Otherwise, the prex
might get through, but without the associated label. Look at Example 7-2. The idea is to only
advertise the prex 10.10.100.3/32. The

set mpls-label

command in the route map ensures that
the prex 10.10.100.3/32 is sent with an MPLS label.
When advertising IPv4 prexes with a label, BGP by default sends an implicit NULL label for
directly connected prexes. 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, congure

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

Example 7-2

BGP

neighbor

Command with Outbound Route Map

!!! !
rrr rooo ouuu uttt teee errr r bbb bggg gppp p 666 6555 5000 0000 0222 2
nnn nooo o sss syyy ynnn nccc chhh hrrr rooo onnn niii izzz zaaa attt tiii iooo onnn n
bbb bggg gppp p lll looo oggg g--- -nnn neee eiii iggg ghhh hbbb booo orrr r--- -ccc chhh haaa annn nggg geee esss s
nnn neee ettt twww wooo orrr rkkk k 111 1000 0... .111 1000 0... .111 1000 0000 0... .333 3 mmm maaa asss skkk k 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .111 1000 0... .444 4... .111 1 rrr reee emmm mooo ottt teee e--- -aaa asss s 111 1
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .111 1000 0... .444 4... .111 1 rrr rooo ouuu uttt teee e--- -mmm maaa appp p lll laaa abbb beee elll l ooo ouuu uttt t
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .111 1000 0... .444 4... .111 1 sss seee ennn nddd d--- -lll laaa abbb beee elll l
nnn nooo o aaa auuu uttt tooo o--- -sss suuu ummm mmmm maaa arrr ryyy y
!!! !
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1 ppp peee errr rmmm miii ittt t 111 1000 0... .111 1000 0... .111 1000 0000 0... .333 3
rrr rooo ouuu uttt teee e--- -mmm maaa appp p lll laaa abbb beee elll l ppp peee errr rmmm miii ittt t 111 1000 0
mmm maaa attt tccc chhh h iii ippp p aaa addd dddd drrr reee esss ssss s 111 1
sss seee ettt t mmm mppp plll lsss s--- -lll laaa abbb beee elll l
!!! !



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.

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

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.
MPLS VPN
Autonomous
System 2
PE PE
PE-ASBR PE-ASBR
Green
VRF
CE
Red
VRF
CE
Blue
VRF
CE
MPLS VPN
Autonomous
System 1
Green VRF
Red VRF
Blue VRF
Green
VRF
CE
Red
VRF
CE
Blue
VRF
CE


669

Chapter 7: MPLS VPN

Because the interfaces between the two ASBRs are VRF interfaces, the trafc between the ASBRs
is plain, unlabeled IP trafc. 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 reectors (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

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 rst AS to the
egress PE router in the second AS. That is why the vpnv4 routes are exchanged with labels on the
ASBR PE
Autonomous
System 1
MPLS VPN
PE ASBR
Autonomous
System 2
MPLS VPN
eBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
Red
VRF
CE
Red
VRF
CE



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

congured 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 congure the

send-label

keyword on the eBGP neighbor command for the ASBR. You just need
to congure 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

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 prexes 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
ASBR PE
Autonomous
System 1
MPLS VPN
PE ASBR
Autonomous
System 2
MPLS VPN
Red
VRF
CE
Red
VRF
CE
IPv4 Packet IPv4 Packet
VPN Label
IGP Label
IPv4 Packet
VPN Label
IPv4 Packet
VPN Label
IGP Label
IPv4 Packet


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 prex when no attached VRF is importing the vpnv4 prex.
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 conguring

no bgp default route-target lter

on the ASBR. As soon as you
congure 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

Example 7-3

Denying a vpnv4 Route

sydney#

ddd deee ebbb buuu uggg g iii ippp p bbb bggg gppp p vvv vppp pnnn nvvv v444 4 uuu unnn niii iccc caaa asss sttt t uuu uppp pddd daaa attt teee esss s iii innn n

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;
ASBR PE
Autonomous
System 1
MPLS VPN
PE ASBR
Autonomous
System 2
MPLS VPN
eBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
iBGP For
VPNv4 + Label
Red
VRF
CE
Red
VRF
CE
RCVD VPNv4 RD:X --- DENIED Due To
Extended Community Not Supported
No Red VRF Attached
To This ASBR



672

VRF interfaces are allowed on the ASBR, but they are not needed. You need to congure a specic
VRF when the ASBR is also a PE router for a specic 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
congured. Figure 7-5 shows the generation of this /32 route.

Figure 7-5

Generation of eBGP Peer Neighbor 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 congure

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.
ASBR PE
Autonomous
System 1
MPLS VPN
PE ASBR
Autonomous
System 2
MPLS VPN
eBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
Red
VRF
CE
Red
VRF
CE
x.x.x.x
Generates a
x.x.x.x./32 Route


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 prexes 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 prexes. 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 prexes that represent the PE routers (the BGP next hops) to the other autonomous
system with a label. The /32 IPv4 prex 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 prexes 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 prexes comes in handy here. BGP has proven to be
successful and scalable for interdomain routing.
The ASBRs exchange the /32 IPv4 PE loopback prexes 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 prexes to all the PE routers in the local AS. To achieve
this, advertise the /32 IPv4 prexes to the IGP of the local AS. To limit the redistribution from
eBGP into the IGP to the /32 IPv4 PE loopback prexes, congure route maps on the ASBRs.
Figure 7-6 shows a schematic overview of the solution, where the IPv4 /32 PE prexes are
redistributed from IGP into eBGP and vice versa on the ASBRs.



674

Figure 7-6

Multihop eBGP Distribution of vpnv4 Prexes and Label

Another way to get the /32 IPv4 PE loopback prexes to all the PE routers is to advertise the /32
IPv4 PE loopback prexes (and a label) via iBGP. This means that iBGP must send IPv4 prexes
with a label. The advertisement of these prexes and the label via iBGP is most likely the preferred
way of getting the IPv4 prexes from another AS into your own AS. Advertising external prexes
into your AS via BGP is much more acceptable than advertising them into your own IGP.
ASBR
RR
ASBR PE PE
CE
Red VRF
CE
Red VRF
MPLS VPN
Autonomous System 1
RR
MPLS VPN
Autonomous System 2
Redistribution of /32 IPv4 PE
Loopback Prefixes From eBGP
Into IGP and Vice Versa
i
B
G
P

f
o
r

V
P
N
v
4

+
L
a
b
e
l
i
B
G
P

f
o
r

V
P
N
v
4

+
L
a
b
e
l
eBGP For IPv4 +
Label
Multihop eBGP For
VPNv4 + Label
+ Next -hop-unchanged


675

Chapter 7: MPLS VPN

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

Figure 7-7

Multihop eBGP Distribution of vpnv4 Prexes and Label with iBGP for IPv4 and Label

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

send-label

keyword on the BGP
neighbor command. The rst two features do not need it, because BGP enables advertising of the
label by default for vpnv4 routes.
ASBR
RR
ASBR PE PE
CE
Red VRF
CE
Red VRF
MPLS VPN
Autonomous System 1
RR
MPLS VPN
Autonomous System 2
i
B
G
P

f
o
r

V
P
N
v
4

+
L
a
b
e
l
i
B
G
P

f
o
r

V
P
N
v
4

+
L
a
b
e
l
eBGP For IPv4 +
Label
Multihop eBGP For
VPNv4 + Label
iBGP For IPv4 +
Label
iBGP For IPv4 +
Label
+ Next-hop-unchanged



676

Note, too, that the RRs have an eBGP session between them to exchange the vpnv4 prexes. By
defaultas usual for external BGPthe RRs set the next hop of the vpnv4 prexes to themselves.
That means the RRs assign a label to the vpnv4 routes, and all inter-autonomous trafc passes
through them. RRs are usually routers that have the specic function of reecting routes and not
forwarding trafc. To prevent the RRs from setting the next hop to themselves, congure the
keyword

next-hop-unchanged

on the route reectors 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 prexes will be the originating PE router.
Figure 7-8 shows the packet forwarding in the solution where the /32 IPv4 prexes of the PE
routers are redistributed into the IGP of the other AS.

Figure 7-8

Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prexes and Label

The top labeleither the IGP label or the eBGP assigned labelis always the label that is bound
to the /32 prex of the egress PE router. You can see that the packets have two labels at all times.
ASBR
RR
ASBR PE PE
VPN Label
eBGP Label
IPv4 Packet
VPN Label
IGP Label
IPv4 Packet
VPN Label
IGP Label
IPv4 Packet IPv4 Packet IPv4 Packet
CE
Red VRF
CE
Red VRF
RR
MPLS VPN
Autonomous System 1
MPLS VPN
Autonomous System 2


677

Chapter 7: MPLS VPN

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

Figure 7-9

Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prexes and Label with iBGP for
IPv4 and Label

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 prexes 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 prexes
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.
ASBR
RR
ASBR PE PE
VPN Label
eBGP Label
IPv4 Packet
VPN Label
iBGP Label
IGP Label
IPv4 Packet
VPN Label
IGP Label
IPv4 Packet IPv4 Packet IPv4 Packet
CE
Red VRF
CE
Red VRF
RR
MPLS VPN
Autonomous System 1
MPLS VPN
Autonomous System 2



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 prexes advertised into the remote autonomous system (preferably
carried by iBGP and not by the IGP)
Again, the /32 IPv4 PE loopback prexes 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 Prexes and Label Through an MPLS Network
RR
ASBR
RR PE PE
CE
Red VRF
CE
Red VRF
MPLS VPN
Autonomous System 1
MPLS
Autonomous System 3
ASBR
ASBR ASBR
MPLS VPN
Autonomous System 2
i
B
G
P

f
o
r

I
P
v
4

+
L
a
b
e
l
i
B
G
P

f
o
r

I
P
v
4

+
L
a
b
e
l
eBGP for IPv4 +
Label
eBGP for IPv4 +
Label
Multihop eBGP For
VPNv4 + Label
iBGP For IPv4 +
Label
iBGP for VPNv4 +
Label
iBGP for VPNv4 +
Label
+ Next-hop-unchanged


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 Prexes and Label Through an
MPLS Network

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 prexes 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 trafc 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
RR
ASBR
RR PE PE
CE
Red VRF
CE
Red VRF
MPLS VPN
Autonomous System 1
MPLS
Autonomous System 3
ASBR
ASBR ASBR
MPLS VPN
Autonomous System 2
VPN Label
eBGP Label
IPv4 Packet
VPN Label
eBGP Label
IPv4 Packet
VPN Label
iBGP Label
IGP Label
IPv4 Packet
VPN Label
IGP Label
IPv4 Packet
VPN Label
iBGP Label
IGP Label
IPv4 Packet



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 congure static routes for the remote loopback IP address. You
must congure one such static route per link between the ASBRs, because you want to use each
link to forward trafc on. The eBGP multihop session can be for vpnv4 prexes and label or for
IPv4 prexes 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 prexes and label. You can nd the conguration for this
in Example 7-4. To make it work, congure

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 Prexes and Label Between ASBRs
Example 7-4 Conguration 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
!
PE PE
ASBR ASBR
sydney-ASBR-1 london-ASBR-1
MPLS VPN
Autonomous
System 65001
MPLS VPN
Autonomous
System 2
Eth 1/2
10.10.90.2
10.10.91.2
Eth 1/1
Eth 1
10.10.90.1
10.10.91.1
Eth 0
Loopback 0
10.10.100.1/32
Loopback 0
10.10.100.3/32
eBGP Multihop For
VPNv4 + Label
continues
681 Chapter 7: MPLS VPN
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 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
!
Example 7-4 Conguration for Nondirectly Connected eBGP Peers (Continued)
Inter-Autonomous MPLS VPN 682
continues
Example 7-5 shows that BGP is the label advertising protocol on the interfaces between the two
ASBRs. The VRF cust-one prex 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.
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
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 Verifying Nondirectly Connected eBGP Peers
sydney-asbr-1#sss shhh hooo owww w mmm mppp plll lsss s iii innn nttt teee errr rfff faaa accc ceee esss s ddd deee ettt taaa aiii illl l
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:
MPLS operational
Fast Switching Vectors:
IP to MPLS Fast Switching Vector
MPLS Turbo Vector
MTU = 1500
london-asbr-1#sss shhh hooo owww w iii ippp p bbb bggg gppp p vvv vppp pnnn nvvv v444 4 rrr rddd d 111 1::: :111 1 111 1000 0... .999 9999 9... .111 1... .222 2
BGP routing table entry for 1:1:10.99.1.2/32, version 89
Paths: (1 available, best #1, table cust-one)
Example 7-4 Conguration for Nondirectly Connected eBGP Peers (Continued)
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 congure 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 prex
is 2:1.
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
london-asbr-1#sss shhh hooo owww w iii ippp p ccc ceee efff f vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e 111 1000 0... .999 9999 9... .111 1... .222 2
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.
Example 7-5 Verifying Nondirectly Connected eBGP Peers (Continued)
Inter-Autonomous MPLS VPN 684
Figure 7-13 RT Rewrite
Example 7-6 RT Rewrite
!
hostname sydney-as-1
!
router bgp 1
!
neighbor 10.10.4.2 route-map to-as-2 out
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
!
ASBR
sydney-as-1
PE
Autonomous
System 1
10.10.100.1/32
RT 1:1
MPLS VPN
PE ASBR
sydney-as-2
Autonomous
System 2
MPLS VPN
10.10.100.1/32
RT 2:1
Rewrite RT
1:1 to RT 2:1
10.10.100.1/32
RT 2:1
eBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
continues
CsC
CsC is a solution involving a carrier (named the Carriers 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.
sydney-as-1#sss shhh hooo owww w iii ippp p bbb bggg gppp p vvv vppp pnnn nvvv v444 4 aaa alll llll l 111 1000 0... .111 1000 0... .111 1000 0000 0... .111 1
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
sydney-as-2#sss shhh hooo owww w iii ippp p bbb bggg gppp p vvv vppp pnnn nvvv v444 4 aaa alll llll l 111 1000 0... .111 1000 0... .111 1000 0000 0... .111 1
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
Example 7-6 RT Rewrite (Continued)
CsC 686
Figure 7-14 Overview of CsC
MPLS is extended to the customer edge (CE) router, which means a label distribution protocol is
needed between the PEacross the VRF interfaceand 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.
CSC-CE
Customer 1
Site A
ASBR
Customer 2
Site A
Customer 1
Site B
ASBR
Customer 2
Site B
Carrier 1
Site A
CSC-CE
CSC-PE CSC-PE
Carrier 1
Site B BGP
MPLS
Carriers Carrier (CSC)
MPLS VPN Network
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 carriers 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 benet 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 trafc to and from the CSC-CE router. The carriers are carrying
their customer prexes 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 trafc of the carriers is done based on the label that
is assigned to the BGP next-hop prexes. 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
prexes. 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
conguring 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
CsC 688
VRF keyword. Look at Example 7-7 for the output of the LDP commands when LDP is
congured on a VRF interface.
Example 7-7 Example of LDP Commands for CsC
!!! !
hhh hooo osss sttt tnnn naaa ammm meee e lll looo onnn nddd dooo onnn n
!!! !
iii innn nttt teee errr rfff faaa accc ceee e EEE Ettt thhh heee errr rnnn neee ettt t000 0/// /111 1/// /222 2
iii ippp p vvv vrrr rfff f fff fooo orrr rwww waaa arrr rddd diii innn nggg g ccc cuuu usss sttt t--- -ooo onnn neee e
iii ippp p aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1000 0... .222 2... .222 2 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
mmm mppp plll lsss s iii ippp p
!!! !
london#sss shhh hooo owww w mmm mppp plll lsss s lll lddd dppp p nnn neee eiii iggg ghhh hbbb booo orrr r vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e
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
london#sss shhh hooo owww w mmm mppp plll lsss s lll lddd dppp p bbb biii innn nddd diii innn nggg gsss s vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e
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
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
lib entry: 10.99.1.1/32, rev 6
lib entry: 192.168.1.0/24, rev 9
london#sss shhh hooo owww w mmm mppp plll lsss s lll lddd dppp p ddd diii isss sccc cooo ovvv veee errr ryyy y vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e
Local LDP Identifier:
10.99.1.1:0
Discovery Sources:
continues
eBGP Across the VRF Interface
If you choose eBGP for IPv4 and label distribution between the CSC-PE and CSC-CE, you must
congure 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 prex 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 prex 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.
Interfaces:
Ethernet0/1/2 (ldp): xmit/recv
LDP Id: 10.10.100.1:0
london#sss shhh hooo owww w mmm mppp plll lsss s iii innn nttt teee errr rfff faaa accc ceee esss s vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e ddd deee ettt taaa aiii illl l
VRF cust-one:
Interface Ethernet0/1/2:
IP labeling enabled (ldp)
BGP labeling not enabled
MPLS operational
MTU = 1500
Example 7-8 eBGP for IPv4 and Label on a VRF Interface
!!! !
hhh hooo osss sttt tnnn naaa ammm meee e lll looo onnn nddd dooo onnn n
!!! !
rrr rooo ouuu uttt teee errr r bbb bggg gppp p 111 1

!!! !
aaa addd dddd drrr reee esss ssss s--- -fff faaa ammm miii illl lyyy y iii ippp pvvv v444 4 vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e
rrr reee eddd diii isss sttt trrr riii ibbb buuu uttt teee e ccc cooo onnn nnnn neee eccc cttt teee eddd d
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .111 1000 0... .222 2... .111 1 rrr reee emmm mooo ottt teee e--- -aaa asss s 666 6555 5000 0000 0111 1
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .111 1000 0... .222 2... .111 1 aaa accc cttt tiii ivvv vaaa attt teee e
nnn neee eiii iggg ghhh hbbb booo orrr r 111 1000 0... .111 1000 0... .222 2... .111 1 sss seee ennn nddd d--- -lll laaa abbb beee elll l
eee exxx xiii ittt t--- -aaa addd dddd drrr reee esss ssss s--- -fff faaa ammm miii illl lyyy y
!!! !
london#sss shhh hooo owww w mmm mppp plll lsss s iii innn nttt teee errr rfff faaa accc ceee esss s vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e ddd deee ettt taaa aiii illl l
VRF cust-one:
Interface Ethernet0/1/2:
Example 7-7 Example of LDP Commands for CsC (Continued)
CsC 690
continues
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 labelsas
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 prex, 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 prexes. For
the VRF prex 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 prex 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 prex consists of two labels.
MPLS operational
MTU = 1500
london-ce#sss shhh hooo owww w iii ippp p bbb bggg gppp p 111 1000 0... .999 9999 9... .111 1... .222 2 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5
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
london#sss shhh hooo owww w mmm mppp plll lsss s fff fooo orrr rwww waaa arrr rddd diii innn nggg g--- -ttt taaa abbb blll leee e vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e 111 1000 0... .111 1000 0... .111 1000 0000 0... .111 1
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
Example 7-9 LFIB Entries on the CSC-PE
london#sss shhh hooo owww w mmm mppp plll lsss s fff fooo orrr rwww waaa arrr rddd diii innn nggg g--- -ttt taaa abbb blll leee e vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e
18 Pop Label 10.10.2.1/32[V] 0 Et0/1/2 10.10.2.1
Example 7-8 eBGP for IPv4 and Label on a VRF Interface (Continued)
Anti-Label Spoong 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 spoong packets with labels that are assigned to another customer, both
connected to the same service provider.
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

london#sss shhh hooo owww w mmm mppp plll lsss s fff fooo orrr rwww waaa arrr rddd diii innn nggg g--- -ttt taaa abbb blll leee e vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e 111 1000 0... .111 1000 0... .111 1000 0000 0... .111 1
45 Pop Label 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1
london-ce#sss shhh hooo owww w iii ippp p ccc ceee efff f 111 1000 0... .999 9999 9... .111 1... .222 2
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}
london#sss shhh hooo owww w mmm mppp plll lsss s fff fooo orrr rwww waaa arrr rddd diii innn nggg g--- -ttt taaa abbb blll leee e vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e 111 1000 0... .999 9999 9... .111 1... .222 2 ddd deee ettt taaa aiii illl l
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
Example 7-9 LFIB Entries on the CSC-PE (Continued)
CsC 692
CsC Scenarios
The possible CsC scenarios can be classied into three categories:
Only the CE routers run MPLS.
All carrier C routers run MPLS.
There is hierarchical MPLS VPN.
The rst 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 trafc. 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 trafc, 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
CsC
iBGP VPNv4 Routes + Label
iBGP VPNv4 Routes
iBGP iBGP
Carrier 1
Site A
ASBR
Carrier 1
Site B
ASBR
CSC-PE CSC-CE CSC-PE CSC-CE
MPLS
Carrier 1 IGP
Routes + Label
Carrier 1 IGP
Routes + Label
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
All Carrier C Routers Run MPLS
In this scenario, all the carrier C routers run MPLS. Therefore, the carrier C routers forward trafc
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 trafc 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 rst CsC scenario, in which all C routers were required to run BGP. Look at Figure 7-17
for the schematic overview of this scenario.
CsC
Carrier 1
iBGP
Site A
ASBR
Carrier 1
iBGP
Site B
ASBR
IGP Carrier 1
Label
IPv4 Packet
CSC VPN
Label
IGP CSC
Label
IPv4 Packet
IGP Carrier 1
Label
IPv4 Packet
CSC-CE CSC-PE CSC-PE CSC-CE
CsC 694
Figure 7-17 Schematic Overview of Information Exchange in the Second CsC Scenario
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
The difference between this and the rst scenario is that the packets in the carrier network are
labeled throughout the network.
CsC
iBGP IPv4 Routes
Carrier 1
Site A
ASBR
Carrier 1
Site B
ASBR
MPLS
Carrier 1 IGP
Routes + Label
Carrier 1 IGP
Routes + Label
CsC
Carrier 1
Site A
ASBR
Carrier 1
Site B
ASBR
IGP Carrier 1
Label
IGP Carrier 1
Label
IPv4 Packet
CSC VPN
Label
IGP CSC
Label
IPv4 Packet
IGP Carrier 1
Label
IGP Carrier 1
Label
IPv4 Packet
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
benet 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
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.
CsC
iBGP IPv4 Routes + Label
Carrier 1
Site A
ASBR
(PE)
Carrier 1
Site B
ASBR
(PE)
MPLS
Carrier 1 IGP
Routes + Label
Carrier 1 IGP
Routes + Label
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
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 conguration 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 trafc 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
CsC
Carrier 1
Site A
ASBR
(PE)
Carrier 1
Site B
ASBR
(PE)
Carrier 1
VPN Label
Carrier 1
VPN Label
IPv4 Packet
Carrier 1
VPN Label
CSC VPN
Label
IGP CSC
Label
IPv4 Packet
Carrier 1
VPN Label
Carrier 1
VPN Label
IGP Carrier 1
Label
IGP Carrier 1
Label
IGP Carrier 1
Label
IGP Carrier 1
Label
IPv4 Packet
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
The trafc from the three hosts on the broadband access network is policy-routed onto the
corresponding VRF interface of the PE router. The trafc 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 congured with VRF
selection, which enables the PE router to route the trafc 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.
AS 1
MPLS VPN
PE
PE
PE
PE
VRF
cust-one
CE
ISP 1
VRF
cust-two
CE
ISP 2
VRF
cust-three
CE
ISP 3
10.10.1.103
10.10.1.77
10.10.1.10
Policy-Based
Routing to VLAN
Interfaces
Broadband
Access
Network
CE
VLAN 10 VRF cust-one
VLAN 11 VRF cust-two
VLAN 12 VRF cust-three
Figure 7-22 VRF Selection
After the trafc is routed to the chosen VRF, it is forwarded according to the VRF routing table on
the PE router. The trafc is then forwarded as regular MPLS VPN trafc 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 trafc from the Internet (or the VRF sites) is forwarded according to the
global routing table in the MPLS VPN network. The trafc 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 trafc to
be forwarded back to this PE router where VRF Selection is enabled. Example 7-10 shows a
sample conguration for VRF Selection based on source IP address. The trafc from source IP
address 10.10.1.103 is forwarded into VRF cust-one, and the trafc 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
AS 1
MPLS VPN
PE
PE
PE
PE
VRF
cust-one
CE
ISP 1
VRF
cust-two
CE
ISP 2
VRF
cust-three
CE
ISP 3
10.10.1.103
10.10.1.77
10.10.1.10
VRF Selection
Broadband
Access
Network
Based On
Source IP
Address
VRFs is vrf selection source source-IP-address source-IP-mask vrf vrf_name. The command
show ip vrf select demonstrates the congured 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
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf cust-one
no auto-summary
no synchronization
exit-address-family
!
london#sss shhh hooo owww w iii ippp p vvv vrrr rfff f sss seee elll leee eccc cttt t
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
You can congure 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 trafc does not need to be routed back
to this PE router according to the global routing table, because the subnet prex is advertised as a
vpnv4 prex. 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.
Trafc 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 trafc if the source IP address
is spoofed. To prevent this, you can congure a VRF on the PE router to drop such trafc. To drop
this potentially malicious trafc, 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 congured on the PE router, which
serves as a bucket to drop packets with an unknown source IP address.
Example 7-11 Announcement of the Interface Subnet into the VRFs
!!! !
iii innn nttt teee errr rfff faaa accc ceee e EEE Ettt thhh heee errr rnnn neee ettt t000 0/// /111 1/// /222 2
iii ippp p vvv vrrr rfff f sss seee elll leee eccc cttt t sss sooo ouuu urrr rccc ceee e
iii ippp p vvv vrrr rfff f rrr reee eccc ceee eiii ivvv veee e ccc cuuu usss sttt t--- -ooo onnn neee e
iii ippp p vvv vrrr rfff f rrr reee eccc ceee eiii ivvv veee e ccc cuuu usss sttt t--- -ttt twww wooo o
iii ippp p aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1000 0... .111 1... .111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
!!! !
Example 7-12 Drop VRF for Unknown Source IP Addresses
!!! !
iii ippp p vvv vrrr rfff f ddd drrr rooo oppp p
rrr rddd d 999 9999 9999 9999 9::: :999 9999 9999 9999 9
!!! !
vvv vrrr rfff f sss seee elll leee eccc cttt tiii iooo onnn n sss sooo ouuu urrr rccc ceee e 111 1000 0... .111 1000 0... .111 1... .111 1000 0333 3 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 vvv vrrr rfff f ccc cuuu usss sttt t--- -ooo onnn neee e
vvv vrrr rfff f sss seee elll leee eccc cttt tiii iooo onnn n sss sooo ouuu urrr rccc ceee e 111 1000 0... .111 1000 0... .111 1... .111 1000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 vvv vrrr rfff f ccc cuuu usss sttt t--- -ttt twww wooo o
vvv vrrr rfff f sss seee elll leee eccc cttt tiii iooo onnn n sss sooo ouuu urrr rccc ceee e 000 0... .000 0... .000 0... .000 0 000 0... .000 0... .000 0... .000 0 vvv vrrr rfff f ddd drrr rooo oppp p
!!! !
iii ippp p rrr rooo ouuu uttt teee e vvv vrrr rfff f ddd drrr rooo oppp p 000 0... .000 0... .000 0... .000 0 000 0... .000 0... .000 0... .000 0 NNN Nuuu ulll llll l000 0
!!! !
london#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e vvv vrrr rfff f ddd drrr rooo oppp p
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 chp7ONLa

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1974 chp7ONLa

Uploaded by

Copyright:

Available Formats

1974_chp7ONLa.

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

You might also like