supplemental content chp7

1974_chp7ONLa.fm Page 665 Tuesday, November 14, 2006 9:54 AM 1974_chp7ONLa.fm Page 666 Tuesday, November 14, 2006 9:54 AM CHAPTER SUPPLEMENT MPLS VPN This online supplement of Chapter focuses on two important MPLS VPN developments The first one is Inter-Autonomous MPLS VPN Inter-Autonomous MPLS VPN is a concept whereby two MPLS VPN service provider networks interconnect to provide a seamless VPN service to their MPLS VPN customers, even though the customers have VPN sites that are connected to different MPLS VPN service providers The second important MPLS VPN development is Carrier’s Carrier (CsC) With CsC, one MPLS VPN service provider exists, and it has other service providers as MPLS VPN customers These other service providers in turn provide Internet services or MPLS VPN services to their customers At the end of this supplement, you will see an interesting feature called VRF Selection, whereby the CE-facing interface on the provider edge (PE) router no longer belongs to just one virtual routing/forwarding (VRF) instance First, however, this supplement discusses Border Gateway Protocol (BGP) sending IPv4 prefixes with an MPLS label BGP Advertising IPv4 Prefixes with a Label In Cisco IOS, BGP advertises labels by default for vpnv4 prefixes only Labels are not advertised by default for IPv4 (and IPv6) routes via either iBGP or eBGP If labels are to be advertised for anything other than vpnv4 routes, you need to configure the send-label keyword on the BGP neighbor command Example 7-1 shows the send-label keyword being used Labels are sent for IPv4 routes to BGP neighbor 10.200.254.2 Example 7-1 BGP neighbor Command with send-label Keyword ! router bgp bgp log-neig hbor-changes neighbor 10 200.254.2 remote-as nei ghbor 10.200.254.2 update -source Loopback0 ! addres s-family ipv4 neighbor 10 200.254.2 activate neigh bor 10.200.254.2 send-lab el no auto-summary no sync hronization exit-address- family ! 1974_chp7ONLa.fm Page 667 Tuesday, November 14, 2006 9:54 AM 667 Chapter 7: MPLS VPN Note the following on using an outbound route map to limit the number of routes that BGP advertises This is something that you can when deploying Inter-Autonomous MPLS VPN (see the next section, “Inter-Autonomous MPLS VPN”) or CsC (see the section “CsC”) On an external BGP (eBGP) session, you might want to filter certain routes and prevent them from being sent to the eBGP neighbor If the routes are Interior Gateway Protocol (IGP) routes that are being redistributed into BGP, you can filter when redistributing the IGP into BGP However, if you deploy the filtering on the eBGP session outbound with a route map, you must ensure that the label that is associated with the prefix is also sent When you are deploying an outbound route map on an eBGP neighbor and you allow certain prefixes through, these prefixes not have a label by default For the label to be advertised along with the prefix when the conditions are matched in an outbound route map, use the set mpls-label command in the route map Otherwise, the prefix might get through, but without the associated label Look at Example 7-2 The idea is to only advertise the prefix 10.10.100.3/32 The set mpls-label command in the route map ensures that the prefix 10.10.100.3/32 is sent with an MPLS label Example 7-2 BGP neighbor Command with Outbound Route Map ! router bgp 65002 no synch ronization bgp log-neighb or-changes network 10.10 100.3 mask 255.255.255.25 neighbor 10.10.4.1 remot e-as neighbor 10.10.4.1 route-map label out neig hbor 10.10.4.1 send-label no auto-summary ! access-li st permit 10.10.100.3 ro ute-map label permit 10 m atch ip address set mpl s-label ! When advertising IPv4 prefixes with a label, BGP by default sends an implicit NULL label for directly connected prefixes This means that penultimate hop popping (PHP) also occurs with BGP as the label advertisement protocol To have BGP advertise an explicit NULL label instead of an implicit NULL label, configure neighbor ip-address send-label explicit-null You might want to have the explicit NULL label as opposed to the implicit NULL label for quality of service (QoS) reasons Refer to Chapter 12, “MPLS and Quality of Service,” to learn how you can use the explicit NULL label to transport the QoS of the labeled packet Inter-Autonomous MPLS VPN VPN sites might not be connected to just one MPLS VPN network An MPLS VPN network is one autonomous system (AS) because internal BGP runs between all the PE routers It might be that one VPN has sites connecting to different autonomous systems, meaning different service 1974_chp7ONLa.fm Page 668 Tuesday, November 14, 2006 9:54 AM Inter-Autonomous MPLS VPN 668 providers In that case, the MPLS VPN service becomes Inter-Autonomous MPLS VPN Two or more autonomous systems have to be interconnected at some point to provide connectivity for the VPN sites in the different autonomous systems The two routers that provide the connectivity between the two autonomous systems are called the autonomous system boundary routers (ASBRs) With MPLS VPN, all the PE routers must have a peering via internal BGP (iBGP) Obviously, because Inter-Autonomous MPLS VPN deals with more than one service provider, this is not possible Service providers not run an iBGP session to BGP peers outside of their autonomous system The next sections show the solutions that provide connectivity for the VPNs across more than one AS Three solutions provide an Inter-Autonomous MPLS VPN service NOTE The three solutions are described in section 10 of RFC 4364 They are often referred to as Inter-Autonomous MPLS VPN option 10a, 10b, and 10c They are presented here in this order VRF-to-VRF With the VRF-to-VRF solution, the ASBRs that connect the two autonomous systems must be PE routers They are connected via a (sub)interface that is a VRF interface on both PE routers for each VPN that is shared between the two service providers Therefore, the VRFs are connected back to back on the ASBRs Figure 7-1 shows a schematic overview of this solution Figure 7-1 VRF-to-VRF CE CE Green VRF Green VRF MPLS VPN MPLS VPN Green VRF Red VRF CE Red VRF CE Blue VRF PE PE PE-ASBR Autonomous System PE-ASBR Red VRF Autonomous System CE CE Blue VRF Blue VRF 1974_chp7ONLa.fm Page 669 Tuesday, November 14, 2006 9:54 AM 669 Chapter 7: MPLS VPN Because the interfaces between the two ASBRs are VRF interfaces, the traffic between the ASBRs is plain, unlabeled IP traffic As with regular MPLS VPN, routing needs to occur across the VRF interface This can be any routing protocol that regular MPLS VPN supports, as the PE-CE routing protocol However, because the routing serves to exchange routes across the autonomous system border, service providers prefer eBGP, which is most likely to be seen in this solution This solution is simple and easy to understand, but it is not very scalable because you must use a (sub)interface for each shared VPN; therefore, it requires some work to set it up You not need new functionality for this solution The software that offers regular MPLS VPN provides Inter-Autonomous MPLS VPN with this solution In fact, the ASBR has no knowledge that it is doing Inter-Autonomous MPLS VPN The ASBR sees the other ASBR as a CE router, because the interface toward the other ASBR is a regular VRF interface eBGP Distribution of vpnv4 Routes with Label from AS to Neighboring AS Between Directly Connected eBGP Peers With this solution, the ASBR routers use external BGP to exchange vpnv4 or VPN-IPv4 routes with labels between them; they are directly connected to each other at the border of their AS The border routers must hold the vpnv4 routes, so they need to be PE routers If they are not PE routers, they must be route reflectors (RR) RRs hold the vpnv4 routes without having the VRF routing tables Look at Figure 7-2 for a schematic overview of this solution Figure 7-2 eBGP Distribution of vnpv4 Routes and Label iBGP for VPNv4 + Label iBGP for VPNv4 + Label eBGP for VPNv4 + Label MPLS VPN CE Red VRF PE MPLS VPN ASBR Autonomous System ASBR PE Autonomous System CE Red VRF The ASBRs not need to have the VRF routing tables as long as they have the vpnv4 routes in the BGP table The packets between the ASBRs are no longer IP packets; they are labeled Therefore, a label switched path (LSP) needs to exist between the ingress PE in the first AS to the egress PE router in the second AS That is why the vpnv4 routes are exchanged with labels on the 1974_chp7ONLa.fm Page 670 Tuesday, November 14, 2006 9:54 AM Inter-Autonomous MPLS VPN 670 eBGP session between the ASBRs Because eBGP takes care of the label exchange, Label Distribution Protocol (LDP) does not need to run between the ASBRs It is not necessary to have mpls ip configured on the interface toward the other ASBR For this scenario to work, the ASBR routers must run eBGP distribution of vpnv4 routes with a label eBGP sends vpnv4 routes with a label by default in Cisco IOS That means you not need to configure the send-label keyword on the eBGP neighbor command for the ASBR You just need to configure the BGP neighbor command for the eBGP neighbor under the address family vpnv4 of the router bgp process and activate the peer Figure 7-3 shows the packet forwarding between autonomous systems with this solution Figure 7-3 Packet Forwarding: eBGP Distribution of vnpv4 Routes and Label IGP Label IGP Label IPv4 Packet VPN Label VPN Label VPN Label IPv4 Packet IPv4 Packet IPv4 Packet MPLS VPN CE Red VRF PE MPLS VPN ASBR Autonomous System IPv4 Packet ASBR PE Autonomous System CE Red VRF The VPN label that AS uses is the label that the ASBR in AS assigns, which is the next hop for the vpnv4 routes that are advertised from AS to AS This is so unless next-hop-self is used on the ASBR of AS In that case, the ASBR in AS assigns a new VPN label to the vpnv4 route and advertises this VPN label to the PE routers in AS Therefore, the VPN label used in AS is either a label that the ASBR in AS assigns or a label that the ASBR in AS assigns, depending on whether next-hop-self is used on the ASBR of AS Missing VRF Problem on ASBR By default, a PE router drops the vpnv4 route if no attached VRF is importing the vpnv4 route on that PE router This is a nice behavior for regular MPLS VPN because unwanted vpnv4 routes are not stored on PE routers if no VRF imports the vpnv4 prefixes according to the route targets (RT) on the PE This behavior improves scalability in the MPLS VPN network However, for InterAutonomous MPLS VPN, the ASBRs need to have all the vpnv4 routes because some of them need to be advertised to the ASBR in the other AS, regardless of whether the ASBR has a VRF 1974_chp7ONLa.fm Page 671 Tuesday, November 14, 2006 9:54 AM 671 Chapter 7: MPLS VPN attached that is importing the vpnv4 route In Example 7-3, you can see the BGP debug message when a PE router receives a vpnv4 prefix when no attached VRF is importing the vpnv4 prefix Example 7-3 Denying a vpnv4 Route sydney#debug ip bgp vpnv4 unicast updates in BGP updates debugging is on (inbound) for address family: VPNv4 Unicast sydney# BGP(2): 10.200.254.2 rcvd UPDATE w/ attr: nexthop 10.200.254.2, origin ?, localpref 100, metric 0, extended community RT:2:2 BGP(2): 10.200.254.2 rcvd 2:2:10.140.1.1/32 DENIED due to: extended community not supported; Figure 7-4 shows a network with two autonomous systems exchanging red VPN routes The ASBR in autonomous system rejects red VPN routes because it does not have a VRF that imports the red vpnv4 routes The reason is that the ASBR does not connect to a red VPN site You can solve the problem by configuring no bgp default route-target filter on the ASBR As soon as you configure this command, the ASBR accepts and stores all vpnv4 routes Of course, if the ASBR does have a VRF importing the red VRF routes, the problem is not apparent for this VRF Figure 7-4 Missing VRF Problem No Red VRF Attached To This ASBR iBGP For VPNv4 + Label eBGP for VPNv4 + Label MPLS VPN CE Red VRF PE ASBR Autonomous System RCVD VPNv4 RD:X - DENIED Due To Extended Community Not Supported iBGP for VPNv4 + Label MPLS VPN ASBR Autonomous System PE CE Red VRF 1974_chp7ONLa.fm Page 672 Tuesday, November 14, 2006 9:54 AM Inter-Autonomous MPLS VPN 672 VRF interfaces are allowed on the ASBR, but they are not needed You need to configure a specific VRF when the ASBR is also a PE router for a specific VPN in the autonomous system Next-Hop-Self and eBGP Peer Neighbor Route On the ASBRs, you have the choice of whether to run next-hop-self When you run next-hop-self toward the iBGP neighbors in the AS, the ASBR must assign a label to all vpnv4 routes and advertise this label to the iBGP peers, or PE routers When you are not doing next-hop-self toward the iBGP neighbors, the next hop of the vpnv4 routes is the ASBR in the neighboring AS Therefore, the next-hop IP address of the neighboring ASBR must be known in the local AS Cisco IOS helps by automatically creating a /32 connected route on the local ASBR for the IP address of the common link on the neighboring ASBR This automatically created route is called the eBGP peer neighbor route and is created as soon as the eBGP neighbor under address family vpnv4 is configured Figure 7-5 shows the generation of this /32 route Figure 7-5 Generation of eBGP Peer Neighbor Route iBGP for VPNv4 + Label eBGP for VPNv4 + Label MPLS VPN CE Red VRF PE iBGP for VPNv4 + Label MPLS VPN ASBR Autonomous System ASBR x.x.x.x Autonomous System PE CE Red VRF Generates a x.x.x.x./32 Route You must make sure that the IGP advertises this route in the local autonomous system You can this by including the link in the IGP and making the interface toward the other ASBR passive, or you can configure redistribute connected under the IGP Of course, when you have next-hop-self on the local ASBR, the IGP does not need to advertise this route The advantage of not doing next-hop-self (and the peer neighbor route) is that the local ASBR does not put the VPN label for every vpnv4 route it receives from the remote ASBR, in its LFIB This improves scalability The outgoing label in the local ASBR is the implicit NULL label for all vpnv4 routes from the remote AS Also, the local ASBR does not need to assign a local label for each vpnv4 route because it is not the next hop for these vpnv4 routes 1974_chp7ONLa.fm Page 673 Tuesday, November 14, 2006 9:54 AM 673 Chapter 7: MPLS VPN Multihop eBGP Distribution of vpnv4 Routes with Label Between Source and Destination Autonomous Systems, with eBGP Distribution of IPv4 Routes with Label from AS to Neighboring AS The routers that are exchanging the vpnv4 routes with eBGP can be RRs that are connected to each other across an eBGP multihop session The ASBRs not need to be involved with exchanging or even storing vpnv4 prefixes anymore In fact, the two autonomous systems 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 not like to run an IGP between their AS and the other AS They also dislike running LDP to the other AS That is why eBGP with label exchange for IPv4 prefixes comes in handy here BGP has proven to be successful and scalable for interdomain routing The ASBRs exchange the /32 IPv4 PE loopback prefixes and associated label However, because an LSP needs to exist from each PE in the local AS to each PE in the remote AS, you need to advertise the remote /32 IPv4 PE loopback prefixes to all the PE routers in the local AS To achieve this, advertise the /32 IPv4 prefixes to the IGP of the local AS To limit the redistribution from eBGP into the IGP to the /32 IPv4 PE loopback prefixes, configure route maps on the ASBRs Figure 7-6 shows a schematic overview of the solution, where the IPv4 /32 PE prefixes are redistributed from IGP into eBGP and vice versa on the ASBRs 1974_chp7ONLa.fm Page 674 Tuesday, November 14, 2006 9:54 AM Inter-Autonomous MPLS VPN Figure 7-6 674 Multihop eBGP Distribution of vpnv4 Prefixes and Label RR CE 4+ iBG eBGP For IPv4 + Label Nv VP l or P f Labe RR + Next -hop-unchanged iBG Pf or La VPN be v4 l + Multihop eBGP For VPNv4 + Label PE ASBR ASBR PE Red VRF CE Red VRF MPLS VPN Autonomous System MPLS VPN Autonomous System Redistribution of /32 IPv4 PE Loopback Prefixes From eBGP Into IGP and Vice Versa Another way to get the /32 IPv4 PE loopback prefixes to all the PE routers is to advertise the /32 IPv4 PE loopback prefixes (and a label) via iBGP This means that iBGP must send IPv4 prefixes with a label The advertisement of these prefixes and the label via iBGP is most likely the preferred way of getting the IPv4 prefixes from another AS into your own AS Advertising external prefixes into your AS via BGP is much more acceptable than advertising them into your own IGP 1974_chp7ONLa.fm Page 686 Tuesday, November 14, 2006 9:54 AM CsC Figure 7-14 686 Overview of CsC Carrier’s Carrier (CSC) MPLS VPN Network MPLS CSC-PE CSC-PE CSC-CE CSC-CE Carrier Site A Carrier Site B BGP ASBR Customer Site A ASBR Customer Site A Customer Site B Customer Site B MPLS is extended to the customer edge (CE) router, which means a label distribution protocol is needed between the PE—across the VRF interface—and the CE routers This can be achieved by any IGP that is supported on VRF interfaces together with LDP for the label distribution, or it can be eBGP for IPv4 routes with label exchange 1974_chp7ONLa.fm Page 687 Tuesday, November 14, 2006 9:54 AM 687 Chapter 7: MPLS VPN You can see one larger carrier, the CsC, providing MPLS VPN services to the smaller carriers and MPLS extended to include the CE routers of the smaller carriers More routers from the carriers might be running MPLS This is discussed further in the later section “CsC Scenarios.” The customer sites are attached to the sites of the carriers by interfacing with ASBRs The carriers carry the customer routes in BGP, because these routes are external to the carrier’s networks The BGP sessions between the sites of a carrier are usually iBGP if one AS number is used for one carrier It could technically be eBGP, too, but then one carrier needs to use multiple AS numbers For instance, one AS number can be used for each site of one carrier MPLS Across the VRF Interface The great benefit of CsC comes from running MPLS between the CSC-PE and CSC-CE The CSC-PE router no longer needs to look up the destination IP addresses in the VRF routing table because now it is label-switching traffic to and from the CSC-CE router The carriers are carrying their customer prefixes in BGP If the BGP next-hop addresses are advertised into their IGP (they should be), they are known to the CsC and are in the carrier VRF routing table on the CSC-PE routers The label switching of the customer traffic of the carriers is done based on the label that is assigned to the BGP next-hop prefixes Therefore, the CsC does not need to carry the customer BGP routes of the carriers in the VRF routing tables on the PE routers, but only the BGP next-hop prefixes This makes CsC a scalable solution and provides hierarchy Routing and Label Exchange Between CSC-PE and CSC-CE The routing and label exchange between the CSC-PE and CSC-CE can be a supported IGP that can run across a VRF interface, with LDP taking care of the label distribution Alternatively, it can be eBGP advertising IPv4 routes with labels across the VRF interface The choice is yours, but the Cisco IOS software on the CSC-PE must support MPLS on the VRF interface Furthermore, the CSC-CE must also support MPLS Because you now have a VRF interface on the CSC-PE router on which to receive and forward labeled packets, some enhancements were needed on top of the regular MPLS VPN solution LDP Across the VRF Interface LDP was enhanced so that it can run on the VRF interface on the PE router You enable LDP by configuring mpls ip on the VRF interface toward the CSC-CE router (You must enable LDP on the CSC-CE router too, of course.) The show mpls ldp commands have been enhanced with the 1974_chp7ONLa.fm Page 688 Tuesday, November 14, 2006 9:54 AM CsC 688 VRF keyword Look at Example 7-7 for the output of the LDP commands when LDP is configured on a VRF interface Example 7-7 Example of LDP Commands for CsC ! hostname london ! interface Ethernet0/1/2 ip vrf for warding cust-one ip addre ss 10.10.2.2 255.255.255 mpls ip ! show mpls ldp neighbor vrf cust-one london#s Peer LDP Ident: 10.10.100.1:0; Local LDP Ident 10.99.1.1:0 TCP connection: 10.10.100.1.646 - 10.99.1.1.12229 State: Oper; Msgs sent/rcvd: 6/8; Downstream Up time: 00:00:15 LDP discovery sources: Ethernet0/1/2, Src IP addr: 10.10.2.1 Addresses bound to peer LDP Ident: 10.10.2.1 10.10.100.1 192.168.1.1 10.88.1.1 show mpls ldp bindings vrf cust-one london#s lib entry: 10.10.2.0/24, rev local binding: label: 46 remote binding: lsr: 10.10.100.1:0, label: imp-null lib entry: 10.10.100.1/32, rev local binding: label: 45 remote binding: lsr: 10.10.100.1:0, label: imp-null lib entry: 10.10.101.1/32, rev remote binding: lsr: 10.10.100.1:0, label: 16 lib entry: 10.88.1.1/32, rev remote binding: lsr: 10.10.100.1:0, label: imp-null lib entry: 10.99.1.1/32, rev local binding: label: 32 lib entry: 192.168.1.0/24, rev remote binding: lsr: 10.10.100.1:0, label: imp-null show mpls ldp discovery vr f cust-one london#s Local LDP Identifier: 10.99.1.1:0 Discovery Sources: continues 1974_chp7ONLa.fm Page 689 Tuesday, November 14, 2006 9:54 AM 689 Chapter 7: MPLS VPN Example 7-7 Example of LDP Commands for CsC (Continued) Interfaces: Ethernet0/1/2 (ldp): xmit/recv LDP Id: 10.10.100.1:0 show mpls interfaces vrf c ust-one detail london#s VRF cust-one: Interface Ethernet0/1/2: IP labeling enabled (ldp) LSP Tunnel labeling not enabled BGP labeling not enabled MPLS operational MTU = 1500 eBGP Across the VRF Interface If you choose eBGP for IPv4 and label distribution between the CSC-PE and CSC-CE, you must configure the send-label keyword on the eBGP peer neighbor command under the address family IPv4 VRF under the router bgp process Look at Example 7-8, where eBGP and label distribution are enabled on the london PE and CE routers The CE prefix 10.10.100.1/32 is now showing an outgoing label of Pop Label toward the CE in the label forwarding information base (LFIB) on the PE router The remote VRF prefix 10.99.1.2/32 is now showing an outgoing label 33 on the CE router The show mpls interfaces command shows that BGP is taking care of the label distribution between the PE and CE and not LDP Example 7-8 eBGP for IPv4 and Label on a VRF Interface ! hostname london ! router bg p … ! address-family ipv4 vrf cust-one redistribut e connected neighbor 10.1 0.2.1 remote-as 65001 neig hbor 10.10.2.1 activate n eighbor 10.10.2.1 send-la bel exit-address-family ! show mpls interfaces vrf c ust-one detail london#s VRF cust-one: Interface Ethernet0/1/2: IP labeling not enabled 1974_chp7ONLa.fm Page 690 Tuesday, November 14, 2006 9:54 AM CsC 690 eBGP for IPv4 and Label on a VRF Interface (Continued) Example 7-8 LSP Tunnel labeling not enabled BGP labeling enabled MPLS operational MTU = 1500 show ip bgp 10.99.1.2 255 255.255.255 london-ce#s BGP routing table entry for 10.99.1.2/32, version 45 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 10.10.2.2 from 10.10.2.2 (10.200.254.2) Origin incomplete, localpref 100, valid, external, best, mpls labels in/out nolabel/33 show mpls forwarding-table vrf cust-one 10.10.100.1 london#s Local Outgoing Prefix Bytes Label Outgoing Label Label or VC or Tunnel Id Switched interface 45 Pop Label 10.10.100.1/32[V] Et0/1/2 Next Hop 10.10.2.1 LFIB When you deploy CsC, the LFIB shows that packets are forwarded labeled instead of unlabeled on the outgoing VRF interface on the PE router Also, the packets arriving from the CSC-CE router are already labeled The outgoing label stack for packets toward the remote PE is two labels—as usual with MPLS VPN The packets from the CSC-CE, arriving on the VRF interface on the CSCPE, are forwarded by a lookup in the LFIB table on the CSC-PE router, as they are labeled The top label is the label that is associated with the VRF prefix, advertised from the PE to the CE by LDP or eBGP With regular MPLS VPN, the packets from the CE router were always IP packets, so the forwarding was done based on an IP lookup of the destination IP address in the appropriate VRF routing table Example 7-9 shows LFIB entries on the CSC-PE router for VRF prefixes For the VRF prefix 10.10.100.1/32 learned from the London CSC-CE router, the outgoing label is now Pop Label With regular MPLS VPN, the outgoing label was No Label The Pop Label is the result of PHP, which is on by default between the CSC-PE and CSC-CE You can also see in Example 7-9 that packets are sent labeled from the CSC-CE router toward the CSC-PE router The prefix 10.99.1.2/32 shows up in the CEF table on the CSC-CE router with an outgoing label of 33 Regular MPLS VPN had no outgoing label toward the PE router The outgoing label stack on the ingress CSC-PE router for this VRF prefix consists of two labels Example 7-9 LFIB Entries on the CSC-PE show mpls forwarding-table vrf cust-one london#s Local Outgoing Prefix Bytes Label Outgoing Label Label or VC or Tunnel Id Switched interface 18 Pop Label 10.10.2.1/32[V] Et0/1/2 Next Hop 10.10.2.1 continues 1974_chp7ONLa.fm Page 691 Tuesday, November 14, 2006 9:54 AM 691 Chapter 7: MPLS VPN LFIB Entries on the CSC-PE (Continued) Example 7-9 32 Aggregate 10.99.1.1/32[V] cust-one 33 22 10.99.1.2/32[V] PO4/0/0 point2point 45 Pop Label 10.10.100.1/32[V] Et0/1/2 10.10.2.1 46 Aggregate 10.10.2.0/24[V] cust-one show mpls forwarding-table vrf cust-one 10.10.100.1 london#s Local Outgoing Prefix Bytes Label Outgoing Label Label or VC or Tunnel Id Switched interface 45 Pop Label 10.10.100.1/32[V] Et0/1/2 Next Hop 10.10.2.1 show ip cef 10.99.1.2 london-ce#s 10.99.1.2/32, version 648, epoch 0, cached adjacency 10.10.2.2 packets, 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, dependencies, recursive next hop 10.10.2.2, Ethernet1/1 via 10.10.2.2/32 valid cached adjacency tag rewrite with Et1/1, 10.10.2.2, tags imposed: {33} show mpls forwarding-table vrf cust-one 10.99.1.2 d etail london#s Local Outgoing Prefix Bytes Label Outgoing Label Label or VC or Tunnel Id Switched interface 33 22 10.99.1.2/32[V] PO4/0/0 Next Hop point2point MAC/Encaps=4/12, MRU=4466, Label Stack{19 22} 0F008847 0001300000016000 VPN route: cust-one No output feature configured Anti-Label Spoofing Mechanism When a VRF interface of a PE router that is running Cisco IOS receives a labeled packet, the PE checks whether the label was a locally assigned label for that VRF If it was not, the labeled packet is dropped With CsC, the packets from customers arriving on the PE router can be labeled, so it is important to check whether that label was indeed assigned to that VRF This effectively prevents one customer from spoofing packets with labels that are assigned to another customer, both connected to the same service provider 1974_chp7ONLa.fm Page 692 Tuesday, November 14, 2006 9:54 AM CsC 692 CsC Scenarios The possible CsC scenarios can be classified into three categories: ■ Only the CE routers run MPLS ■ All carrier C routers run MPLS ■ There is hierarchical MPLS VPN The first two scenarios differ from each other in the way that MPLS and BGP are deployed in the carrier networks In the third scenario, the carriers also run MPLS VPN Because the CsC and the carriers run MPLS VPN, this third scenario is commonly referred to as the Hierarchical MPLS VPN scenario No matter what scenario you deploy, the characteristic feature of CsC is that the VRF interface of the CSC-PE router must have labeled traffic Remember that for all three scenarios, an IGP and LDP can exist between the CSC-PE and CSC-CE, or eBGP and label distribution can exist between the CSC-PE and CSC-CE Only the CE Routers Run MPLS In this scenario, only the CSC-CE routers run MPLS All the customer routes are BGP routes For the C routers of the carrier network to forward the customer traffic, they must run BGP Therefore, all the C routers of the carrier network run iBGP, not just the border routers This is because every router in the carrier network is still forwarding IP packets Figure 7-15 shows that MPLS is extended to include the CSC-CE routers only iBGP runs between the sites of the carrier to advertise the customer (BGP) routes Figure 7-15 Schematic Overview of Information Exchange in the First CsC Scenario MPLS Carrier IGP Routes + Label Carrier IGP Routes + Label CsC Carrier Site A Carrier iBGP ASBR Site B iBGP CSC-CE CSC-PE CSC-PE iBGP VPNv4 Routes + Label iBGP VPNv4 Routes CSC-CE ASBR 1974_chp7ONLa.fm Page 693 Tuesday, November 14, 2006 9:54 AM 693 Chapter 7: MPLS VPN For an overview of the packet forwarding in this scenario, check out Figure 7-16 The packets have two MPLS labels in the CsC network This is no different from regular MPLS VPN However, the packets on the links between the CSC-PE and CSC-CE now have one label The result of this is that the CSC-PE does not need to perform an IP lookup of the destination IP address in the IP header anymore When a packet arrives on the VRF interface of the CSC-PE, it looks up the label in the LFIB and forwards the packet accordingly Figure 7-16 Schematic Overview of the Packet Forwarding in the First CsC Scenario CsC Carrier Site A Carrier iBGP ASBR Site B iBGP CSC-CE CSC-PE CSC-CE ASBR CSC-PE IGP CSC Label IPv4 Packet IGP Carrier Label CSC VPN Label IGP Carrier Label IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet All Carrier C Routers Run MPLS In this scenario, all the carrier C routers run MPLS Therefore, the carrier C routers forward traffic to the customers by performing a label lookup in the LFIB, not by performing an IP lookup Because the customer routes in the carrier network are known as BGP routes, and because the labeled traffic can be forwarded based on the label that is assigned to the BGP next hop, only the edge routers in the carrier network need to be running BGP This is already a great improvement over the first CsC scenario, in which all C routers were required to run BGP Look at Figure 7-17 for the schematic overview of this scenario 1974_chp7ONLa.fm Page 694 Tuesday, November 14, 2006 9:54 AM CsC Figure 7-17 694 Schematic Overview of Information Exchange in the Second CsC Scenario MPLS Carrier IGP Routes + Label Carrier IGP Routes + Label CsC Carrier Site A ASBR CSC-CE CSC-PE Carrier Site B ASBR CSC-CE CSC-PE iBGP VPNv4 Routes + Label iBGP IPv4 Routes Because all routers in the carrier network run MPLS, only the ASBR routers need to run BGP Figure 7-18 shows the packet forwarding in this scenario Figure 7-18 Schematic Overview of the Packet Forwarding in the Second CsC Scenario CsC Carrier Site A ASBR CSC-CE CSC-PE Carrier CSC-PE Site B ASBR CSC-CE IGP CSC Label IGP Carrier Label IGP Carrier Label CSC VPN Label IGP Carrier Label IGP Carrier Label IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet The difference between this and the first scenario is that the packets in the carrier network are labeled throughout the network 1974_chp7ONLa.fm Page 695 Tuesday, November 14, 2006 9:54 AM 695 Chapter 7: MPLS VPN Hierarchical MPLS VPN In this scenario, all the carrier C routers run MPLS, and there is MPLS VPN The carriers in turn have their own PE routers interfacing with their customer routers through a VRF interface The benefit of this scenario over the second CsC scenario is that now the customer routes are in their own VRF in the carrier network This is hierarchical MPLS VPN because the carriers are VPN customers of the CsC, and the customers are VPN customers of the carriers Figure 7-19 shows the schematic overview of this scenario Figure 7-19 Schematic Overview of Information Exchange in the Third CsC Scenario MPLS Carrier IGP Routes + Label Carrier IGP Routes + Label CsC Carrier Site A ASBR (PE) CSC-CE CSC-PE Carrier CSC-PE iBGP VPNv4 Routes + Label CSC-CE Site B ASBR (PE) iBGP IPv4 Routes + Label As with the second CsC scenario, MPLS is extended throughout the carrier network In this third scenario, the carriers provide MPLS VPN services toward their customers Therefore, the ASBR routers need to be PE routers The PE routers have VRF interfaces toward the CE routers of the customers As the carrier runs MPLS VPN, the carrier PE routers need to run iBGP, exchanging vpnv4 routes with a label From the carrier perspective, he is not doing anything else except running MPLS VPN From the perspective of the CsC, he is running MPLS VPN and label distribution across the VRF interfaces toward the carriers 1974_chp7ONLa.fm Page 696 Tuesday, November 14, 2006 9:54 AM VRF Selection Based on Source IP Address 696 You can see an overview of the packet forwarding in this scenario in Figure 7-20 Figure 7-20 Schematic Overview of the Packet Forwarding in the Third CsC Scenario CsC Carrier Site A ASBR CSC-CE CSC-PE Carrier CSC-PE Site B ASBR CSC-CE (PE) (PE) IGP CSC Label IGP Carrier Label IGP Carrier Label CSC VPN Label IGP Carrier Label IGP Carrier Label Carrier VPN Label Carrier VPN Label Carrier VPN Label Carrier VPN Label Carrier VPN Label IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet IPv4 Packet In the carrier network, the customer packets have two labels This is expected, because this is regular MPLS VPN In the CsC network, however, the packets have three labels The bottom label is the label that forwards the packet on the egress PE router The middle label is the CSC VPN label that forwards the packet out of the correct VRF interface on the CSC-PE router The top label is the IGP CSC label that forwards the packet to the correct egress CSC-PE router in the CsC network VRF Selection Based on Source IP Address When packets from the CE router enter the PE router with MPLS VPN, they are seen as coming from one and only one VRF This is based on the VRF configuration on the interface of the PE router toward the CE If the service provider, for example, has a cable broadband access network toward the CE routers, all CE routers can be in only one VRF If the cable provider wants to provide a service whereby he offers the opportunity for customers to get to the Internet via different Internet service providers (ISPs), he has to put an extra CE router in front of the PE router and route the traffic based on the source IP address to a different interface on the PE router This routing based on the source IP address can be done with policy-based routing (PBR) in Cisco IOS It entails that a PBR CE router sits in front of the PE router Multiple physical interfaces can exist between the PBR CE and the PE router However, an easier and cheaper method is to have multiple 1974_chp7ONLa.fm Page 697 Tuesday, November 14, 2006 9:54 AM 697 Chapter 7: MPLS VPN VLAN interfaces from the PBR CE router to the PE router and map a VRF to each VLAN interface This solution does require an extra CE router for the PBR, though Figure 7-21 gives an overview of this PBR solution Figure 7-21 PBR to PE Router ISP Broadband Access Network CE VRF cust-one AS 10.10.1.103 Policy-Based Routing to VLAN Interfaces PE VLAN 10 10.10.1.77 ISP VRF cust-one VLAN 11 VRF cust-two VLAN 12 VRF cust-three CE PE CE PE PE MPLS VPN VRF cust-two ISP 10.10.1.10 CE VRF cust-three The traffic from the three hosts on the broadband access network is policy-routed onto the corresponding VRF interface of the PE router The traffic is then routed on the PE through regular MPLS VPN toward one ISP in one VPN Another solution, VRF selection, offers the same functionality without the need for the extra router for the PBR in front of the PE router With that solution, the hosts on the broadband access network are directly connected to the PE router The interface on the PE router toward the hosts is put in the global routing table instead of a VRF However, that interface is configured with VRF selection, which enables the PE router to route the traffic to a particular VRF based on the source IP address Figure 7-22 shows the same network as Figure 7-21, but now with VRF Selection 1974_chp7ONLa.fm Page 698 Tuesday, November 14, 2006 9:54 AM VRF Selection Based on Source IP Address Figure 7-22 698 VRF Selection ISP Broadband Access Network CE VRF cust-one AS 10.10.1.103 PE ISP VRF Selection 10.10.1.77 Based On Source IP Address CE PE PE PE MPLS VPN VRF cust-two ISP 10.10.1.10 CE VRF cust-three After the traffic is routed to the chosen VRF, it is forwarded according to the VRF routing table on the PE router The traffic is then forwarded as regular MPLS VPN traffic in the backbone, with two labels on the packet as usual The interface on the PE router toward the hosts (or CE routers) is in the global routing table Therefore, the return traffic from the Internet (or the VRF sites) is forwarded according to the global routing table in the MPLS VPN network The traffic can be sent back by having the network statement of BGP cover the IP subnet of that broadband access interface on the PE router On the remote PE router, a static route in the VRF with a global next-hop IP address enables the traffic to be forwarded back to this PE router where VRF Selection is enabled Example 7-10 shows a sample configuration for VRF Selection based on source IP address The traffic from source IP address 10.10.1.103 is forwarded into VRF cust-one, and the traffic from source IP address 10.10.1.10 is forwarded into VRF cust-two The command to enable VRF Selection on the customer-facing interface is ip vrf select source The command to map source IP addresses to 1974_chp7ONLa.fm Page 699 Tuesday, November 14, 2006 9:54 AM 699 Chapter 7: MPLS VPN VRFs is vrf selection source source-IP-address source-IP-mask vrf vrf_name The command show ip vrf select demonstrates the configured VRF Selection policy Example 7-10 VRF Selection Based on Source IP Address ! hostname london ! ip vrf cust-one rd 1:1 route-target export 1:1 route-target import 1:1 ! ip vrf cust-two rd 2:2 route-target export 2:2 route-target import 2:2 ! interface Ethernet0/1/2 ip vrf select source ip address 10.10.1.1 255.255.255.0 ! vrf selection source 10.10.1.103 255.255.255.255 vrf cust-one vrf selection source 10.10.1.10 255.255.255.255 vrf cust-two ! router bgp … ! address-family ipv4 vrf cust-two redistribute connected no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf cust-one redistribute connected no auto-summary no synchronization exit-address-family ! show ip vrf select london#s VRF Selection Information Source IP-Address 10.10.1.103 10.10.1.10 Mask 255.255.255.255 255.255.255.255 Selected VRF Table cust-one cust-two 1974_chp7ONLa.fm Page 700 Tuesday, November 14, 2006 9:54 AM VRF Selection Based on Source IP Address 700 You can configure ip vrf receive vrf_name on the VRF Selection interface to announce the subnet directly into the VRF routing table In this way, the return traffic does not need to be routed back to this PE router according to the global routing table, because the subnet prefix is advertised as a vpnv4 prefix Example 7-11 shows how the command ip vrf receive is applied to announce the subnet 10.10.1.0/24 in the VRFs cust-one and cust-two of Example 7-10 Example 7-11 Announcement of the Interface Subnet into the VRFs ! interface Ethernet0/1/2 i p vrf select source ip vr f receive cust-one ip vrf receive cust-two ip addr ess 10.10.1.1 255.255.255 ! Traffic with an unknown source IP address from a VRF Selection interface is forwarded according to the global routing table on the PE router This allows malicious traffic if the source IP address is spoofed To prevent this, you can configure a VRF on the PE router to drop such traffic To drop this potentially malicious traffic, the VRF can route it to a NULL interface on the PE router with a static route Example 7-12 shows the extra VRF named drop configured on the PE router, which serves as a bucket to drop packets with an unknown source IP address Example 7-12 Drop VRF for Unknown Source IP Addresses ! ip vrf drop rd 9999:9999 ! vrf selection source 10.1 0.1.103 255.255.255.255 v rf cust-one vrf selection source 10.10.1.10 255.255 255.255 vrf cust-two vrf s election source 0.0.0.0 0.0.0 vrf drop ! ip route vrf drop 0.0.0.0 0.0.0.0 N ull0 ! show ip route vrf drop london#s Routing Table: drop Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 0.0.0.0 to network 0.0.0.0 S* 0.0.0.0/0 is directly connected, Null0 ...1974_chp7ONLa.fm Page 666 Tuesday, November 14, 2006 9:54 AM CHAPTER SUPPLEMENT MPLS VPN This online... neigh bor 10.200.254.2 send-lab el no auto-summary no sync hronization exit-address- family ! 1974_chp7ONLa.fm Page 667 Tuesday, November 14, 2006 9:54 AM 667 Chapter 7: MPLS VPN Note the following... that one VPN has sites connecting to different autonomous systems, meaning different service 1974_chp7ONLa.fm Page 668 Tuesday, November 14, 2006 9:54 AM Inter-Autonomous MPLS VPN 668 providers