7 C H A P T E R S U P P L E M E N T This online supplement of Chapter 7 focuses on two important developments. The first one is Inter-Autonomous. Inter-Autonomous is a concept whereby two service provider networks interconnect to provide a seamless VPN service to their customers, even though the customers have VPN sites that are connected to different service providers. The second important development is Carrier s Carrier (CsC). With CsC, one service provider exists, and it has other service providers as customers. These other service providers in turn provide Internet services or services to their customers. At the end of this supplement, you will see an interesting feature called Selection, whereby the -facing interface on the provider edge () router no longer belongs to just one virtual routing/forwarding () instance. First, however, this supplement discusses Border Gateway Protocol (BGP) sending IPv4 prefixes with an MPLS label. BGP Advertising IPv4 Prefixes with a In Cisco IOS, BGP advertises labels by default for vpnv4 prefixes only. s 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. s are sent for IPv4 routes to BGP neighbor 10.200.254.2. Example 7-1 BGP neighbor Command with send-label Keyword router bgp 1 bgp log-neighbor-changes neighbor 10.200.254.2 remote-as 1 neighbor 10.200.254.2 update-source Loopback0 address-family ipv4 neighbor 10.200.254.2 activate neighbor 10.200.254.2 send-label no auto-summary no synchronization exit-address-family
667 Chapter 7: 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 (see the next section, Inter-Autonomous ) or CsC (see the section CsC ). On an external BGP (ebgp) session, you might want to filter certain routes and prevent them from being sent to the ebgp neighbor. If the routes are Interior Gateway Protocol (IGP) routes that are being redistributed into BGP, you can filter when redistributing the IGP into BGP. However, if you deploy the filtering on the ebgp session outbound with a route map, you must ensure that the label that is associated with the prefix is also sent. When you are deploying an outbound route map on an ebgp neighbor and you allow certain prefixes through, these prefixes do not have a label by default. For the label to be advertised along with the prefix when the conditions are matched in an outbound route map, use the set mpls-label command in the route map. Otherwise, the prefix might get through, but without the associated label. Look at Example 7-2. The idea is to only advertise the prefix 10.10.100.3/32. The set mpls-label command in the route map ensures that the prefix 10.10.100.3/32 is sent with an MPLS label. Example 7-2 BGP neighbor Command with Outbound Route Map router bgp 65002 no synchronization bgp log-neighbor-changes network 10.10.100.3 mask 255.255.255.255 neighbor 10.10.4.1 remote-as 1 neighbor 10.10.4.1 route-map label out neighbor 10.10.4.1 send-label no auto-summary access-list 1 permit 10.10.100.3 route-map label permit 10 match ip address 1 set 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 VPN sites might not be connected to just one network. An network is one autonomous system (AS) because internal BGP runs between all the routers. It might be that one VPN has sites connecting to different autonomous systems, meaning different service
Inter-Autonomous 668 providers. In that case, the service becomes Inter-Autonomous. 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 (s). With, all the routers must have a peering via internal BGP (ibgp). Obviously, because Inter-Autonomous deals with more than one service provider, this is not possible. Service providers do not run an ibgp session to BGP peers outside of their autonomous system. The next sections show the solutions that provide connectivity for the VPNs across more than one AS. Three solutions provide an Inter-Autonomous service. NOTE The three solutions are described in section 10 of RFC 4364. They are often referred to as Inter-Autonomous option 10a, 10b, and 10c. They are presented here in this order. -to- With the -to- solution, the s that connect the two autonomous systems must be routers. They are connected via a (sub)interface that is a interface on both routers for each VPN that is shared between the two service providers. Therefore, the s are connected back to back on the s. Figure 7-1 shows a schematic overview of this solution. Figure 7-1 -to- Green Green Green Red - Red Blue - Red Autonomous System 1 Autonomous System 2 Blue Blue
669 Chapter 7: Because the interfaces between the two s are interfaces, the traffic between the s is plain, unlabeled IP traffic. As with regular, routing needs to occur across the interface. This can be any routing protocol that regular supports, as the - routing protocol. However, because the routing serves to exchange routes across the autonomous system border, service providers prefer ebgp, which is most likely to be seen in this solution. This solution is simple and easy to understand, but it is not very scalable because you must use a (sub)interface for each shared VPN; therefore, it requires some work to set it up. You do not need new functionality for this solution. The software that offers regular provides Inter-Autonomous with this solution. In fact, the has no knowledge that it is doing Inter-Autonomous. The sees the other as a router, because the interface toward the other is a regular interface. ebgp Distribution of vpnv4 Routes with from AS to Neighboring AS Between Directly Connected ebgp Peers With this solution, the 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 routers. If they are not routers, they must be route reflectors (RR). RRs hold the vpnv4 routes without having the routing tables. Look at Figure 7-2 for a schematic overview of this solution. Figure 7-2 ebgp Distribution of vnpv4 Routes and ibgp for VPNv4 + ebgp for VPNv4 + ibgp for VPNv4 + Red Autonomous System 1 Autonomous System 2 Red The s do not need to have the routing tables as long as they have the vpnv4 routes in the BGP table. The packets between the s are no longer IP packets; they are labeled. Therefore, a label switched path (LSP) needs to exist between the ingress in the first AS to the egress router in the second AS. That is why the vpnv4 routes are exchanged with labels on the
Inter-Autonomous 670 ebgp session between the s. Because ebgp takes care of the label exchange, Distribution Protocol (LDP) does not need to run between the s. It is not necessary to have mpls ip configured on the interface toward the other. For this scenario to work, the routers must run ebgp distribution of vpnv4 routes with a label. ebgp sends vpnv4 routes with a label by default in Cisco IOS. That means you do not need to configure the send-label keyword on the ebgp neighbor command for the. 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 IGP IGP VPN VPN VPN Red Autonomous System 1 Autonomous System 2 Red The VPN label that AS 2 uses is the label that the in AS 1 assigns, which is the next hop for the vpnv4 routes that are advertised from AS 1 to AS 2. This is so unless next-hop-self is used on the of AS 2. In that case, the in AS 2 assigns a new VPN label to the vpnv4 route and advertises this VPN label to the routers in AS 2. Therefore, the VPN label used in AS 2 is either a label that the in AS 2 assigns or a label that the in AS 1 assigns, depending on whether next-hop-self is used on the of AS 2. Missing Problem on By default, a router drops the vpnv4 route if no attached is importing the vpnv4 route on that router. This is a nice behavior for regular because unwanted vpnv4 routes are not stored on routers if no imports the vpnv4 prefixes according to the route targets (RT) on the. This behavior improves scalability in the network. However, for Inter- Autonomous, the s need to have all the vpnv4 routes because some of them need to be advertised to the in the other AS, regardless of whether the has a
671 Chapter 7: attached that is importing the vpnv4 route. In Example 7-3, you can see the BGP debug message when a router receives a vpnv4 prefix when no attached 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 in autonomous system 1 rejects red VPN routes because it does not have a that imports the red vpnv4 routes. The reason is that the does not connect to a red VPN site. You can solve the problem by configuring no bgp default route-target filter on the. As soon as you configure this command, the accepts and stores all vpnv4 routes. Of course, if the does have a importing the red routes, the problem is not apparent for this. Figure 7-4 Missing Problem No Red Attached To This ibgp For VPNv4 + ebgp for VPNv4 + ibgp for VPNv4 + Red Autonomous System 1 Autonomous System 2 Red RCVD VPNv4 RD:X --- DENIED Due To Extended Community Not Supported
Inter-Autonomous 672 interfaces are allowed on the, but they are not needed. You need to configure a specific when the is also a router for a specific VPN in the autonomous system. Next-Hop-Self and ebgp Peer Neighbor Route On the s, 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 must assign a label to all vpnv4 routes and advertise this label to the ibgp peers, or routers. When you are not doing next-hop-self toward the ibgp neighbors, the next hop of the vpnv4 routes is the in the neighboring AS. Therefore, the next-hop IP address of the neighboring must be known in the local AS. Cisco IOS helps by automatically creating a /32 connected route on the local for the IP address of the common link on the neighboring. 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 + ebgp for VPNv4 + ibgp for VPNv4 + Red Autonomous System 1 x.x.x.x Autonomous System 2 Red Generates a x.x.x.x./32 Route You must make sure that the IGP advertises this route in the local autonomous system. You can do this by including the link in the IGP and making the interface toward the other passive, or you can configure redistribute connected under the IGP. Of course, when you have next-hop-self on the local, 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 does not put the VPN label for every vpnv4 route it receives from the remote, in its LFIB. This improves scalability. The outgoing label in the local is the implicit NULL label for all vpnv4 routes from the remote AS. Also, the local does not need to assign a local label for each vpnv4 route because it is not the next hop for these vpnv4 routes.
673 Chapter 7: Multihop ebgp Distribution of vpnv4 Routes with Between Source and Destination Autonomous Systems, with ebgp Distribution of IPv4 Routes with 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 s do not need to be involved with exchanging or even storing vpnv4 prefixes anymore. In fact, the two autonomous systems do not need to be directly connected anymore; another autonomous system can exist between the two autonomous systems that exchange the vpnv4 prefixes. Directly connected autonomous systems or not, the ingress and egress 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 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 router is usually the loopback IP address of the router. An IGP can exchange these /32 IPv4 prefixes that build the end-to-end LSP or ingress--to-egress- LSP between the autonomous systems. LDP can take care of the label exchange in that case. However, service providers do not like to run an IGP between their AS and the other AS. They also dislike running LDP to the other AS. That is why ebgp with label exchange for IPv4 prefixes comes in handy here. BGP has proven to be successful and scalable for interdomain routing. The s exchange the /32 IPv4 loopback prefixes and associated label. However, because an LSP needs to exist from each in the local AS to each in the remote AS, you need to advertise the remote /32 IPv4 loopback prefixes to all the 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 loopback prefixes, configure route maps on the s. Figure 7-6 shows a schematic overview of the solution, where the IPv4 /32 prefixes are redistributed from IGP into ebgp and vice versa on the s.
Inter-Autonomous 674 Figure 7-6 Multihop ebgp Distribution of vpnv4 Prefixes and Multihop ebgp For VPNv4 + + Next -hop-unchanged ibgp for VPNv4 + RR ebgp For IPv4 + RR ibgp for VPNv4 + Red Autonomous System 1 Autonomous System 2 Red Redistribution of /32 IPv4 Loopback Prefixes From ebgp Into IGP and Vice Versa Another way to get the /32 IPv4 loopback prefixes to all the routers is to advertise the /32 IPv4 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.
675 Chapter 7: Look at Figure 7-7 for a schematic overview of the solution where ibgp advertises the IPv4 /32 prefixes (and label) in the other autonomous systems. Figure 7-7 Multihop ebgp Distribution of vpnv4 Prefixes and with ibgp for IPv4 and Multihop ebgp For VPNv4 + + Next-hop-unchanged ibgp for VPNv4 + RR ebgp For IPv4 + RR ibgp for VPNv4 + Red ibgp For IPv4 + ibgp For IPv4 + Red Autonomous System 1 Autonomous System 2 This second solution has the following four features: ibgp for vpnv4 + label (the default for ) 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.
Inter-Autonomous 676 Note, too, that the RRs have an ebgp session between them to exchange the vpnv4 prefixes. By default as usual for external BGP the RRs set the next hop of the vpnv4 prefixes to themselves. That means the RRs assign a label to the vpnv4 routes, and all inter-autonomous traffic passes through them. RRs are usually routers that have the specific function of reflecting routes and not forwarding traffic. To prevent the RRs from setting the next hop to themselves, configure the keyword next-hop-unchanged on the route reflectors on the BGP neighbor command under the vpnv4 address family to the multihop ebgp neighbor. The result is that the next hop of the vpnv4 BGP prefixes will be the originating router. Figure 7-8 shows the packet forwarding in the solution where the /32 IPv4 prefixes of the routers are redistributed into the IGP of the other AS. Figure 7-8 Packet Forwarding: Multihop ebgp Distribution of vpnv4 Prefixes and IGP ebgp IGP VPN VPN VPN RR RR Red Autonomous System 1 Autonomous System 2 Red The top label either the IGP label or the ebgp assigned label is always the label that is bound to the /32 prefix of the egress router. You can see that the packets have two labels at all times.
677 Chapter 7: Figure 7-9 shows the packet forwarding in the solution where ibgp advertises the /32 IPv4 prefixes of the routers in the other autonomous system. Figure 7-9 Packet Forwarding: Multihop ebgp Distribution of vpnv4 Prefixes and with ibgp for IPv4 and IGP IGP ebgp ibgp VPN VPN VPN RR RR Red Autonomous System 1 Autonomous System 2 Red 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 router assigns, because the RRs did not change the next hop of the vpnv4 route. The middle label is the label that the assigns (which depends on whether the next-hop-self is set); it gets the packet to the egress router. The top label is the IGP label in the local AS that gets the packet to the s. 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 ) 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.
Inter-Autonomous 678 Finally, you can have autonomous systems that share the same VPN but that are not directly connected to each other. Another MPLS provider might exist between the autonomous systems. For this to work, you need the following: An LSP from the ingress router to the egress router The /32 IPv4 loopback prefixes advertised into the remote autonomous system (preferably carried by ibgp and not by the IGP) Again, the /32 IPv4 loopback prefixes can be redistributed into the IGP of the other autonomous systems or they can be advertised by ibgp for IPv4 + label. Figure 7-10 shows the schematic overview of the solution where ibgp for IPv4 + label is used. Note that the middle AS (AS 3) runs only MPLS, not. Figure 7-10 Multihop ebgp Distribution of vpnv4 Prefixes and Through an MPLS Network MPLS Autonomous System 3 ibgp For IPv4 + ebgp for IPv4 + ebgp for IPv4 + Multihop ebgp For VPNv4 + ibgp for IPv4 + + Next-hop-unchanged ibgp for IPv4 + RR RR Red Red ibgp for VPNv4 + Autonomous System 1 ibgp for VPNv4 + Autonomous System 2
679 Chapter 7: 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 Through an MPLS Network IGP MPLS Autonomous System 3 ibgp VPN ebgp ebgp IGP IGP VPN VPN ibgp VPN VPN RR RR Red Red Autonomous System 1 Autonomous System 2 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 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 ) of the autonomous system. Nondirectly Connected ebgp Peers The s can be directly connected over several links in parallel. If you want to use more than one link to forward labeled traffic between the s, the ebgp session must be between the loopback IP addresses of the BGP peers. The ebgp session, however, is not directly connected
Inter-Autonomous 680 anymore; it becomes a multihop session. The local has to be able to reach the loopback IP address of the other. Because you probably do not want to run an IGP between the two service providers, you can just configure static routes for the remote loopback IP address. You must configure one such static route per link between the s, because you want to use each link to forward traffic on. The ebgp multihop session can be for vpnv4 prefixes and label or for IPv4 prefixes and label. Therefore, you can use the ebgp multihop session in all of the previously explained solutions. Figure 7-12 shows an example of two s with two links between them and an ebgp peering session for vpnv4 prefixes and label. You can find the configuration for this in Example 7-4. To make it work, configure disable-connected-check for the ebgp neighbor and mpls bgp forwarding on the interfaces toward the other. Figure 7-12 Multihop ebgp Session for vpnv4 Prefixes and Between s ebgp Multihop For VPNv4 + Loopback 0 10.10.100.1/32 Eth 1/2 10.10.90.2 Eth 1 10.10.90.1 Loopback 0 10.10.100.3/32 london--1 10.10.91.2 Eth 1/1 10.10.91.1 Eth 0 sydney--1 Autonomous System 65001 Autonomous System 2 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.0 mpls bgp forwarding interface Ethernet1/2 ip address 10.10.90.2 255.255.255.0 mpls bgp forwarding continues
681 Chapter 7: Example 7-4 Configuration for Nondirectly Connected ebgp Peers (Continued) router bgp 65001 no bgp default route-target filter bgp log-neighbor-changes neighbor 10.10.100.3 remote-as 2 neighbor 10.10.100.3 disable-connected-check neighbor 10.10.100.3 update-source Loopback0 address-family ipv4 neighbor 10.10.100.3 activate neighbor 10.10.100.3 send-community no auto-summary no synchronization network 10.10.100.1 mask 255.255.255.255 exit-address-family address-family vpnv4 neighbor 10.10.100.3 activate neighbor 10.10.100.3 send-community both exit-address-family ip route 10.10.100.3 255.255.255.255 Ethernet1/2 10.10.90.1 ip route 10.10.100.3 255.255.255.255 Ethernet1/1 10.10.91.1 hostname sydney-asbr-1 interface Loopback0 ip address 10.10.100.3 255.255.255.255 interface Ethernet0 ip address 10.10.91.1 255.255.255.0 mpls bgp forwarding interface Ethernet1 ip address 10.10.90.1 255.255.255.0 mpls bgp forwarding router bgp 2 no bgp default route-target filter bgp log-neighbor-changes neighbor 10.10.100.1 remote-as 65001 neighbor 10.10.100.1 disable-connected-check neighbor 10.10.100.1 update-source Loopback0
Inter-Autonomous 682 Example 7-4 Configuration for Nondirectly Connected ebgp Peers (Continued) address-family ipv4 neighbor 10.10.100.1 activate no auto-summary no synchronization exit-address-family address-family vpnv4 neighbor 10.10.100.1 activate neighbor 10.10.100.1 send-community both exit-address-family ip route 10.10.100.1 255.255.255.255 Ethernet1 10.10.90.2 ip route 10.10.100.1 255.255.255.255 Ethernet0 10.10.91.2 Example 7-5 shows that BGP is the label advertising protocol on the interfaces between the two s. The cust-one prefix 10.99.1.2/32 learned on the london-asbr-1 router is recursive to the loopback IP address 10.10.100.3 of the sydney-asbr-1 router. Example 7-5 Verifying Nondirectly Connected ebgp Peers sydney-asbr-1#show mpls interfaces detail 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#show ip bgp vpnv4 rd 1:1 10.99.1.2 BGP routing table entry for 1:1:10.99.1.2/32, version 89 Paths: (1 available, best #1, table cust-one) continues
683 Chapter 7: Example 7-5 Verifying Nondirectly Connected ebgp Peers (Continued) Advertised to update-groups: 1 2 1 10.10.100.3 from 10.10.100.3 (10.10.100.33) Origin incomplete, localpref 100, valid, external, best Extended Community: RT:1:1 0x8800:32768:0 0x8801:42:128000 0x8802:65280:256 0x8803:65281:1514, mpls labels in/out 34/26 london-asbr-1#show ip cef vrf cust-one 10.99.1.2 10.99.1.2/32, version 26, epoch 0, per-destination sharing 0 packets, 0 bytes tag information set, all rewrites owned local tag: 34 fast tag rewrite with Recursive rewrite via 10.10.100.3/32, tags imposed {26} via 10.10.100.3, 0 dependencies, recursive next hop 10.10.90.1, Ethernet1/2 via 10.10.100.3/32 (Default) valid adjacency tag rewrite with Recursive rewrite via 10.10.100.3/32, tags imposed {26} Recursive load sharing using 10.10.100.3/32. RT Rewrite When two service providers perform Inter-Autonomous, 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 router. As such, each service provider can keep its own policy regarding the RT assignment. The service provider needs to configure a route map toward the other service provider. This route map allows deletion of the RT and replacement with a new one. RT rewrite is supported both in the inbound and outbound directions. Therefore, you can use an inbound or an outbound route map to replace the RT. The set extcomm-list extended-community-list-number delete command and the set extcommunity rt extended-community-value [additive] command replace the RT. Look at Example 7-6 and Figure 7-13, where the sydney 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 in AS 2, the RT on the vpnv4 prefix is 2:1.
Inter-Autonomous 684 Figure 7-13 RT Rewrite ibgp for VPNv4 + ebgp for VPNv4 + ibgp for VPNv4 + sydney-as-1 Rewrite RT 1:1 to RT 2:1 sydney-as-2 10.10.100.1/32 RT 1:1 10.10.100.1/32 RT 2:1 10.10.100.1/32 RT 2:1 Autonomous System 1 Autonomous System 2 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 continues
685 Chapter 7: Example 7-6 RT Rewrite (Continued) sydney-as-1#show ip bgp vpnv4 all 10.10.100.1 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#show ip bgp vpnv4 all 10.10.100.1 BGP routing table entry for 1:1:10.10.100.1/32, version 10 Paths: (1 available, best #1, no table) Flag: 0xA00 Not advertised to any peer 1 65001 10.10.4.1 from 10.10.4.1 (192.168.99.1) Origin IGP, localpref 100, valid, external, best Extended Community: RT:2:1, mpls labels in/out nolabel/33 CsC CsC is a solution involving a carrier (named the Carrier s Carrier) providing services to other carriers or service providers. This can be done by using regular. However, because every service provider is carrying a huge number of customer routes and the CsC is to provide 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 router (CSC-) in the MPLS domain. Figure 7-14 has an overview of CsC.
CsC 686 Figure 7-14 Overview of CsC Carrier s Carrier (CSC) Network CSC- MPLS CSC- CSC- CSC- Carrier 1 Site A BGP Carrier 1 Site B Customer 1 Site A Customer 2 Site A Customer 1 Site B Customer 2 Site B MPLS is extended to the customer edge () router, which means a label distribution protocol is needed between the across the interface and the routers. This can be achieved by any IGP that is supported on interfaces together with LDP for the label distribution, or it can be ebgp for IPv4 routes with label exchange.
687 Chapter 7: You can see one larger carrier, the CsC, providing services to the smaller carriers and MPLS extended to include the 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 s. 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 Interface The great benefit of CsC comes from running MPLS between the CSC- and CSC-. The CSC- router no longer needs to look up the destination IP addresses in the routing table because now it is label-switching traffic to and from the CSC- 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 routing table on the CSC- 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 routing tables on the routers, but only the BGP next-hop prefixes. This makes CsC a scalable solution and provides hierarchy. Routing and Exchange Between CSC- and CSC- The routing and label exchange between the CSC- and CSC- can be a supported IGP that can run across a interface, with LDP taking care of the label distribution. Alternatively, it can be ebgp advertising IPv4 routes with labels across the interface. The choice is yours, but the Cisco IOS software on the CSC- must support MPLS on the interface. Furthermore, the CSC- must also support MPLS. Because you now have a interface on the CSC- router on which to receive and forward labeled packets, some enhancements were needed on top of the regular solution. LDP Across the Interface LDP was enhanced so that it can run on the interface on the router. You enable LDP by configuring mpls ip on the interface toward the CSC- router. (You must enable LDP on the CSC- router too, of course.) The show mpls ldp commands have been enhanced with the
CsC 688 keyword. Look at Example 7-7 for the output of the LDP commands when LDP is configured on a interface. Example 7-7 Example of LDP Commands for CsC hostname london interface Ethernet0/1/2 ip vrf forwarding cust-one ip address 10.10.2.2 255.255.255.0 mpls ip london#show mpls ldp neighbor vrf cust-one Peer LDP Ident: 10.10.100.1:0; Local LDP Ident 10.99.1.1:0 TCP connection: 10.10.100.1.646-10.99.1.1.12229 State: Oper; Msgs sent/rcvd: 6/8; Downstream Up time: 00:00:15 LDP discovery sources: Ethernet0/1/2, Src IP addr: 10.10.2.1 Addresses bound to peer LDP Ident: 10.10.2.1 10.10.100.1 192.168.1.1 10.88.1.1 london#show mpls ldp bindings vrf cust-one lib entry: 10.10.2.0/24, rev 2 local binding: label: 46 remote binding: lsr: 10.10.100.1:0, label: imp-null lib entry: 10.10.100.1/32, rev 4 local binding: label: 45 remote binding: lsr: 10.10.100.1:0, label: imp-null lib entry: 10.10.101.1/32, rev 8 remote binding: lsr: 10.10.100.1:0, label: 16 lib entry: 10.88.1.1/32, rev 7 remote binding: lsr: 10.10.100.1:0, label: imp-null lib entry: 10.99.1.1/32, rev 6 local binding: label: 32 lib entry: 192.168.1.0/24, rev 9 remote binding: lsr: 10.10.100.1:0, label: imp-null london#show mpls ldp discovery vrf cust-one Local LDP Identifier: 10.99.1.1:0 Discovery Sources: continues
689 Chapter 7: Example 7-7 Example of LDP Commands for CsC (Continued) Interfaces: Ethernet0/1/2 (ldp): xmit/recv LDP Id: 10.10.100.1:0 london#show mpls interfaces vrf cust-one detail 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 Interface If you choose ebgp for IPv4 and label distribution between the CSC- and CSC-, you must configure the send-label keyword on the ebgp peer neighbor command under the address family IPv4 under the router bgp process. Look at Example 7-8, where ebgp and label distribution are enabled on the london and routers. The prefix 10.10.100.1/32 is now showing an outgoing label of Pop toward the in the label forwarding information base (LFIB) on the router. The remote prefix 10.99.1.2/32 is now showing an outgoing label 33 on the router. The show mpls interfaces command shows that BGP is taking care of the label distribution between the and and not LDP. Example 7-8 ebgp for IPv4 and on a Interface hostname london router bgp 1 address-family ipv4 vrf cust-one redistribute connected neighbor 10.10.2.1 remote-as 65001 neighbor 10.10.2.1 activate neighbor 10.10.2.1 send-label exit-address-family london#show mpls interfaces vrf cust-one detail cust-one: Interface Ethernet0/1/2: IP labeling not enabled
CsC 690 Example 7-8 ebgp for IPv4 and on a Interface (Continued) LSP Tunnel labeling not enabled BGP labeling enabled MPLS operational MTU = 1500 london-ce#show ip bgp 10.99.1.2 255.255.255.255 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#show mpls forwarding-table vrf cust-one 10.10.100.1 Local Outgoing Prefix Bytes Outgoing Next Hop or VC or Tunnel Id Switched interface 45 Pop 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1 LFIB When you deploy CsC, the LFIB shows that packets are forwarded labeled instead of unlabeled on the outgoing interface on the router. Also, the packets arriving from the CSC- router are already labeled. The outgoing label stack for packets toward the remote is two labels as usual with. The packets from the CSC-, arriving on the interface on the CSC-, are forwarded by a lookup in the LFIB table on the CSC- router, as they are labeled. The top label is the label that is associated with the prefix, advertised from the to the by LDP or ebgp. With regular, the packets from the router were always IP packets, so the forwarding was done based on an IP lookup of the destination IP address in the appropriate routing table. Example 7-9 shows LFIB entries on the CSC- router for prefixes. For the prefix 10.10.100.1/32 learned from the London CSC- router, the outgoing label is now Pop. With regular, the outgoing label was No. The Pop is the result of PHP, which is on by default between the CSC- and CSC-. You can also see in Example 7-9 that packets are sent labeled from the CSC- router toward the CSC- router. The prefix 10.99.1.2/32 shows up in the F table on the CSC- router with an outgoing label of 33. Regular had no outgoing label toward the router. The outgoing label stack on the ingress CSC- router for this prefix consists of two labels. Example 7-9 LFIB Entries on the CSC- london#show mpls forwarding-table vrf cust-one Local Outgoing Prefix Bytes Outgoing Next Hop or VC or Tunnel Id Switched interface 18 Pop 10.10.2.1/32[V] 0 Et0/1/2 10.10.2.1 continues
691 Chapter 7: Example 7-9 LFIB Entries on the CSC- (Continued) 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 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#show mpls forwarding-table vrf cust-one 10.10.100.1 Local Outgoing Prefix Bytes Outgoing Next Hop or VC or Tunnel Id Switched interface 45 Pop 10.10.100.1/32[V] 0 Et0/1/2 10.10.2.1 london-ce#show ip cef 10.99.1.2 10.99.1.2/32, version 648, epoch 0, cached adjacency 10.10.2.2 0 packets, 0 bytes tag information set local tag: BGP route head fast tag rewrite with Et1/1, 10.10.2.2, tags imposed: {33} via 10.10.2.2, 0 dependencies, recursive next hop 10.10.2.2, Ethernet1/1 via 10.10.2.2/32 valid cached adjacency tag rewrite with Et1/1, 10.10.2.2, tags imposed: {33} london#show mpls forwarding-table vrf cust-one 10.99.1.2 detail Local Outgoing Prefix Bytes Outgoing Next Hop 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, Stack{19 22} 0F008847 0001300000016000 VPN route: cust-one No output feature configured Anti- Spoofing Mechanism When a interface of a router that is running Cisco IOS receives a labeled packet, the checks whether the label was a locally assigned label for that. If it was not, the labeled packet is dropped. With CsC, the packets from customers arriving on the router can be labeled, so it is important to check whether that label was indeed assigned to that. This effectively prevents one customer from spoofing packets with labels that are assigned to another customer, both connected to the same service provider.
CsC 692 CsC Scenarios The possible CsC scenarios can be classified into three categories: Only the routers run MPLS. All carrier C routers run MPLS. There is hierarchical. 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. Because the CsC and the carriers run, 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 interface of the CSC- router must have labeled traffic. Remember that for all three scenarios, an IGP and LDP can exist between the CSC- and CSC-, or ebgp and label distribution can exist between the CSC- and CSC-. Only the Routers Run MPLS In this scenario, only the CSC- 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- 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 1 IGP Routes + Carrier 1 IGP Routes + Carrier 1 Site A CsC Carrier 1 Site B ibgp ibgp CSC- CSC- CSC- CSC- ibgp VPNv4 Routes + ibgp VPNv4 Routes
693 Chapter 7: 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. However, the packets on the links between the CSC- and CSC- now have one label. The result of this is that the CSC- does not need to perform an IP lookup of the destination IP address in the IP header anymore. When a packet arrives on the interface of the CSC-, 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 Carrier 1 Site A ibgp CsC Carrier 1 Site B ibgp CSC- CSC- CSC- CSC- IGP CSC IGP Carrier 1 CSC VPN IGP Carrier 1 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.
CsC 694 Figure 7-17 Schematic Overview of Information Exchange in the Second CsC Scenario MPLS Carrier 1 IGP Routes + Carrier 1 IGP Routes + Carrier 1 Site A CsC Carrier 1 Site B CSC- CSC- CSC- CSC- ibgp VPNv4 Routes + ibgp IPv4 Routes Because all routers in the carrier network run MPLS, only the 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 Carrier 1 Site A CsC Carrier 1 Site B CSC- CSC- CSC- CSC- IGP CSC IGP Carrier 1 IGP Carrier 1 CSC VPN IGP Carrier 1 IGP Carrier 1 The difference between this and the first scenario is that the packets in the carrier network are labeled throughout the network.
695 Chapter 7: Hierarchical In this scenario, all the carrier C routers run MPLS, and there is. The carriers in turn have their own routers interfacing with their customer routers through a interface. The benefit of this scenario over the second CsC scenario is that now the customer routes are in their own in the carrier network. This is hierarchical 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 1 IGP Routes + Carrier 1 IGP Routes + Carrier 1 Site A CsC Carrier 1 Site B CSC- CSC- CSC- CSC- () ibgp VPNv4 Routes + () ibgp IPv4 Routes + As with the second CsC scenario, MPLS is extended throughout the carrier network. In this third scenario, the carriers provide services toward their customers. Therefore, the routers need to be routers. The routers have interfaces toward the routers of the customers. As the carrier runs, the carrier routers need to run ibgp, exchanging vpnv4 routes with a label. From the carrier perspective, he is not doing anything else except running. From the perspective of the CsC, he is running and label distribution across the interfaces toward the carriers.
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 Carrier 1 Site A CsC Carrier 1 Site B CSC- CSC- CSC- CSC- () () IGP CSC IGP Carrier 1 IGP Carrier 1 CSC VPN IGP Carrier 1 IGP Carrier 1 Carrier 1 VPN Carrier 1 VPN Carrier 1 VPN Carrier 1 VPN Carrier 1 VPN In the carrier network, the customer packets have two labels. This is expected, because this is regular. In the CsC network, however, the packets have three labels. The bottom label is the label that forwards the packet on the egress router. The middle label is the CSC VPN label that forwards the packet out of the correct interface on the CSC- router. The top label is the IGP CSC label that forwards the packet to the correct egress CSC- router in the CsC network. Selection Based on Source IP Address When packets from the router enter the router with, they are seen as coming from one and only one. This is based on the configuration on the interface of the router toward the. If the service provider, for example, has a cable broadband access network toward the routers, all routers can be in only one. 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 router in front of the router and route the traffic based on the source IP address to a different interface on the 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 router sits in front of the router. Multiple physical interfaces can exist between the PBR and the router. However, an easier and cheaper method is to have multiple
697 Chapter 7: VLAN interfaces from the PBR router to the router and map a to each VLAN interface. This solution does require an extra router for the PBR, though. Figure 7-21 gives an overview of this PBR solution. Figure 7-21 PBR to Router Broadband Access Network AS 1 ISP 1 cust-one 10.10.1.103 Policy-Based Routing to VLAN Interfaces VLAN 10 cust-one ISP 2 10.10.1.77 VLAN 11 VLAN 12 cust-two cust-three cust-two ISP 3 10.10.1.10 cust-three The traffic from the three hosts on the broadband access network is policy-routed onto the corresponding interface of the router. The traffic is then routed on the through regular toward one ISP in one VPN. Another solution, selection, offers the same functionality without the need for the extra router for the PBR in front of the router. With that solution, the hosts on the broadband access network are directly connected to the router. The interface on the router toward the hosts is put in the global routing table instead of a. However, that interface is configured with selection, which enables the router to route the traffic to a particular based on the source IP address. Figure 7-22 shows the same network as Figure 7-21, but now with Selection.
Selection Based on Source IP Address 698 Figure 7-22 Selection Broadband Access Network AS 1 ISP 1 cust-one 10.10.1.103 ISP 2 10.10.1.77 Selection Based On Source IP Address cust-two ISP 3 10.10.1.10 cust-three After the traffic is routed to the chosen, it is forwarded according to the routing table on the router. The traffic is then forwarded as regular traffic in the backbone, with two labels on the packet as usual. The interface on the router toward the hosts (or routers) is in the global routing table. Therefore, the return traffic from the Internet (or the sites) is forwarded according to the global routing table in the 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 router. On the remote router, a static route in the with a global next-hop IP address enables the traffic to be forwarded back to this router where Selection is enabled. Example 7-10 shows a sample configuration for Selection based on source IP address. The traffic from source IP address 10.10.1.103 is forwarded into cust-one, and the traffic from source IP address 10.10.1.10 is forwarded into cust-two. The command to enable Selection on the customer-facing interface is ip vrf select source. The command to map source IP addresses to
699 Chapter 7: s is vrf selection source source-ip-address source-ip-mask vrf vrf_name. The command show ip vrf select demonstrates the configured Selection policy. Example 7-10 Selection Based on Source IP Address hostname london ip vrf cust-one rd 1:1 route-target export 1:1 route-target import 1:1 ip vrf cust-two rd 2:2 route-target export 2:2 route-target import 2:2 interface Ethernet0/1/2 ip vrf select source ip address 10.10.1.1 255.255.255.0 vrf selection source 10.10.1.103 255.255.255.255 vrf cust-one vrf selection source 10.10.1.10 255.255.255.255 vrf cust-two router bgp 1 address-family ipv4 vrf cust-two 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 london#show ip vrf select Selection Information Source IP-Address Mask Selected Table 10.10.1.103 255.255.255.255 cust-one 10.10.1.10 255.255.255.255 cust-two
Selection Based on Source IP Address 700 You can configure ip vrf receive vrf_name on the Selection interface to announce the subnet directly into the routing table. In this way, the return traffic does not need to be routed back to this 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 s cust-one and cust-two of Example 7-10. Example 7-11 Announcement of the Interface Subnet into the s interface Ethernet0/1/2 ip vrf select source ip vrf receive cust-one ip vrf receive cust-two ip address 10.10.1.1 255.255.255.0 Traffic with an unknown source IP address from a Selection interface is forwarded according to the global routing table on the router. This allows malicious traffic if the source IP address is spoofed. To prevent this, you can configure a on the router to drop such traffic. To drop this potentially malicious traffic, the can route it to a NULL interface on the router with a static route. Example 7-12 shows the extra named drop configured on the router, which serves as a bucket to drop packets with an unknown source IP address. Example 7-12 Drop for Unknown Source IP Addresses ip vrf drop rd 9999:9999 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 vrf selection source 0.0.0.0 0.0.0.0 vrf drop ip route vrf drop 0.0.0.0 0.0.0.0 Null0 london#show ip route vrf drop Routing Table: drop Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 0.0.0.0 to network 0.0.0.0 S* 0.0.0.0/0 is directly connected, Null0