supplemental content chp7

7/31/2019 Supplemental Content Chp7

1/36


2/36

C HAPTERS UPPLEMENT

7

This online supplement of Chapter 7 focuses on two important MPLS VPN developments. T

first one is Inter-Autonomous MPLS VPN. Inter-Autonomous MPLS VPN is a concept whereb

two MPLS VPN service provider networks interconnect to provide a seamless VPN service

their MPLS VPN customers, even though the customers have VPN sites that are connected t

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 otherservice 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, whereb

the CE-facing interface on the provider edge (PE) router no longer belongs to just one virtua

routing/forwarding (VRF) instance. First, however, this supplement discusses Border Gatew

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 keywo

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 BGPneighbor Command withsend-labelKeyword

!!!!

rrrroooouuuutttteeeerrrr bbbbggggpppp 1111

bbbbggggpppp lllloooogggg----nnnneeeeiiiigggghhhhbbbboooorrrr----cccchhhhaaaannnnggggeeeessss

nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....222200000000....222255554444....2222 rrrreeeemmmmooootttteeee----aaaassss 1111

nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....222200000000....222255554444....2222 uuuuppppddddaaaatttteeee----ssssoooouuuurrrrcccceeee LLLLooooooooppppbbbbaaaacccckkkk0000

!!!!

aaaaddddddddrrrreeeessssssss----ffffaaaammmmiiiillllyyyy iiiippppvvvv4444

nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....222200000000....222255554444....2222 aaaaccccttttiiiivvvvaaaatttteeee

nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....222200000000....222255554444....2222 sssseeeennnndddd----llllaaaabbbbeeeellll

nnnnoooo aaaauuuuttttoooo----ssssuuuummmmmmmmaaaarrrryyyy

nnnnoooo ssssyyyynnnncccchhhhrrrroooonnnniiiizzzzaaaattttiiiioooonnnn

eeeexxxxiiiitttt----aaaaddddddddrrrreeeessssssss----ffffaaaammmmiiiillllyyyy

!!!!

MPLS VPN


3/36

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

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

Example 7-2 BGPneighbor Command with Outbound Route Map

!!!!


nnnnoooo ssssyyyynnnncccchhhhrrrroooonnnniiiizzzzaaaattttiiiioooonnnn

bbbbggggpppp lllloooogggg----nnnneeeeiiiigggghhhhbbbboooorrrr----cccchhhhaaaannnnggggeeeessss

nnnneeeettttwwwwoooorrrrkkkk 11110000....11110000....111100000000....3333 mmmmaaaasssskkkk 222255555555....222255555555....222255555555....222255555555


nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....4444....1111 rrrroooouuuutttteeee----mmmmaaaapppp llllaaaabbbbeeeellll oooouuuutttt


nnnnoooo aaaauuuuttttoooo----ssssuuuummmmmmmmaaaarrrryyyy

!!!!

aaaacccccccceeeessssssss----lllliiiisssstttt 1111 ppppeeeerrrrmmmmiiiitttt 11110000....11110000....111100000000....3333rrrroooouuuutttteeee----mmmmaaaapppp llllaaaabbbbeeeellll ppppeeeerrrrmmmmiiiitttt 11110000

mmmmaaaattttcccchhhh iiiipppp aaaaddddddddrrrreeeessssssss 1111

sssseeeetttt mmmmppppllllssss----llllaaaabbbbeeeellll

!!!!


4/36


providers. In that case, the MPLS VPN service becomes Inter-Autonomous MPLS VPN. Tw

more autonomous systems have to be interconnected at some point to provide connectivity fo

VPN sites in the different autonomous systems. The two routers that provide the connectivit

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

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 V

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

routers. They are connected via a (sub)interface that is a VRF interface on both PE routers for

VPN that is shared between the two service providers. Therefore, the VRFs are connected bac

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 refer

to as Inter-Autonomous MPLS VPN option 10a, 10b, and 10c. They are presented here in t

order.

MPLS VPN

AutonomousSystem 2

PEPE

PE-ASBRPE-ASBR

GreenVRF

CE

RedVRF

CE

BlueVRF

CE

MPLS VPN

AutonomousSystem 1

Green VRF

Red VRF

Blue VRF

GreenVRF

CE

RedVRF

CE

BlueVRF

CE


5/36


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

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

ASBRPE

AutonomousSystem 1

MPLS VPN

PEASBR

AutonomousSystem 2

MPLS VPN

eBGP forVPNv4 + Label

iBGP for

VPNv4 + Label

iBGP for

VPNv4 + Label

RedVRF

CE

RedVRF

CE


6/36


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 h

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 witlabel. eBGP sends vpnv4 routes with a label by default in Cisco IOS. That means you do not n

to configure the send-label keyword on the eBGP neighbor command for the ASBR. You just n

to configure the BGP neighbor command for the eBGP neighbor under the address family vp

of the router bgp process and activate the peer. Figure 7-3 shows the packet forwarding betw

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

the vpnv4 routes that are advertised from AS 1 to AS 2. This is so unless next-hop-selfis use

the ASBR of AS 2. In that case, the ASBR in AS 2 assigns a new VPN label to the vpnv4 route

advertises this VPN label to the PE routers in AS 2. Therefore, the VPN label used in AS 2 is e

a label that the ASBR in AS 2 assigns or a label that the ASBR in AS 1 assigns, depending o

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 rout

that PE router. This is a nice behavior for regular MPLS VPN because unwanted vpnv4 routes

not stored on PE routers if no VRF imports the vpnv4 prefixes according to the route targets (

on the PE. This behavior improves scalability in the MPLS VPN network. However, for Inte

Autonomous MPLS VPN, the ASBRs need to have all the vpnv4 routes because some of the

need to be advertised to the ASBR in the other AS, regardless of whether the ASBR has a VR

ASBRPE

AutonomousSystem 1

MPLS VPN

PEASBR

AutonomousSystem 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


7/36


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.

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

Example 7-3 Denying a vpnv4 Route

sydney#ddddeeeebbbbuuuugggg iiiipppp bbbbggggpppp vvvvppppnnnnvvvv4444 uuuunnnniiiiccccaaaasssstttt uuuuppppddddaaaatttteeeessss iiiinnnn

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;

ASBRPE

Autonomous

System 1

MPLS VPN

PEASBR

Autonomous

System 2

MPLS VPN

eBGP for

VPNv4 + Label

iBGP forVPNv4 + Label

iBGP ForVPNv4 + Label

RedVRF

CE

RedVRF

CE

RCVD VPNv4 RD:X --- DENIED Due ToExtended Community Not Supported

No Red VRF AttachedTo This ASBR


8/36


VRF interfaces are allowed on the ASBR, but they are not needed. You need to configure a spe

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

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 tow

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

IOS helps by automatically creating a /32 connected route on the local ASBR for the IP addr

of the common link on the neighboring ASBR. This automatically created route is called the eB

peer neighbor route and is created as soon as the eBGP neighbor under address family vpnv

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

this by including the link in the IGP and making the interface toward the other ASBR passiv

you can configure redistribute connected under the IGP. Of course, when you have next-hop

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

not put the VPN label for every vpnv4 route it receives from the remote ASBR, in its LFIB.

improves scalability. The outgoing label in the local ASBR is the implicit NULL label for al

vpnv4 routes from the remote AS. Also, the local ASBR does not need to assign a local labe

each vpnv4 route because it is not the next hop for these vpnv4 routes.

ASBRPE

AutonomousSystem 1

MPLS VPN

PEASBR

AutonomousSystem 2

MPLS VPN


iBGP for

VPNv4 + Label

iBGP for

VPNv4 + Label

RedVRF

CE

RedVRF

CE

x.x.x.x

Generates ax.x.x.x./32 Route


9/36


Multihop eBGP Distribution of vpnv4 Routes with Label Between Sourceand Destination Autonomous Systems, with eBGP Distribution of IPv4Routes 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 exchangingor 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 anIGP 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 areredistributed from IGP into eBGP and vice versa on the ASBRs.


10/36


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

Another way to get the /32 IPv4 PE loopback prefixes to all the PE routers is to advertise the

IPv4 PE loopback prefixes (and a label) via iBGP. This means that iBGP must send IPv4 prefi

with a label. The advertisement of these prefixes and the label via iBGP is most likely the prefe

way of getting the IPv4 prefixes from another AS into your own AS. Advertising external prefi

into your AS via BGP is much more acceptable than advertising them into your own IGP.

ASBR

RR

ASBRPE PECE

Red VRF

CE

Red VRF

MPLS VPNAutonomous System 1

RR


Redistribution of /32 IPv4 PE

Loopback Prefixes From eBGP

Into IGP and Vice Versa

iBGP

forVPNv4

+

Lab

el

iBGPforV

PNv4

+

Label

eBGP For IPv4 +Label

Multihop eBGP ForVPNv4 + Label

+ Next -hop-unchanged


11/36


Look at Figure 7-7 for a schematic overview of the solution where iBGP advertises the IPv4 /32

PE prefixes (and label) in the other autonomous systems.

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

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.

ASBR

RR

ASBRPE PECE

Red VRF

CE

Red VRF


RR


iBGP

forVPNv4

+

Lab

el

iBGPfo

rVPNv4

+

Label

eBGP For IPv4 +

Label

Multihop eBGP For

VPNv4 + Label

iBGP For IPv4 +Label

iBGP For IPv4 +Label

+ Next-hop-unchanged


12/36


Note, too, that the RRs have an eBGP session between them to exchange the vpnv4 prefixes

defaultas usual for external BGPthe RRs set the next hop of the vpnv4 prefixes to themse

That means the RRs assign a label to the vpnv4 routes, and all inter-autonomous traffic pass

through them. RRs are usually routers that have the specific function of reflecting routes and

forwarding traffic. To prevent the RRs from setting the next hop to themselves, configure thekeyword next-hop-unchanged on the route reflectors on the BGP neighbor command unde

vpnv4 address family to the multihop eBGP neighbor. The result is that the next hop of the vp

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

The top labeleither the IGP label or the eBGP assigned labelis always the label that is bo

to the /32 prefix of the egress PE router. You can see that the packets have two labels at all tim

ASBR

RR

ASBRPE PE

VPN Label

eBGP Label

IPv4 Packet

VPN Label

IGP Label

IPv4 Packet

VPN Label

IGP Label

IPv4 Packet IPv4 PacketIPv4 Packet

CE

Red VRF

CE

Red VRF

RR




13/36


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

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.

ASBR

RR

ASBRPE PE

VPN Label

eBGP Label

IPv4 Packet

VPN Label

iBGP Label

IGP Label

IPv4 Packet

VPN Label

IGP Label

IPv4 Packet IPv4 PacketIPv4 Packet

CE

Red VRF

CE

Red VRF

RR

MPLS VPNAutonomous System 1 MPLS VPNAutonomous System 2


14/36


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 syste

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

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

schematic overview of the solution where iBGP for IPv4 + label is used. Note that the middle

(AS 3) runs only MPLS, not MPLS VPN.

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

RR

ASBR

RRPE PECE

Red VRF

CE

Red V


MPLSAutonomous System 3

ASBR

ASBR ASBR


iBGP

forIP

v4+

Lab

el

iBGPfo

rIPv4

+

Label

eBGP for IPv4 +Label

eBGP for IPv4 +Label

Multihop eBGP ForVPNv4 + Label

iBGP For IPv4 +

Label

iBGP for VPNv4 +

Label

iBGP for VPNv4 +

Label

+ Next-hop-unchanged


15/36


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

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

RR

ASBR

RRPE PECE

Red VRF

CE

Red VRF


MPLSAutonomous System 3

ASBR

ASBR ASBR


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



16/36


anymore; it becomes a multihop session. The local ASBR has to be able to reach the loopbac

address of the other ASBR. Because you probably do not want to run an IGP between the tw

service providers, you can just configure static routes for the remote loopback IP address. Yo

must configure one such static route per link between the ASBRs, because you want to use e

link to forward traffic on. The eBGP multihop session can be for vpnv4 prefixes and label orIPv4 prefixes and label. Therefore, you can use the eBGP multihop session in all of the previo

explained solutions. Figure 7-12 shows an example of two ASBRs with two links between th

and an eBGP peering session for vpnv4 prefixes and label. You can find the configuration for

in Example 7-4. To make it work, configure disable-connected-check for the eBGP neighbor

mpls bgp forwarding on the interfaces toward the other ASBR.

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

Example 7-4 Configuration for Nondirectly Connected eBGP Peers

!

hostname london-asbr-1

!

interface Loopback0

ip address 10.10.100.1 255.255.255.255

!

interface Ethernet1/1

ip address 10.10.91.2 255.255.255.0mpls bgp forwarding

!

interface Ethernet1/2

ip address 10.10.90.2 255.255.255.0

mpls bgp forwarding

!

PE PE

ASBRASBR

sydney-ASBR-1london-ASBR-1

MPLS VPN

AutonomousSystem 65001

MPLS VPN

AutonomousSystem 2

Eth 1/210.10.90.2

10.10.91.2

Eth 1/1

Eth 110.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 ForVPNv4 + Label

conti


17/36


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-changesneighbor 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 Configuration for Nondirectly Connected eBGP Peers (Continued)


18/36


cont

Example 7-5 shows that BGP is the label advertising protocol on the interfaces between the

ASBRs. The VRF cust-one prefix 10.99.1.2/32 learned on the london-asbr-1 router is recursiv

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#sssshhhhoooowwww mmmmppppllllssss iiiinnnntttteeeerrrrffffaaaacccceeeessss ddddeeeettttaaaaiiiillll

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#sssshhhhoooowwww iiiipppp bbbbggggpppp vvvvppppnnnnvvvv4444 rrrrdddd 1111::::1111 11110000....99999999....1111....2222

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 Configuration for Nondirectly Connected eBGP Peers (Continued)


19/36


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-numberdelete command and the set

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

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#sssshhhhoooowwww iiiipppp cccceeeeffff vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee 11110000....99999999....1111....2222

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)


20/36


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

!

ASBRsydney-as-1

PE

AutonomousSystem 1

10.10.100.1/32RT 1:1

MPLS VPN

PEASBRsydney-as-2

AutonomousSystem 2

MPLS VPN

10.10.100.1/32RT 2:1

Rewrite RT1:1 to RT 2:1

10.10.100.1/32RT 2:1




conti


21/36


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#sssshhhhoooowwww iiiipppp bbbbggggpppp vvvvppppnnnnvvvv4444 aaaallllllll 11110000....11110000....111100000000....1111


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#sssshhhhoooowwww iiiipppp bbbbggggpppp vvvvppppnnnnvvvv4444 aaaallllllll 11110000....11110000....111100000000....1111


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)


22/36

CsC

Figure 7-14 Overview of CsC

MPLS is extended to the customer edge (CE) router, which means a label distribution protoc

needed between the PEacross the VRF interfaceand the CE routers. This can be achieve

any IGP that is supported on VRF interfaces together with LDP for the label distribution, or it

be eBGP for IPv4 routes with label exchange.

CSC-CE

Customer 1Site A

ASBR

Customer 2Site A Customer 1Site B

ASBR

Customer 2Site B

Carrier 1Site A

CSC-CE

CSC-PE CSC-PE

Carrier 1Site BBGP

MPLS

Carriers Carrier (CSC)MPLS VPN Network


23/36


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. TheBGP 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 theCisco 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 onthe CSC-CE router too, of course.) The show mpls ldp commands have been enhanced with the


24/36

CsC

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

!!!!

hhhhoooossssttttnnnnaaaammmmeeee lllloooonnnnddddoooonnnn

!!!!

iiiinnnntttteeeerrrrffffaaaacccceeee EEEEtttthhhheeeerrrrnnnneeeetttt0000////1111////2222

iiiipppp vvvvrrrrffff ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg ccccuuuusssstttt----oooonnnneeee

iiiipppp aaaaddddddddrrrreeeessssssss 11110000....11110000....2222....2222 222255555555....222255555555....222255555555....0000

mmmmppppllllssss iiiipppp

!!!!

london#sssshhhhoooowwww mmmmppppllllssss llllddddpppp nnnneeeeiiiigggghhhhbbbboooorrrr vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee

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:15LDP 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#sssshhhhoooowwww mmmmppppllllssss llllddddpppp bbbbiiiinnnnddddiiiinnnnggggssss vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee

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


remote binding: lsr: 10.10.100.1:0, label: imp-nulllib 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#sssshhhhoooowwww mmmmppppllllssss llllddddpppp ddddiiiissssccccoooovvvveeeerrrryyyy vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee

Local LDP Identifier:

10.99.1.1:0

Discovery Sources:conti


25/36


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.

Interfaces:

Ethernet0/1/2 (ldp): xmit/recv

LDP Id: 10.10.100.1:0

london#sssshhhhoooowwww mmmmppppllllssss iiiinnnntttteeeerrrrffffaaaacccceeeessss vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee ddddeeeettttaaaaiiiillll

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

!!!!

hhhhoooossssttttnnnnaaaammmmeeee lllloooonnnnddddoooonnnn

!!!!


!!!!

aaaaddddddddrrrreeeessssssss----ffffaaaammmmiiiillllyyyy iiiippppvvvv4444 vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee

rrrreeeeddddiiiissssttttrrrriiiibbbbuuuutttteeee ccccoooonnnnnnnneeeecccctttteeeedddd


nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....2222....1111 aaaaccccttttiiiivvvvaaaatttteeee


eeeexxxxiiiitttt----aaaaddddddddrrrreeeessssssss----ffffaaaammmmiiiillllyyyy

!!!!

london#sssshhhhoooowwww mmmmppppllllssss iiiinnnntttteeeerrrrffffaaaacccceeeessss vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee ddddeeeettttaaaaiiiillll

VRF cust-one:

Interface Ethernet0/1/2:


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


26/36

CsC

conti

LFIB

When you deploy CsC, the LFIB shows that packets are forwarded labeled instead of unlabe

on the outgoing VRF interface on the PE router. Also, the packets arriving from the CSC-CE ro

are already labeled. The outgoing label stack for packets toward the remote PE is two labels

usual with MPLS VPN. The packets from the CSC-CE, arriving on the VRF interface on the C

PE, are forwarded by a lookup in the LFIB table on the CSC-PE router, as they are labeled.

top label is the label that is associated with the VRF prefix, advertised from the PE to the CELDP or eBGP. With regular MPLS VPN, the packets from the CE router were always IP pack

so the forwarding was done based on an IP lookup of the destination IP address in the approp

VRF routing table. Example 7-9 shows LFIB entries on the CSC-PE router for VRF prefixes

the VRF prefix 10.10.100.1/32 learned from the London CSC-CE router, the outgoing label is

Pop Label. With regular MPLS VPN, the outgoing label wasNo Label. The Pop Label is the re

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

CSC-PE router. The prefix 10.99.1.2/32 shows up in the CEF table on the CSC-CE router wit

outgoing label of 33. Regular MPLS VPN had no outgoing label toward the PE router. Theoutgoing label stack on the ingress CSC-PE router for this VRF prefix consists of two labels



MPLS operational

MTU = 1500

london-ce#sssshhhhoooowwww iiiipppp bbbbggggpppp 11110000....99999999....1111....2222 222255555555....222255555555....222255555555....222255555555

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#sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee 11110000....11110000....111100000000....1111

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#sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee



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)


27/36


Anti-Label Spoofing Mechanism

When a VRF interface of a PE router that is running Cisco IOS receives a labeled packet, the PE

checks whether the label was a locally assigned label for that VRF. If it was not, the labeled packet

is dropped. With CsC, the packets from customers arriving on the PE router can be labeled, so it

is important to check whether that label was indeed assigned to that VRF. This effectively prevents

one customer from spoofing packets with labels that are assigned to another customer, both

connected to the same service provider.

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#sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee 11110000....11110000....111100000000....1111



45 Pop Label 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1

london-ce#sssshhhhoooowwww iiiipppp cccceeeeffff 11110000....99999999....1111....2222

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#sssshhhhoooowwww mmmmppppllllssss ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg----ttttaaaabbbblllleeee vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee 11110000....99999999....1111....2222 ddddeeeettttaaaaiiiillll



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-oneNo output feature configured

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


28/36

CsC

CsC Scenarios

The possible CsC scenarios can be classified into three categories:

Only the CE routers run MPLS.

All carrier C routers run MPLS.

There is hierarchical MPLS VPN.

The first two scenarios differ from each other in the way that MPLS and BGP are deployed in

carrier networks. In the third scenario, the carriers also run MPLS VPN. Because the CsC and

carriers run MPLS VPN, this third scenario is commonly referred to as theHierarchical MP

VPN scenario. No matter what scenario you deploy, the characteristic feature of CsC is that

VRF interface of the CSC-PE router must have labeled traffic. Remember that for all three

scenarios, an IGP and LDP can exist between the CSC-PE and CSC-CE, or eBGP and label

distribution can exist between the CSC-PE and CSC-CE.

Only the CE Routers Run MPLS

In this scenario, only the CSC-CE routers run MPLS. All the customer routes are BGP routes

the C routers of the carrier network to forward the customer traffic, they must run BGP. There

all the C routers of the carrier network run iBGP, not just the border routers. This is because e

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

iBGPiBGP

Carrier 1 Site A

ASBR

Carrier 1Site B

ASCSC-PE CSC-CECSC-PECSC-CE

MPLS

Carrier 1 IGPRoutes + Label



29/36


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

to the customers by performing a label lookup in the LFIB, not by performing an IP lookup.

Because the customer routes in the carrier network are known as BGP routes, and because the

labeled traffic can be forwarded based on the label that is assigned to the BGP next hop, only the

edge routers in the carrier network need to be running BGP. This is already a great improvement

over the first CsC scenario, in which all C routers were required to run BGP. Look at Figure 7-17

for the schematic overview of this scenario.

CsCCarrier 1

iBGP

Site A

ASBR

Carrier 1

iBGP

Site B

ASBR


IGP Carrier 1Label

IPv4 Packet

CSC VPN

Label

IGP CSCLabel

IPv4 Packet

IGP Carrier 1

Label

IPv4 Packet

CSC-CE CSC-PECSC-PECSC-CE


30/36

CsC

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 BG

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 first scenario is that the packets in the carrier network ar

labeled throughout the network.

CsC


iBGP IPv4 Routes

Carrier 1 Site A

ASBR

Carrier 1Site B

ASBCSC-PE CSC-CECSC-PECSC-CE

MPLS



CsCCarrier 1 Site A

ASBR

Carrier 1Site 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

CSC-PE CSC-CECSC-PECSC-CE


31/36


Hierarchical MPLS VPN

In this scenario, all the carrier C routers run MPLS, and there is MPLS VPN. The carriers in turn

have their own PE routers interfacing with their customer routers through a VRF interface. The

benefit of this scenario over the second CsC scenario is that now the customer routes are in their

own VRF in the carrier network. This is hierarchical MPLS VPN because the carriers are VPNcustomers 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 1Site B

ASBR

(PE)


MPLS

Carrier 1 IGP

Routes + Label

Carrier 1 IGP

Routes + Label


32/36

VRF Selection Based on Source IP Address

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 i

regular MPLS VPN. In the CsC network, however, the packets have three labels. The bottom l

is the label that forwards the packet on the egress PE router. The middle label is the CSC VP

label that forwards the packet out of the correct VRF interface on the CSC-PE router. The top l

is the IGP CSC label that forwards the packet to the correct egress CSC-PE router in the CsC

network.


When packets from the CE router enter the PE router with MPLS VPN, they are seen as com

from one and only one VRF. This is based on the VRF configuration on the interface of the P

router toward the CE. If the service provider, for example, has a cable broadband access netw

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 ro

and route the traffic based on the source IP address to a different interface on the PE router.

routing based on the source IP address can be done with policy-based routing (PBR) in Cisco I

It entails that a PBR CE router sits in front of the PE router. Multiple physical interfaces can e

between the PBR CE and the PE router. However, an easier and cheaper method is to have mul

CsCCarrier 1 Site A

ASBR

(PE)

Carrier 1Site B

ASBR

(PE)


Carrier 1

VPN Label

Carrier 1

VPN Label

IPv4 Packet

Carrier 1

VPN Label

CSC VPNLabel

IGP CSCLabel

IPv4 Packet

Carrier 1

VPN Label

Carrier 1

VPN Label

IGP Carrier 1

Label

IGP Carrier 1

LabelIGP Carrier 1

Label

IGP Carrier 1

Label

IPv4 Packet



33/36


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-21PBR to PE Router

The traffic from the three hosts on the broadband access network is policy-routed onto the

corresponding VRF interface of the PE router. The traffic is then routed on the PE through regular

MPLS VPN toward one ISP in one VPN.

Another solution, VRF selection, offers the same functionality without the need for the extra router

for the PBR in front of the PE router. With that solution, the hosts on the broadband access network

are directly connected to the PE router. The interface on the PE router toward the hosts is put inthe global routing table instead of a VRF. However, that interface is configured with VRF

selection, which enables the PE router to route the traffic to a particular VRF based on the source

IP address. Figure 7-22 shows the same network as Figure 7-21, but now with VRF Selection.

AS 1

MPLS VPN

PE

PE

PE

PE

VRFcust-one

CE

ISP 1

VRFcust-two

CE

ISP 2

VRFcust-three

CE

ISP 3

10.10.1.103

10.10.1.77

10.10.1.10

Policy-Based

Routing to VLANInterfaces

BroadbandAccessNetwork

CE

VLAN 10 VRF cust-one

VLAN 11 VRF cust-two

VLAN 12 VRF cust- three


34/36


Figure 7-22 VRF Selection

After the traffic is routed to the chosen VRF, it is forwarded according to the VRF routing tabl

the PE router. The traffic is then forwarded as regular MPLS VPN traffic in the backbone, with

labels on the packet as usual.

The interface on the PE router toward the hosts (or CE routers) is in the global routing table

Therefore, the return traffic from the Internet (or the VRF sites) is forwarded according to th

global routing table in the MPLS VPN network. The traffic can be sent back by having the netw

statement of BGP cover the IP subnet of that broadband access interface on the PE router. On

remote PE router, a static route in the VRF with a global next-hop IP address enables the traffi

be forwarded back to this PE router where VRF Selection is enabled. Example 7-10 shows a

sample configuration for VRF Selection based on source IP address. The traffic from sourceaddress 10.10.1.103 is forwarded into VRF cust-one, and the traffic from source IP address

10.10.1.10 is forwarded into VRF cust-two. The command to enable VRF Selection on the

customer-facing interface is ip vrf select source. The command to map source IP addresses

AS 1

MPLS VPN

PE

PE

PEPE

VRFcust-one

CE

ISP 1

VRFcust-two

CE

ISP 2

VRFcust-three

CE

ISP 3

10.10.1.103

10.10.1.77

10.10.1.10

VRF Selection

BroadbandAccess

Network

Based On

Source IPAddress


35/36


VRFs is vrf selection sourcesource-IP-address source-IP-maskvrfvrf_name. The command

show ip vrf select demonstrates the configured VRF Selection policy.

Example 7-10 VRF Selection Based on Source IP Address

!

hostname london

!

ip vrf cust-one

rd 1:1

route-target export 1:1

route-target import 1:1

!

ip vrf cust-two

rd 2:2

route-target export 2:2

route-target import 2:2!

interface Ethernet0/1/2

ip vrf select source

ip address 10.10.1.1 255.255.255.0

!

vrf selection source 10.10.1.103 255.255.255.255 vrf cust-one

vrf selection source 10.10.1.10 255.255.255.255 vrf cust-two

!

router bgp 1

!

address-family ipv4 vrf cust-tworedistribute connected

no auto-summary

no synchronization

exit-address-family

!

address-family ipv4 vrf cust-one

redistribute connected

no auto-summary

no synchronization

exit-address-family

!

london#sssshhhhoooowwww iiiipppp vvvvrrrrffff sssseeeelllleeeecccctttt

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


36/36


You can configure ip vrf receive vrf_name on the VRF Selection interface to announce the su

directly into the VRF routing table. In this way, the return traffic does not need to be routed b

to this PE router according to the global routing table, because the subnet prefix is advertised

vpnv4 prefix. Example 7-11 shows how the command ip vrf receive is applied to announce

subnet 10.10.1.0/24 in the VRFs cust-one and cust-two of Example 7-10.

Traffic with an unknown source IP address from a VRF Selection interface is forwarded accorto the global routing table on the PE router. This allows malicious traffic if the source IP add

is spoofed. To prevent this, you can configure a VRF on the PE router to drop such traffic. To d

this potentially malicious traffic, the VRF can route it to a NULL interface on the PE router

a static route. Example 7-12 shows the extra VRF named drop configured on the PE router, w

serves as a bucket to drop packets with an unknown source IP address.

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

!!!!

iiiinnnntttteeeerrrrffffaaaacccceeee EEEEtttthhhheeeerrrrnnnneeeetttt0000////1111////2222

iiiipppp vvvvrrrrffff sssseeeelllleeeecccctttt ssssoooouuuurrrrcccceeee

iiiipppp vvvvrrrrffff rrrreeeecccceeeeiiiivvvveeee ccccuuuusssstttt----oooonnnneeee

iiiipppp vvvvrrrrffff rrrreeeecccceeeeiiiivvvveeee ccccuuuusssstttt----ttttwwwwoooo

iiiipppp aaaaddddddddrrrreeeessssssss 11110000....11110000....1111....1111 222255555555....222255555555....222255555555....0000

!!!!

Example 7-12 Drop VRF for Unknown Source IP Addresses

!!!!

iiiipppp vvvvrrrrffff ddddrrrroooopppp

rrrrdddd 9999999999999999::::9999999999999999

!!!!

vvvvrrrrffff sssseeeelllleeeeccccttttiiiioooonnnn ssssoooouuuurrrrcccceeee 11110000....11110000....1111....111100003333 222255555555....222255555555....222255555555....222255555555 vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee

vvvvrrrrffff sssseeeelllleeeeccccttttiiiioooonnnn ssssoooouuuurrrrcccceeee 11110000....11110000....1111....11110000 222255555555....222255555555....222255555555....222255555555 vvvvrrrrffff ccccuuuusssstttt----ttttwwwwoooo

vvvvrrrrffff sssseeeelllleeeeccccttttiiiioooonnnn ssssoooouuuurrrrcccceeee 0000....0000....0000....0000 0000....0000....0000....0000 vvvvrrrrffff ddddrrrroooopppp

!!!!

iiiipppp rrrroooouuuutttteeee vvvvrrrrffff ddddrrrroooopppp 0000....0000....0000....0000 0000....0000....0000....0000 NNNNuuuullllllll0000

!!!!

london#sssshhhhoooowwww iiiipppp rrrroooouuuutttteeee vvvvrrrrffff ddddrrrroooopppp

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

supplemental content chp7

Documents