W4_JTO_Ph2_Datacom_IT-part-6.pdf

JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN 6 Cisco Router Configuration : MPLS based layer-3 VPN 6.1 Learning objectives The objective of this chapter is to understand i) MPLS VPN reference architecture...

JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN 6 Cisco Router Configuration : MPLS based layer-3 VPN 6.1 Learning objectives The objective of this chapter is to understand i) MPLS VPN reference architecture ii) Routing in an MPLS VPN Network iii) MPLS VPN Attributes iv) VRF v) MPLS-VPN Cisco IOS Configuration 6.2 Introduction Layer 3 VPN is without doubt the MPLS application that has caused the most ink to flow. RFC 2547 proposes a peer architecture in which customer edge (CE) routers exchange routes with service provider edge routers (universally called PE, for provider edge). Unlike a Frame Relay or ATM VPN service, there are no point-to-point connections between customer sites. Figure shows an MPLS-VPN reference architecture, with two different VPNs. Customer sites have a CE router that connects to service provider PE routers. PE devices are connected by LSRs. A single PE can peer with CEs that belong to different customers, as is the case for PE A. To provide backup routes, a CE can also peer with different PEs that belong to the same, or even to different, service providers. Sites in a VPN can communicate only with other sites in the same VPN. Standard IP traffic runs over the CE- PE link, so this link cannot be shared with other customer traffic. (By the way, that is a very important point: The CE and PE do not exchange labels, or labeled packets.) This is identical to existing Layer 2 VPN networks, so an MPLS-VPN service requires no architecture change to the customer's network. 6.3 MPLS-VPN Reference Architecture JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 74 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN Figure 42: MPLS-VPN Reference Architecture Even though each site has just one link into the service provider cloud, thanks to the MPLS-VPN architecture, there can be a full-mesh connectivity between the sites. In fact, the intersite IP topology can be of arbitrary complexity. MPLS-VPN implementations default to full mesh and must be constrained to provide a more hierarchical connectivity model, such as hub and spoke. The MPLS-VPN model makes it easier to route between CEs, compared to the costly approach of using dedicated WAN connections between sites and the relative difficulty of routing effectively over such point-to-point networks. For CEs to communicate, the service provider needs to exchange (private and possibly overlapping) customer IP routes and carry packets to those routes across its network. MPLS provides a solution that supports customer address-space independence using a forwarding mechanism that uses a two-label hierarchy in which the inner label identifies the VPN and the outer label identifies the destination PE device. RFC 2547 mandates the use of the Border Gateway Protocol (BGP) to exchange prefixes and labels between PE devices and introduces some new attributes to provide this functionality. Speaking of BGP, how are customer routes advertised in an MPLS-VPN network? Figure shows that several different routing protocols are used. The following sequence explains the operation behind Figure 6.4 Routing in an MPLS VPN Network Figure 43: Routing in an MPLS VPN Network CE red1 advertises the 192.168.4.0/24 prefix to PE A. A CE can use static or dynamic routing (RIP, eBGP, or OSPF) to exchange routes with a PE. CE red1 runs eBGP. CE green2 uses RIPv2. PE A imports the prefixes announced by the CE into the route table for this VPN. If other interfaces on the same PE belong to the same VPN, routes are announced to the local peers. Each VPN has its own routing table. JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 75 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN PE A uses iBGP to announce reachability for each of its attached customer sites. In Figure PE A has one iBGP session with PE C for the red VPN and another with PE D for the green VPN. PE C imports the routes into the routing table used for the red VPN, and PE D imports the routes for the green VPN. The PEs are in a full iBGP mesh and each can run many different VPNs. PE C announces the 192.168.4.0 route to CE red2 using RIPv2. A show ip route command on CE red2 will show 192.168.4.0/24 with a next hop of 192.168.2.1, which is the address of PE C. Similarly, CE red1 has an entry for 192.168.3.0 with a next hop of 192.168.1.2. PE A's routing table for the red VPN has an entry for 192.168.4.0 through 192.168.1.1 and another entry for 191.168.3.0 with a next hop that points to PE C. This is where the MPLS-VPN magic occurs. PE C announces itself as the next hop for the 192.168.3.0 route. Because this is a BGP route, PE A will use another lookup to find the route and, this time, the next hop will be 10.0.0.2, which is the LSR. When traffic must go between sites, the CE forwards IP packets to the PE as it would to any other router. Figure shows a packet going from CE green1 to CE green2, following this sequence: PE A identifies the next hop (PE D) for this packet as a BGP neighbor. PE A first imposes a label, 22, that will identify the VPN routing table to PE D. This label was advertised by the neighbor, PE D, during the exchange of BGP prefixes, which happened some time before the preceding step. The packet must now travel across the MPLS network, so PE A imposes another label, 96, that identifies the next-hop LSR on the IGP path to PE D. This label was advertised by the downstream LSR (LSR B) from 10.0.0.2. Each LSR in the core swaps labels and forwards the packet as normal toward PE D. The penultimate hop pops the outer label. In Figure 4-14, there is only one hop to the egress LSR, so LSR B removes the outer label. PE D uses the remaining label, 22, to identify which VPN routing table to use for the packet, and then pops the label from the packet. PE D does an IP lookup in the VPN routing table to find the outgoing interface and then forwards the IP packet to CE green2, which will route it to its destination. JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 76 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN 6.5 Packet Flow in MPLS-VPN Network Figure 44: Packet Flow in MPLS-VPN Network It is very important to understand that the LSRs have no visibility of the VPN traffic. They forward labeled traffic along LSPs established by whatever routing protocol is running in the service provider core. Of course, this IGP can be completely different from the IGPs running on the CE-PE links. 6.6 MPLS-VPN Attributes Defining an MPLS VPN is harder than you might expect. For the longest time, the Cisco IOS implementation had no single number or string that would define a VPN in a network. Fortunately, a VPN ID has since been introduced to address this problem. Note that every VPN on a Cisco router has the following attributes: Dedicated interfaces, which can be logical or physical Dedicated routing table A local name and, optionally, a numeric ID Rules that determine how VPN routes are advertised to peer routers Route reachability within an MPLS VPN is established through the selective import of BGP routes. Several new extended attributes have been added to BGP in accordance with the specifications in RFC 2547. Figure shows how PEs exchange these attributes. iBGP Attribute Exchange JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 77 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN Figure 45: i-BGP Attribute Exchange The following are the most important BGP attributes: 6.6.1 route-target Each PE defines a numeric value, called a route-target, that is associated to all the routes it exports to its BGP peers. PEs also define another value used to filter incoming routes. In order for a route to be accepted, the route-target export value must match the import value at the receiving device. Note that the import and export values do not have to match, which allows topologies other than full mesh to be defined. The route-targets are carried in BGP updates. In Figure, PE A uses 100:1 for both export and import route- targets. PE C uses the same values, so routes from the red VPN sites will be exchanged between these two routers. 6.6.2 route-distinguisher A BGP attribute that is appended to private routes to make them globally unique. Consider a case in which two networks each use the 10.0.0.0/24 prefix and connect to the same service provider PE. The PE uses different virtual routing tables because the prefixes belong to different customers, so there is no conflict in address space when importing the routes into the service provider network. Now every PE that connects to a CE in the customer's VPN must receive reachability information for the 10.0.0.0/24 prefix. The PE announces the route to all its PE peers, but only those with the same VPN and matching route-target import it. The route-distinguisher (RD) is included in the routing exchange to make sure that each BGP peer treats the prefixes as belonging to different networks. Returning to Figure , the red VPN uses an RD of 100:1; the green VPN is configured for 200:1. Although not necessary, having the same RD throughout a VPN is better, for operational simplicity. MPLS-VPNs require private routing tables in each VPN so that they can peer with the CEs in the different domains. In Cisco jargon, these are called VRFs, as shown in Figure , and the standard routing table is called the global routing table. In the example given that described the operation of Figure, the VPN routing tables referenced in the text are VRFs. JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 78 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN VRFs Figure 46: Virtual Routing and Forwarding Table VRFs are populated by routing processes associated with each VPN. Note that in other implementations, separate processes run in each VPN, but Cisco IOS does a mix of both. BGP, for example, is a single process across the whole router, but there are independent OSPF processes for each VPN. LFIBs are populated using information from VRFs. Even though each VPN on a PE router has its very own VRF, no VRFs are required on CE routers. (There is an optional exception to this called, rather unimaginatively, multi- VRF CE, but the basic RFC 2547 scenario requires no such thing.) 6.7 MPLS-VPN Cisco IOS Configuration This section gives the extracts necessary to deploy a simple MPLS VPN. Example is the configuration of a PE. The underlying network topology is the same as used in the examples in Chapter. Example. MPLS-VPN PE Configuration ! Define a VRF for the VPN with route-target and r-ds ! R-T 101:1 is used for both import and export ip vrf RED rd 101:1 route-target both 101:1 interface Loopback0 ip address 12.0.0.3 255.255.255.255 no ip directed-broadcast ! Add each CE-PE link to the VRF ! Remember the IP address must be added after the VRF name JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 79 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN interface Ethernet1/0/0 ipvrf forwarding RED ip address 11.1.4.1 255.255.255.255 no ip directed-broadcast ! Core facing links interface FastEthernet0/0/0 ip address 192.168.1.3 255.255.255.0 tag-switching ip no ip directed-broadcast full-duplex no cdp enable ! Configure iBGP to the 2 remote PEs router bgp 101 neighbor 12.0.0.1 remote-as 101 neighbor 12.0.0.1 update-source Loopback0 neighbor 12.0.0.2 remote-as 101 neighbor 12.0.0.2 update-source Loopback0 ! address-family ipv4 vrf RED redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 12.0.0.1 activate neighbor 12.0.0.1 send-community extended neighbor 12.0.0.2 activate neighbor 12.0.0.2 send-community extended exit-address-family ! Example shows the first PE configuration. There are three basic sections. The first global command sets up a VRF for the VPN, with some name, route-distinguisher, and route- target values. Then, every CE-PE link needs to be added to the VRF. There is no VRF on JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 80 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN core-facing links, which simply do label switching. The final section is iBGP, which in this example established two sessions to peers at 12.0.0.1 and 12.0.0.2. Each VPN has its own address-family configuration, where you can configure which networks to announce and so forth. The VPNv4 address-family establishes the peers as being MPLS-VPN savvy, so BGP peers understand the necessary extended communities. Example gives the LSR configuration, which, as you can see, is very straightforward. Example MPLS LSR Configuration ! Core facing links interface FastEthernet1/0/1 ip address 192.168.1.4 255.255.255.0 tag-switching ip no ip directed-broadcast full-duplex no cdp enable interface FastEthernet2/0/1 ip address 192.168.4.2 255.255.255.0 tag-switching ip no ip directed-broadcast full-duplex no cdp enable Example gives the PE Configuration at the other side of the network. Example MPLS-VPN Egress PE Configuration ! Route-target and RD values must match. VRF names don't have to ! but better if it does ip vrf RED rd 101:1 route-target both 101:1 interface Loopback0 ip address 12.0.0.1 255.255.255.255 no ip directed-broadcast ! egress CE-PE link interface Ethernet1/0/0 ip vrf forwarding RED ip address 11.2.4.1 255.255.255.255 no ip directed-broadcast ! Core facing links JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 81 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN interface FastEthernet0/0/0 ip address 192.168.4.1 255.255.255.0 tag-switching ip no ip directed-broadcast full-duplex no cdp enable router bgp 101 neighbor 12.0.0.2 remote-as 101 neighbor 12.0.0.2 update-source Loopback0 neighbor 12.0.0.3 remote-as 101 neighbor 12.0.0.3 update-source Loopback0 ! address-family ipv4 vrf RED redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 12.0.0.2 activate neighbor 12.0.0.2 send-community extended neighbor 12.0.0.3 activate neighbor 12.0.0.3 send-community extended exit-address-family ! Note ping, telnet, and traceroute have VRF options so that they can be used between PEs. Why don't the standard commands work? Remember that a VRF represents an entirely private routing space. Commands issued from the Cisco IOS command line use the global routing table. On a PE, this means that all the LSRs are reachable, but no device in a VPN address space is. Therefore, these commands need a new parameter to tell the router which VPN to originate a ping in, for example. Of course, a ping within a VRF, or from any CE, will not see any LSR, because those are in a different address space. This makes sense enough in theory, but can take some getting used to in practice. MPLS-VPN architecture provides full-mesh configuration by default. In other words, a PE forwards traffic directly to its destination. It turns out that some enterprise networks need to change this behavior. A common reason is a security policy that requires all sites JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 82 of 174 For Restricted Circulation JTO Phase II Data Network & IT Configuration:MPLS based Layer 3 VPN in a certain area to forward traffic through a regional hub, which might have some expensive virus-checking package for e-mail, or perhaps needs to do NAT on traffic between sites. Whatever the reason, MPLS VPNs can be deployed as hub-and-spoke topologies by using route-targets. If a spoke imports routes only from a hub, then traffic will in turn flow through the hub to get somewhere else. (Remember, PEs forward to BGP next hops.) Because a hub must know all the routes, it imports from all spokes. Spokes must never import from each other. This scenario is shown in Figure, with correct use of route-targets. Figure 47: Hub-and-Spoke Topology Examples through show how to configure the route-targets to match the figure. Example PE A Hub !Hub imports from Spokes vrf green rd 200:1 route-target both 200:1 route-target import 100:1 Example PE B Spoke !All spokes import from Hub Vrf green rd 100:1 route-target import 200:1route-target export 100:1 Example PE C Spoke !And export to Hub Vrf green rd 100:1 route-target import 200:1 route-target export 100:1 Route-targets are also used to build extranets. An extranet is a VPN with limited reachability of destinations inside other VPNs. JTO Phase II (DNIT) Version 1.0 Sep 2021 Page 83 of 174 For Restricted Circulation