Introduction. MPLS-based VPN. Network Components. Objectives

Транскрипт

1 Introduction MPLS-based VPN MPLS Layer 3 VPNs Fundamentals MPLS Layer 3 VPN allows SPs to use their IP/MPLS backbone to provide VPN services to their customers This approach is also referred to as BGP/MPLS VPNs BGP is used to distribute VPN routing information across the provider's backbone MPLS is used to forward VPN traffic from one VPN site to another The de facto standard is described in RFC 2547bis 1 2 Objectives Network Components The primary objectives of MPLS Layer 3 VPNs are Customer can outsource WAN connectivity Sites can be in different organizations Extranets and intranets Flexible connectivity Full or partial mesh, hub and spoke Scalability Number of VPNs, sites per VPN Private addresses, traffic isolation BGP/MPLS approach to VPNs defines three main components: Customer Edge (CE) devices: are at the customer site and have a direct interface to the provider network These are also known as CPE devices Provider Edge (PE) routers: are at the edge of the service provider network that connect directly to a CE Provider (P) routers: form the core network and do not attach to CE devices While PE and P routers are managed by the provider, CE routers are usually managed by the customer 3 4

2 Simple BGP/MPLS VPN Topology Customer Edge devices VPN A CE VPN B PE-ELSR Provider Network P-LSR P-LSR P-LSR PE-ELSR VPN A CE VPN B At each customer site, there are one or more CE devices Each CE is connected to one or more PEs via different sort of data link (such as Frame Relay PVC, ATM PVC, VLAN) A CE device may be: a host, when the customer site has a single host a switch, when the customer site has a single subnet a router, in the other cases CE CE 5 6 Customer Edge devices Incorporated VPNs In general, the CE device can be expected to be a router it is a routing peer of the PEs to which it is attached, but it is NOT a routing peer of CE routers at other sites Routers at different sites do not directly exchange routing information with each other The customer has no backbone to manage, and does not deal with any inter-site routing issues This means that MPLS VPN is not an "overlay" on top of the SP's network, but is incorporated into this Overlaid VPNs MPLS VPN network Incorporated VPNs 7 8

3 Configuration requirements Routing protocols Layer 2 (overlay) VPNs: Update traffic matrix Add (n-1) PVCs to connect new CPE Resize full PVC mesh Update OSPF design Reconfigure each CPE for new L3 topology MPLS (peer) VPNs Configure new CPE Update edge LSR CE Static, RIPv2, OSPF, EBGP PE IBGP other PEs CE runs standard routing protocols PE and CE exchange routing information through static routing, RIPv2, OSPF, or EBGP PE exchanges routing/forwarding information with other PEs through IBGP P routers do not need any per-vpn routing information 9 10 VPN Routing and Forwarding tables (s) VPN Routing and Forwarding tables (s) Each PE maintains one or more per-site forwarding tables These are known as s, or VPN Routing and Forwarding" tables Each contains a routing table and FIB table populated by Routing information received from CE routers Relevant routing information received from other PEs In general, each CE-PE connection is mapped to a specific If there are multiple connections between a CE-PE pair, two solutions are possible all the connections are mapped to the same different connections are mapped to different s Different sites can be mapped to the same if they have all VPNs in common 11 12

4 VPN routing and forwarding tables (s) VPN routing and forwarding tables (s) When a PE router receives a packet from a CE identifies the associated to the ingress interface or sub-interface consults this in order to determine how to route the packet The choice of is NOT determined by the user content of the packet Security The associated with a particular site S is populated ONLY with routes that lead to other sites which have at least one VPN in common with S This ensure that each VPN has its own s and can access only the set of routes contained in its routing table VPN routing and forwarding tables (s) Default forwarding table Scalability After learning local VPN routes from CEs, a PE exchanges VPN routing information with other PEs using BGP Each PE is only required to maintain s for its directly connected sites PE routers can maintain BGP sessions to route reflectors as an alternative to a full mesh of BGP sessions A PE will also have a default forwarding table which is not associated with any particular VPN This default table is used for handling traffic which is not VPN traffic VPN traffic which is simply transiting this router (it is not received from a CE and it does not be sent to a CE) 15 16

5 Overlapping address spaces MP-BGP with VPN-IPv4 Unique addresses are a requirement within a, but not between different s VPNs which do have sites in common may have overlapping address spaces This is a common situation when the VPNs use the RFC1918 private address space To solve this problem, BGP/MPLS VPNs converts non-unique IP addresses into globally unique addresses by combining the use of the VPN-IPv4 address family the deployment of MultiProtocol BGP-4 Extensions (MP-BGP) (RFC2283) Problem Conventional BGP assumes that each IPv4 address is globally unique and installs only one route for each IPv4 address VPN-IPv4 Address Family Route Distinguishers A VPN-IPv4 address is a 12-byte quantity consisting of an 8-byte Route Distinguisher (RD) a 4-byte IPv4 address Type Field 2-byte Type Filed 8-byte Route Distinguisher Administrator Subfield 6-byte Value Filed Assigned Number Subfield 4-byte IPv4 address IPv4 Address Prefix At the present, there are two types of RD format Type 0 2-byte Administrator Subfield: holds an autonomous system number (ASN) 4-byte Assigned Number Subfield: holds a value from the numbering space administered by the service provider Type 1 4-byte Administrator Subfield: holds an IPv4 address 2-byte Assigned Number Subfield: holds a value from the numbering space administered by the service provider VPN-IPv4 example (type 0): 100:26: /

6 Route Distinguishers VPN Route Distribution The use of the private ASN space or the private IP address space when defining RDs is strongly discouraged Indeed, each RD has to be globally unique Each can use its own RD Globally unique RDs allows VPNs to use overlapping address spaces without any ambiguity Distinct routes to a common IPv4 prefix can be created Multiple routes to the same system can be created Policies to decide which packets use which route can be defined The distribution of VPN-IPv4 routing information is constrained through the use of BGP extended community attributes These attributes are carried in BGP messages as attributes of the route identify specific classes of routes which have to be treated with specific routing policies Each BGP extended community must be globally unique contains either a public IP address or ASN can be used by only one VPN Route Advertisements Extended community attributes MP-IBGP advertisement for each route consists of VPN-IPv4 prefix MPLS label which was assigned to the route by the ingress PE router when it learned the local route from the directly attached CE Next hop address (loopback interface of PE) Extended community attributes (route target, SOO) RFC 2547bis VPNs use three different types of BGP attributes The route target attribute: identifies a set of sites (s) that should receive the route The VPN-of-origin attribute: identifies a set of sites and establishes the associated route as coming from one of the sites in that set The site-of-origin attribute: identifies the specific site from which a PE router learns a route. It can be used to prevent routing loops Destination Label BGP next hop Route Target 23 24

7 Route Targets Route Targets Operational Model Route Target is a 64 bit field allowing VPNs to implement a flexible, policy-based control mechanism There are two sets of Route Targets Export Route Targets: are associated by a PE to routes learned from directly connected sites on the basis of the configured export policy Import Route Targets: control whether a route will be accepted into a site-specific on the basis of the configured import policy When a VPN-IPv4 route is created by a PE, it is associated with one or more export Route Target attributes The ingress PE can be configured in two ways to assign a single route target attribute to all routes learned from a given site to assign different route target attributes to different sets of routes learned from a given site Differently, the CE router can specify one or more route targets for each route This approach shifts the control of implementing VPN policies from the service provider to the customer Route Targets Operational Model Operational Model Every on egress PEs is associated to one or more import Route Target attributes Export Route Targets are carried in BGP as attributes of the route A route associated with export Route Target T must be distributed to every PE router that has a associated with import Route Target T An egress PE router can only install a VPN-IPv4 route in a if the route target attribute carried with the route matches one of the PE router s import targets policy policy policy BGP table PE Global routing table IGP + LDP MP-BGP Global routing table IGP + LDP Provider Network Global routing table BGP table PE policy policy policy 27 28

8 Operational Model Control Flow Two fundamental traffic flows occur in a BGP/MPLS VPN In a BGP/MPLS VPN, the control flow consists of two subflows A control flow that is used for VPN route distribution and label switched path (LSP) establishment A data flow that is used to forward customer data traffic The first is responsible for the exchange of routing information between the CE and PE routers and between the PE routers The second is responsible for the establishment of LSPs across the provider s backbone between PE routers Control flow Control flow P P P P CE2 CE2 P MP-BGP When advertises to the route for its directly connected site, installs a local route in the Red Then, PEs establish MP-BGP sessions between them Before advertising the route, selects an MPLS label and assigns its loopback address as the BGP next hop for the route P MP-BGP When receives route advertisement it determines if it should install the route into Red by performing route filtering based on Route Target If installs the route, it then advertises the route from to CE

9 Control flow Control flow P P If LDP is used, a full mesh of best-effort LSPs is established across the backbone to support PE-to-PE connectivity P MP-BGP In order to use MPLS to forward VPN traffic across the backbone, labels are distributed to create LSPs between BGP next hops Either LDP (TDP) or RSVP-TE can be used If RSVP-TE is used, RSVP-based LSPs have a higher priority than LDP-based LSPs Both an LDP-based and an RSVP-based LSP exist between a pair of PE routers, the ingress LSR selects the RSVP-based LSP Data flow Data flow When a packet arrives at CE2, it performs a longest-match route lookup and forwards the IPv4 packet to receives the packet, performs a route lookup in Red, and obtains the following information the MPLS label that was advertised by with the route the BGP next hop for the route (the loopback address of PE 1) the outgoing sub-interface for the LSP from to the initial MPLS label for the LSP from to Then, packet is forwarded across the backbone using two-level Label Stack Top (outer) label allocated by LDP represents the BGP Next-Hop Bottom (inner) label allocated by BGP indicates outgoing interface IP Datagram Encapsulation per RFC 2547 Layer2 header Top Label Bottom Label IP Datagram For the LSP For the destination network 35 36

10 Data flow Building VPNs using Route Targets P routers switch packets based on the top label When receives the packet, it looks for a matching MPLS route for the bottom label If there is a match, the bottom label is popped and a native IPv4 packet is sent directly to the CE associated with the label Note that the does not have to be consulted By setting up the import and export targets, SPs can build different kinds of VPNs Two main VPN topologies: Full mesh Hub and spoke Full-mesh topology Full-mesh topology Suppose it is desired to create a full-mesh closed site connectivity for a Red Corporation which shares the same BGB/MPLS VPN Backbone with a Blue Corporation Each sites of Red Corporation can send traffic directly to the others of the same Corporation Each sites of Red Corporation cannot be sent to or received traffic from sites of the Blue Corporation Site 6 CE6 Provider Network Exp Target = Red Imp Target = Red Exp Target = Red Imp Target = Red Exp Target = Red Imp Target = Red PE3 CE3 CE2 Site 3 Site 2 CE5 Site 5 Site 4 CE

11 Full-mesh topology Hub-and-spoke topology Each Red Corporation site is associated with Red on its PE router A single globally unique route target (Red) is configured for each Red as both the import target and the export target This route target (Red) is not assigned to any other as the import or the export target The result is full-mesh connectivity among Red Corporation sites Suppose that Red Corporation wants to create a VPN that supports hub-and-spoke site connectivity with the following policies: can communicate directly with Site 5, but indirectly by way of Site 5 with Site 2 Site 2 can communicate directly with Site 5, but indirectly by way of Site 5 with Site 5 can communicate directly with and Site 2 Of course, privacy requires that Red and Blue Corporation sites cannot send traffic to or receive traffic from each other Hub-and-spoke topology Hub-and-spoke topology Provider Network CE3 Site 3 Two globally unique route target values are used: hub and spoke Site 6 CE6 Exp Target = Spoke Imp Target = Hub Exp Target = Hub Imp Target = Spoke PE3 Exp Target = Spoke Imp Target = Hub CE5 Site 5 Site 4 CE4 CE2 Site 2 The hub site s is configured with export target = hub import target = spoke All the routes in of hub site are imported by the spoke sites The at the hub site imports all remote routes with a spoke attribute 43 44

12 Hub-and-spoke topology The at each spoke site is configured with export target = spoke import target = hub The routes in s of each spoke site are imported by the hub site, but dropped by other spoke sites The at a spoke site imports only routes with a hub attribute, that are the routes advertised by the hub site MPLS Layer 3 VPNs MPLS Layer 3 VPNs Case study Case Study Network topology Assume a single service provider has an IP backbone to deliver BGP/MPLS VPN services to different enterprises There are 3 PEs and 5 customer sites The following connectivity policies are desired - Site 5 Site 2 - Site 3 Site 2 - Site 4 Site 5 - Site 3 - Site 2 Site 3 - Site 4 Site 4 - Site /16 Site /16 CE2 Site /16 Provider Network CE3 PE3 CE4 Site /16 CE5 Site /

13 Network topology Generic Configuration for PE /16 Site /16 CE2 66* Site /16 Provider Network 55 CE PE3 CE4 Site /16 CE5 Site / /16 Site /16 if_x if_x if_z if_1 if_2 if_3 if_z CE2 Red Interface = if_1 RD = RD_Red Export Target = Red Import Target = Red Green Interface = if_3 RD = RD_Green Export Target = Green Import Target = Green * Top labels defined by the PE Generic Configuration for PE 1 Generic Configuration for PE /16 if_x if_z if_1 if_3 if_2 MPLS Forwarding Table In Interface Label Action Out Interface If_ pop If_1 If_ pop If_3 if_1 if_2 if_z CE5 if_x Site /16 Red Interface = if_2 RD = RD_Red Export Target = Red Import Target = Red Site /16 if_x if_z CE2 Destination BGP next hop Interface Bottom label Top label 10.1/16 Direct If_ Destination BGP next hop Interface Bottom label Top label 10.1/16 Direct If_

14 Generic Configuration for PE 2 Generic Configuration for PE 3 if_1 if_2 if_z CE5 if_x Site /16 MPLS Forwarding Table In Interface Label Action Out Interface PE3 if_1 Green Interface = if_2, if_3 RD = RD_Green Export Target = Green Import Target = Green If_1 pop If_2 if_3 if_2 Destination BGP next hop Interface Bottom label Top label Site /16 if_x CE3 if_z if_z CE4 if_x Site4 10.2/ /16 Direct If_ Generic Configuration for PE 3 Route Distribution Across Backbone Site /16 PE3 if_1 if_3 if_2 CE3 if_z if_z if_x CE4 if_x In Interface Site4 10.2/16 MPLS Forwarding Table Label Action Out Interface If_ pop If_2 If_ pop If_3 After configurations and local routes learning Ingress PEs use MP-IBGP to distribute routes across the SP backbone to egress PEs Before distribution, each IPv4 prefix is converted into a VPN-IPv4 prefix using the RDs configured for the that contains the route Each PE can send all routes to all its MP-IBGP peers or it can exclude for each peer the specific VPN routes that it does not share with the given peer Destination BGP next hop Interface Bottom label Top label 10.2/16 Direct If_ /16 Direct If_

15 Route Advertisements Route Installations Destination Label BGP next hop Route Target RD_Red:10.1/ Red RD_Green:10.1/ Green MP-IBGP session Egress PEs When an egress PE receives a VPN-IPv4 route, it compares the route to all of its import policies If the route target matches the import target policy of at least one, the VPN-IPv4 route is installed in its VPN_IPv4.RIB table Destination Label BGP next hop Route Target RD_Red:10.2/16 Red MP-IBGP session Egress PEs Destination Label BGP next hop Route Target RD_Green:10.2/ PE3 Green PE3 RD_Green:10.3/ PE3 Green MP-IBGP session Egress PEs Route Installations update P1 installs the following routes RD_Red:10.2/16 Red RD_Green:10.2/ PE3 Green RD_Green:10.3/ PE3 Green P2 installs the following routes RD_Red:10.1/ Red Destination BGP next hop Interface Bottom label Top label 10.1/16 Direct If_ /16 If_2 11 Destination BGP next hop Interface Bottom label Top label 10.1/16 Direct If_ /16 PE3 If_ /16 PE3 If_ P3 installs the following routes RD_Green:10.1/ Green 59 60

16 update Egress PE Router to CE Route Distribution Routing Table PE3 Destination BGP next hop Interface Bottom label Top label 10.1/16 If_ /16 Direct If_2 - Destination BGP next hop Interface Bottom label Top label 10.1/16 If_ /16 Direct If_ /16 Direct If_ Destination next hop Interface 10.1/16 Direct If_x 10.2/16 If_z CE2 Routing Table Destination next hop Interface 10.1/16 Direct If_x 10.2/16 If_z 10.3/16 If_z CE3 Routing Table Destination next hop Interface CE4 Routing Table Destination next hop Interface 10.1/16 PE3 If_z 10.2/16 Direct If_x 10.3/16 PE3 If_z CE5 Routing Table Destination next hop Interface 10.1/16 If_z 10.2/16 Direct If_x 10.1/16 PE3 If_z 10.2/16 PE3 If_z 10.3/16 Direct If_x Example 1: Forwarding Red VPN Traffic from to Site 5 Example 1: Forwarding Red VPN Traffic from to Site 5 Provider Network Provider Network 11 swap 11 swap Host CE5 Site 5 Server Longest match lookup Push Push 11 Swap top Penultimate pop top pop Longest match lookup Host CE5 Site 5 If_z Server Longest match lookup If_1 If_2 If_1 If_2 Push Push 11 Swap top Penultimate pop top pop Longest match lookup Routing Table Destination next hop Interface 10.1/16 Direct If_x 10.2/16 If_z 63 64

17 Example 1: Forwarding Red VPN Traffic from to Site 5 Example 1: Forwarding Red VPN Traffic from to Site 5 Provider Network Provider Network 11 swap 11 swap Host CE5 Site 5 If_z Server Longest match lookup If_1 If_2 If_1 If_2 Push Push 11 Swap top Penultimate pop top pop Longest match lookup Host CE5 Site 5 If_z Server Longest match lookup If_1 If_2 If_1 If_2 Push Push 11 Swap top Penultimate pop top pop Longest match lookup Destination BGP next hop Interface Bottom label Top label 10.1/16 Direct If_ /16 If_2 11 MPLS Forwarding Table In Interface Label Action Out Interface If_1 pop If_ Example 1: Forwarding Red VPN Traffic from to Site 5 Provider Network Example 1: Forwarding Green VPN Traffic from Site 4 to Site 3 PE3 Host swap CE5 Site 5 If_z Server Longest match lookup Push Push 11 Swap top Penultimate pop top If_1 If_2 If_1 If_2 67 pop CE5 Routing Table Longest match lookup Destination next hop Interface Direct If_z If_x PE3 Site 3 Host CE3 Longest match lookup CE Longest match lookup Site4 Host Destination BGP next hop Interface Bottom label Top label 10.1/16 If_ /16 Direct If_ /16 Direct If_

18 Introduction MPLS-based VPN MPLS Layer 3 VPNs Multi- CE Multi- CE, also termed -lite by Cisco s marketing department, is a new feature developed for CE devices (router or switch) in an MPLS Layer 3 VPN model It extends to the customer sites limited PE functionality of MPLS- VPN to support multiple s in customer edge devices NOTE. The CE device does not need MPLS VPN functionality, MPLS-enabled interfaces or MP-BGP Motivations Motivations BGP/MPLS VPNs provide security and privacy as traffic travels through the provider network VPN A The CE router has no mechanism to guarantee private networks across the traditional customer network Traditional solutions to provide privacy are using a switch and placing each client in a separate VLAN using a separate CE router per each client s organization or IP address grouping attaching to a PE VPN B VPN C Switch VLANs CE router PE router MPLS Network Traditional customer site topology in an MPLS-VPN network with a switch to segment traffic 71 72

19 Motivations Motivations VPN B VPN A VPN C CE router CE router CE router PE router MPLS Network Traditional solutions to provide privacy are both costly to the customer as additional equipment is needed and requires more network management and provisioning of each client site Multi- CE allows a CE device to maintain separate tables in order to extend the privacy and security of an MPLS- VPN down to a branch office The per-vpn segregation of routing information is provided on the customer site before traffic is sent to the PE router Traditional customer site topology in an MPLS-VPN network with separate CEs to segment traffic on the CE device on the CE device CE device acts as multiple virtual CEs A virtual packet-forwarding table is created for each VPN at the customer site Input sub-interfaces are used to distinguish routes for different VPNs and forms s by associating one or more sub-interfaces with each Because Multi- CE is a Layer 3 feature, each sub-interface in a must be a Layer 3 interface Each on the CE device is then mapped to a on the PE router VPN B VPN A VPN C CE- one physical line PE router with multiple point-to-point sub-interfaces MPLS Network Customer site topology in an MPLS-VPN network with -lite configured at the CE router 75 76

20 Operational mode Operational mode CE devices use interfaces to form a VLAN-like configuration on the customer side The CE can segment its LAN traffic by placing each client or organization with its own IP address space either on separate Ethernet interfaces or through one Fast Ethernet interface segmented into multiple sub-interfaces Each interface contains its own IP address space to separate each different client CE learns routes from an interface and installs these routes into the corresponding Between CE and PE router multiple uplinks have to be configured, one for each These uplinks could be implemented with sub-interfaces, VLANs or Generic Route Encapsulation (GRE) tunnels PE learns routes from the CE and installs these routes into the corresponding a routing protocol or a static route is need to propagate routes from a specific on the Multi- CE to the same on the PE router Operational mode Operational mode VPN A VPN B Fast Ethernet 3/8 Fast Ethernet 3/7 Fast Ethernet 3/11 CE- Fast Ethernet 3/5 PE router MPLS Network When receiving a packet from a directly attached interface, the CE performs a route lookup in the associated with that interface Then, the CE forwards the packet to the PE router according to information trough the correct sub-interface or VLAN Across the MPLS backbone, the packet is forwarded according to BGP/MPLS VPN model Global network Fast Ethernet 3/

21 -lite Configuration Guidelines -lite Configuration Guidelines When configuring in a network these points have to be considered A switch with -lite is shared by multiple customers, and all customers have their own routing tables Because customers use different tables, the same IP addresses can be reused. Overlapped IP addresses are allowed in different VPNs No need for NAT to allow support of overlapping IP address space. However, NAT may still be required in order to send traffic to the Internet -lite lets multiple customers share the same physical link between the PE and the CE. Trunk ports with multiple VLANs separate packets among customers. All customers have their own VLANs Most routing protocols (BGP, RIP, and static routing) can be used between the CE and the PE. However, the use of EBGP is recommend for these reasons BGP does not require multiple algorithms to communicate with multiple Ces BGP is designed for passing routing information between systems run by different administrations BGP makes it easy to pass attributes of the routes to the CE lite Configuration Guidelines -lite does not support IGRP, EIGRP, and ISIS The OSPF routing protocol is not supported between the PE and the CE -lite does not affect the packet switching rate The number of s supported by the CE router is dependent on the platform, processing power and available memory MPLS-based VPN MPLS Layer 3 VPNs VPN-IPv

22 Introduction IPv6 Provider Edge Because IPv6 is now gaining acceptance, service providers have been asked by their customers to offer IPv6 services To this, the deployment options available to service providers that currently operate an IPv4 MPLS backbone are the IPv6 Provider Edge (6PE) which allows for global IPv6 reachability service the IPv6 VPN Provider Edge (6VPE) which allows for IPv6 VPN service over a pure IPv4 MPLS/IP backbone The BGP/MPLS VPN allows the routing of IPv4 VPN traffic transparently over an IPv4 MPLS core that remains unaware of these IPv4 VPN routes This is achieved by combining the following Hierarchical routing, in which IPv4 VPN reachability is advertised only between the PE routers transparently over the core Tunneling of IPv4 VPN packets in IPv4 MPLS LSPs IPv6 Provider Edge IPv6 Provider Edge The 6PE solution uses the IPv4 VPN paradigm to achieve global IPv6 reachability over an IPv6-unaware IPv4 MPLS backbone The key difference is that the reachability information advertised among PE routers via MP-BGP is IPv6 prefixes The PE routers become dual-stack and are called 6PE routers They support IPv6 (and typically also IPv4) on access interfaces but still support only IPv4 and IPv4 MPLS on the core-facing interfaces The following steps occur when a source IPv6 site connected to an ingress 6PE router want to communicate with an IPv6 destination connected to an egress 6PE router: 1. Reachability of the IPv4 address of the egress 6PE router loopback interface is advertised in the core network 2. An IPv4 LSP is established from the ingress 6PE router to the egress 6PE router 3. The egress 6PE router learns route from the IPv6 CE router 4. The egress 6PE router runs MP-BGP among each other using the labeled IPv6 address family the MP-BGP sessions run over an IPv4 stack 87 88

23 IPv6 Provider Edge IPv6 Provider Edge The IPv6 addressing architecture defines the IPv4-mapped IPv6 address format (prefix ::FFFF/96) Thus, the IPv4 address of the egress 6PE router is encoded in the BGP Next Hop field as an IPv4-mapped IPv6 address A label is also advertised by the egress 6PE router for the IPv6 prefix Finally, the egress 6PE router populates an entry in its LFIB for this label/prefix 5. The ingress 6PE router populates its IPv6 LFIB with an entry for the advertised IPv6 prefix that indicates that a packet for this prefix is to be encapsulated with the bottom label advertised in MP-BGP for the IPv6 prefix and the top label advertised for the LSP between ingress and egress 6PE 6. If a routing protocol is used between the source site and the ingress 6PE router, the ingress 6PE router advertises the reachability of the IPv6 prefix in that routing protocol IPv6 Provider Edge IPv6 VPN Provider Edge (6VPE) When the ingress 6PE router receives an IPv6 packet, it performs a lookup on the destination IPv6 address in its IPv6 FIB pushes a label stack in front of the IPv6 packet forwards that labeled packet toward the core on the next-hop interface to the egress 6PE router The P routers perform regular IPv4 label-switching operations, resulting in the swapping the top label Finally the packet is received by the egress 6PE router, that pops the labels and performs a lookup in its LIB for the bottom label to properly forward the packet The 6VPE approach offers the same isolation of end users' intranets as IPv4 VPN It combines the "IPv6 handling" of 6PE with the "VPN handling" of IPv4 MPLS VPNs to support IPv6 VPN services over an IPv4 MPLS backbone The main extensions to the 6PE approach are Use of a VPN-IPv6 address family (a VPN-IPv6 address is a 24-byte entity with an 8-byte RD and a 16-byte IPv6 address) Use of the concept of the BGP/MPLS 91 92

24 IPv6 VPN Provider Edge (6VPE) References Because the 6VPE approach relies on the same mechanisms as BGP/MPLS VPN for IPv4, the service provider can offer the same VPN service and features either for IPv6 and IPv4 the IPv6 VPN service is much simpler to understand and integrate within the customer intranet operational costs are dramatically reduced RFC 2547bis, BGP/MPLS VPNs, Rosen and Rekhter, March 1999 RFC 2547bis, BGP/MPLS VPN fundamentals, Chuck Semeria, Juniper Networks Definitive MPLS Network Designs, Jim Guichard, François Le Faucheur, Jean-Philippe Vasseur, Cisco Press 93 94