View
221
Download
0
Category
Preview:
Citation preview
7/31/2019 Supplemental Content Chp7
1/36
7/31/2019 Supplemental Content Chp7
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
7/31/2019 Supplemental Content Chp7
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
!!!!
rrrroooouuuutttteeeerrrr bbbbggggpppp 66665555000000002222
nnnnoooo ssssyyyynnnncccchhhhrrrroooonnnniiiizzzzaaaattttiiiioooonnnn
bbbbggggpppp lllloooogggg----nnnneeeeiiiigggghhhhbbbboooorrrr----cccchhhhaaaannnnggggeeeessss
nnnneeeettttwwwwoooorrrrkkkk 11110000....11110000....111100000000....3333 mmmmaaaasssskkkk 222255555555....222255555555....222255555555....222255555555
nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....4444....1111 rrrreeeemmmmooootttteeee----aaaassss 1111
nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....4444....1111 rrrroooouuuutttteeee----mmmmaaaapppp llllaaaabbbbeeeellll oooouuuutttt
nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....4444....1111 sssseeeennnndddd----llllaaaabbbbeeeellll
nnnnoooo aaaauuuuttttoooo----ssssuuuummmmmmmmaaaarrrryyyy
!!!!
aaaacccccccceeeessssssss----lllliiiisssstttt 1111 ppppeeeerrrrmmmmiiiitttt 11110000....11110000....111100000000....3333rrrroooouuuutttteeee----mmmmaaaapppp llllaaaabbbbeeeellll ppppeeeerrrrmmmmiiiitttt 11110000
mmmmaaaattttcccchhhh iiiipppp aaaaddddddddrrrreeeessssssss 1111
sssseeeetttt mmmmppppllllssss----llllaaaabbbbeeeellll
!!!!
7/31/2019 Supplemental Content Chp7
4/36
Inter-Autonomous MPLS VPN
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
7/31/2019 Supplemental Content Chp7
5/36
669 Chapter 7: MPLS VPN
Because the interfaces between the two ASBRs are VRF interfaces, the traffic between the ASBRs
is plain, unlabeled IP traffic. As with regular MPLS VPN, routing needs to occur across the VRF
interface. This can be any routing protocol that regular MPLS VPN supports, as the PE-CE routing
protocol. However, because the routing serves to exchange routes across the autonomous system
border, service providers prefer eBGP, which is most likely to be seen in this solution. 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
7/31/2019 Supplemental Content Chp7
6/36
Inter-Autonomous MPLS VPN
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/31/2019 Supplemental Content Chp7
7/36
671 Chapter 7: MPLS VPN
attached that is importing the vpnv4 route. In Example 7-3, you can see the BGP debug message
when a PE router receives a vpnv4 prefix when no attached VRF is importing the vpnv4 prefix.
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
7/31/2019 Supplemental Content Chp7
8/36
Inter-Autonomous MPLS VPN
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
eBGP forVPNv4 + Label
iBGP for
VPNv4 + Label
iBGP for
VPNv4 + Label
RedVRF
CE
RedVRF
CE
x.x.x.x
Generates ax.x.x.x./32 Route
7/31/2019 Supplemental Content Chp7
9/36
673 Chapter 7: MPLS VPN
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.
7/31/2019 Supplemental Content Chp7
10/36
Inter-Autonomous MPLS VPN
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
MPLS VPNAutonomous System 2
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
7/31/2019 Supplemental Content Chp7
11/36
675 Chapter 7: MPLS VPN
Look at Figure 7-7 for a schematic overview of the solution where iBGP advertises the IPv4 /32
PE prefixes (and label) in the other autonomous systems.
Figure 7-7 Multihop eBGP Distribution of vpnv4 Prefixes and Label with iBGP for IPv4 and Label
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
MPLS VPNAutonomous System 1
RR
MPLS VPNAutonomous System 2
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
7/31/2019 Supplemental Content Chp7
12/36
Inter-Autonomous MPLS VPN
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
MPLS VPNAutonomous System 1
MPLS VPNAutonomous System 2
7/31/2019 Supplemental Content Chp7
13/36
677 Chapter 7: MPLS VPN
Figure 7-9 shows the packet forwarding in the solution where iBGP advertises the /32 IPv4
prefixes of the PE routers in the other autonomous system.
Figure 7-9 Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prefixes and Label with iBGP for
IPv4 and Label
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
7/31/2019 Supplemental Content Chp7
14/36
Inter-Autonomous MPLS VPN
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
MPLS VPNAutonomous System 1
MPLSAutonomous System 3
ASBR
ASBR ASBR
MPLS VPNAutonomous System 2
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
7/31/2019 Supplemental Content Chp7
15/36
679 Chapter 7: MPLS VPN
In Figure 7-11, you can see the packet forwarding in this solution.
Figure 7-11 Packet Forwarding: Multihop eBGP Distribution of vpnv4 Prefixes and Label Through an
MPLS Network
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
MPLS VPNAutonomous System 1
MPLSAutonomous System 3
ASBR
ASBR ASBR
MPLS VPNAutonomous 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
IPv4 Packet IPv4 Packet
7/31/2019 Supplemental Content Chp7
16/36
Inter-Autonomous MPLS VPN
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
7/31/2019 Supplemental Content Chp7
17/36
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 activate
neighbor 10.10.100.3 send-community both
exit-address-family
!
ip route 10.10.100.3 255.255.255.255 Ethernet1/2 10.10.90.1
ip route 10.10.100.3 255.255.255.255 Ethernet1/1 10.10.91.1
!
hostname sydney-asbr-1
!
interface Loopback0
ip address 10.10.100.3 255.255.255.255!
interface Ethernet0
ip address 10.10.91.1 255.255.255.0
mpls bgp forwarding
!
interface Ethernet1
ip address 10.10.90.1 255.255.255.0
mpls bgp forwarding
!
router bgp 2
no bgp default route-target filter
bgp log-neighbor-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)
7/31/2019 Supplemental Content Chp7
18/36
Inter-Autonomous MPLS VPN
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
neighbor 10.10.100.1 activate
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.100.1 activate
neighbor 10.10.100.1 send-community both
exit-address-family
!
!
ip route 10.10.100.1 255.255.255.255 Ethernet1 10.10.90.2
ip route 10.10.100.1 255.255.255.255 Ethernet0 10.10.91.2
!
Example 7-5 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:
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
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)
7/31/2019 Supplemental Content Chp7
19/36
683 Chapter 7: MPLS VPN
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)
7/31/2019 Supplemental Content Chp7
20/36
Inter-Autonomous MPLS VPN
Figure 7-13 RT Rewrite
Example 7-6 RT Rewrite
!
hostname sydney-as-1
!
router bgp 1
!
address-family vpnv4
neighbor 10.10.4.2 activate
neighbor 10.10.4.2 send-community both
neighbor 10.10.4.2 route-map to-as-2 out
neighbor 10.200.254.3 activate
neighbor 10.200.254.3 send-community both
exit-address-family
!
!
ip extcommunity-list 2 permit rt 1:1
!
route-map to-as-2 permit 10
match extcommunity 2
set extcomm-list 2 delete
set extcommunity rt 2:1 additive
!
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
eBGP forVPNv4 + Label
iBGP forVPNv4 + Label
iBGP forVPNv4 + Label
conti
7/31/2019 Supplemental Content Chp7
21/36
685 Chapter 7: MPLS VPN
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
BGP routing table entry for 1:1:10.10.100.1/32, version 8
Paths: (1 available, best #1, table cust-one)
Advertised to update-groups:
3
65001
10.200.254.2 (metric 3) from 10.200.254.3 (194.68.129.9)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1
Originator: 10.200.254.2, Cluster list: 194.68.129.9,
mpls labels in/out 33/45
sydney-as-2#sssshhhhoooowwww iiiipppp bbbbggggpppp vvvvppppnnnnvvvv4444 aaaallllllll 11110000....11110000....111100000000....1111
BGP routing table entry for 1:1:10.10.100.1/32, version 10
Paths: (1 available, best #1, no table)
Flag: 0xA00
Not advertised to any peer
1 65001
10.10.4.1 from 10.10.4.1 (192.168.99.1)
Origin IGP, localpref 100, valid, external, best
Extended Community: RT:2:1,
mpls labels in/out nolabel/33
Example 7-6 RT Rewrite (Continued)
7/31/2019 Supplemental Content Chp7
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
7/31/2019 Supplemental Content Chp7
23/36
687 Chapter 7: MPLS VPN
You can see one larger carrier, the CsC, providing MPLS VPN services to the smaller carriers and
MPLS extended to include the CE routers of the smaller carriers. More routers from the carriers
might be running MPLS. This is discussed further in the later section CsC Scenarios. The
customer sites are attached to the sites of the carriers by interfacing with ASBRs. The carriers
carry the customer routes in BGP, because these routes are external to the 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
7/31/2019 Supplemental Content Chp7
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
local binding: label: 45
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
remote binding: lsr: 10.10.100.1:0, label: imp-null
lib entry: 10.99.1.1/32, rev 6
local binding: label: 32
lib entry: 192.168.1.0/24, rev 9
remote binding: lsr: 10.10.100.1:0, label: imp-null
london#sssshhhhoooowwww mmmmppppllllssss llllddddpppp ddddiiiissssccccoooovvvveeeerrrryyyy vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee
Local LDP Identifier:
10.99.1.1:0
Discovery Sources:conti
7/31/2019 Supplemental Content Chp7
25/36
689 Chapter 7: MPLS VPN
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)
LSP Tunnel labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1500
Example 7-8 eBGP for IPv4 and Label on a VRF Interface
!!!!
hhhhoooossssttttnnnnaaaammmmeeee lllloooonnnnddddoooonnnn
!!!!
rrrroooouuuutttteeeerrrr bbbbggggpppp 1111
!!!!
aaaaddddddddrrrreeeessssssss----ffffaaaammmmiiiillllyyyy iiiippppvvvv4444 vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee
rrrreeeeddddiiiissssttttrrrriiiibbbbuuuutttteeee ccccoooonnnnnnnneeeecccctttteeeedddd
nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....2222....1111 rrrreeeemmmmooootttteeee----aaaassss 66665555000000001111
nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....2222....1111 aaaaccccttttiiiivvvvaaaatttteeee
nnnneeeeiiiigggghhhhbbbboooorrrr 11110000....11110000....2222....1111 sssseeeennnndddd----llllaaaabbbbeeeellll
eeeexxxxiiiitttt----aaaaddddddddrrrreeeessssssss----ffffaaaammmmiiiillllyyyy
!!!!
london#sssshhhhoooowwww mmmmppppllllssss iiiinnnntttteeeerrrrffffaaaacccceeeessss vvvvrrrrffff ccccuuuusssstttt----oooonnnneeee ddddeeeettttaaaaiiiillll
VRF cust-one:
Interface Ethernet0/1/2:
IP labeling not enabled
Example 7-7 Example of LDP Commands for CsC (Continued)
7/31/2019 Supplemental Content Chp7
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
LSP Tunnel labeling not enabled
BGP labeling enabled
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
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
18 Pop Label 10.10.2.1/32[V] 0 Et0/1/2 10.10.2.1
Example 7-8 eBGP for IPv4 and Label on a VRF Interface (Continued)
7/31/2019 Supplemental Content Chp7
27/36
691 Chapter 7: MPLS VPN
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
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
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
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
33 22 10.99.1.2/32[V] 0 PO4/0/0 point2point
MAC/Encaps=4/12, MRU=4466, Label Stack{19 22}
0F008847 0001300000016000
VPN route: cust-oneNo output feature configured
Example 7-9 LFIB Entries on the CSC-PE (Continued)
7/31/2019 Supplemental Content Chp7
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
Carrier 1 IGPRoutes + Label
7/31/2019 Supplemental Content Chp7
29/36
693 Chapter 7: MPLS VPN
For an overview of the packet forwarding in this scenario, check out Figure 7-16. The packets have
two MPLS labels in the CsC network. This is no different from regular MPLS VPN. However, the
packets on the links between the CSC-PE and CSC-CE now have one label. The result of this is
that the CSC-PE does not need to perform an IP lookup of the destination IP address in the IP
header anymore. When a packet arrives on the VRF interface of the CSC-PE, it looks up the 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
IPv4 Packet IPv4 Packet
IGP Carrier 1Label
IPv4 Packet
CSC VPN
Label
IGP CSCLabel
IPv4 Packet
IGP Carrier 1
Label
IPv4 Packet
CSC-CE CSC-PECSC-PECSC-CE
7/31/2019 Supplemental Content Chp7
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 VPNv4 Routes + Label
iBGP IPv4 Routes
Carrier 1 Site A
ASBR
Carrier 1Site B
ASBCSC-PE CSC-CECSC-PECSC-CE
MPLS
Carrier 1 IGPRoutes + Label
Carrier 1 IGPRoutes + Label
CsCCarrier 1 Site A
ASBR
Carrier 1Site B
ASBR
IPv4 Packet IPv4 Packet
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
7/31/2019 Supplemental Content Chp7
31/36
695 Chapter 7: MPLS VPN
Hierarchical MPLS VPN
In this scenario, all the carrier C routers run MPLS, and there is MPLS VPN. The carriers in turn
have their own PE routers interfacing with their customer routers through a VRF interface. The
benefit of this scenario over the second CsC scenario is that now the customer routes are in their
own VRF in the carrier network. This is hierarchical MPLS VPN because the carriers are 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 VPNv4 Routes + Label
iBGP IPv4 Routes + Label
Carrier 1 Site A
ASBR
(PE)
Carrier 1Site B
ASBR
(PE)
CSC-PE CSC-CECSC-PECSC-CE
MPLS
Carrier 1 IGP
Routes + Label
Carrier 1 IGP
Routes + Label
7/31/2019 Supplemental Content Chp7
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.
VRF Selection Based on Source IP Address
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)
IPv4 Packet IPv4 Packet
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
CSC-PE CSC-CECSC-PECSC-CE
7/31/2019 Supplemental Content Chp7
33/36
697 Chapter 7: MPLS VPN
VLAN interfaces from the PBR CE router to the PE router and map a VRF to each VLAN
interface. This solution does require an extra CE router for the PBR, though. Figure 7-21 gives an
overview of this PBR solution.
Figure 7-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
7/31/2019 Supplemental Content Chp7
34/36
VRF Selection Based on Source IP Address
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
7/31/2019 Supplemental Content Chp7
35/36
699 Chapter 7: MPLS VPN
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
7/31/2019 Supplemental Content Chp7
36/36
VRF Selection Based on Source IP Address
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
Recommended