Sample MPLS-VPN Network Topology
Figure 2 illustrates a sample network topology where a single service provider delivers an MPLS-VPN service to different enterprise customers. In this network there are two PE routers connected to four different customer sites
The inter-site connectivity can be described by the following policies.
• Any host in Site 1 can communicate with any host in Site 2.
• Any host in Site 2 can communicate with any host in Site 1.
• Any host in Site 3 can communicate with any host in Site 4.
• Any host in Site 4 can communicate with any host in Site 3.
To make sure these policies are followed, two processes must be used.
1. Exchange of routing information between the CE and PE routers at the edge of the provider’s backbone and between the PE routers across the provider’s backbone.
2. Establishment of Label Switch Paths (LSPs) across the provider’s backbone between PE routers.
PE/CE Exchange of Routing Information.
In this example, PE 1 is configured to associate VRF Green with the interface or sub-interface over which it learns routes from CE1. When CE 1 advertises the route for prefix 12.1/16 to PE 1, PE 1 installs a local route to 12.1/16 in VRF Green.
PE 1 advertises the route for 12.1/16 to PE 2 using IBGP. Before advertising the router, PE 1 selects an MPLS label (for this example, 426) to advertise with the route and assigns it s loopback address as the BGP next hop for the route. MPLS-VPN supports overlapping address spaces by the use of route distinguishers (RDs) and the VPN-IPv4 address family. It also constrains the distribution or routing information among PE routers by the use of route filtering based on BGP extended community attributes (route targets).
When PE 2 receives PE 1’s route advertisement, it determines if it should install the route to prefix 12.1/16 into VRF Green by performing route filtering based on the BGP extended community attributes carried with the route. If PE 2 decides to install the route in VRF Green, it then advertises the route to prefix 12.1/16 to CE 2.
LSP Establishment:
In order to use MPLS to forward VPN traffic across the provider’s backbone, LSPs must be established between the PE router that learns the route and the PE router that advertises the route (Figure 3).
LSPs can be established and maintained across the service provider’s network using one of the following techniques.
• Label Distribution Protocol (LDP) for assigning labels associated with the PE loopback
• BGP for assigning VPN specific labels
• Resource Reservation Protocol (RSVP) for traffic engineering tunnels
Note that there can be a single LSP or several parallel LSPs (perhaps with different QoS capabilities) established between PE routers. Also, note that it is possible to use RSVP to assign labels for PE loopbacks, although this is not recommended. LDP provides more flexibility and is less manually intensive to configure.
Traffic Flow
Figure 4 shows the flow of VPN traffic across the service provider’s backbone from one customer site to another customer site. Assume that Host 1.2.3.4 at Site 2 wants to communicate with Server 2.1.3.8.
Host 1.2.3.4 forwards all data packets for Server 2.1.3.8 to its default gateway. When a packet arrives at CE 2, it performs a longest-match route lookup and forwards the IPv4 packet to PE 2.
PE 2 receives the packet, performs a route lookup in VRF Green. User traffic is forwarded from PE 2 to PE 1 using MPLS with a label stack containing two labels. For this data flow, PE 2 is the ingress LSR for the LSP and PE 1 is the egress LSR for the LSP. Before transmitting a packet, PE 2 pushes the label, 426 in this example, onto the label stack making it the bottom (or inner) label. This label is originally installed in VRF Green when PE 2 receives PE 1’s IBGP advertisement for the route 12.1/24. Next, PE 2 pushes the label stack making it the top (or outer) label. When the packet arrives from CE2, PE2 inserts a VPN label for that customer (inner label), does a lookup in the proper VPN FIB (LFIB), and then inserts a label for forwarding to PE1 (outer label).
After creating the label stack, PE 2 forwards the MPLS packet on the outgoing interface to the first P router along the LSP from PE 2 to PE 1. P routers switch packets across the core of the provider’s backbone network based on the top (outer) label. The penultimate router to PE 1 pops the top label (exposing the bottom or inner label) and forward the packet to PE 1.
When PE 1 receives the packet, it pops the label creating a native IPv4 packet. PE 1 uses the bottom label (426) to identify the directly attached CE that is the next hop to 12.1/16. Finally, PE 1 forwards the native IPv4 packet to CE 1, which forwards the packet to Server 2.1.3.8 at Site 1.
For additional information on MPLS, http://www.cisco.com/go/mpls contains references to MPLS and MPLS-VPNs.
• Any host in Site 1 can communicate with any host in Site 2.
• Any host in Site 2 can communicate with any host in Site 1.
• Any host in Site 3 can communicate with any host in Site 4.
• Any host in Site 4 can communicate with any host in Site 3.
To make sure these policies are followed, two processes must be used.
1. Exchange of routing information between the CE and PE routers at the edge of the provider’s backbone and between the PE routers across the provider’s backbone.
2. Establishment of Label Switch Paths (LSPs) across the provider’s backbone between PE routers.
PE/CE Exchange of Routing Information.
In this example, PE 1 is configured to associate VRF Green with the interface or sub-interface over which it learns routes from CE1. When CE 1 advertises the route for prefix 12.1/16 to PE 1, PE 1 installs a local route to 12.1/16 in VRF Green.
PE 1 advertises the route for 12.1/16 to PE 2 using IBGP. Before advertising the router, PE 1 selects an MPLS label (for this example, 426) to advertise with the route and assigns it s loopback address as the BGP next hop for the route. MPLS-VPN supports overlapping address spaces by the use of route distinguishers (RDs) and the VPN-IPv4 address family. It also constrains the distribution or routing information among PE routers by the use of route filtering based on BGP extended community attributes (route targets).
When PE 2 receives PE 1’s route advertisement, it determines if it should install the route to prefix 12.1/16 into VRF Green by performing route filtering based on the BGP extended community attributes carried with the route. If PE 2 decides to install the route in VRF Green, it then advertises the route to prefix 12.1/16 to CE 2.
LSP Establishment:
In order to use MPLS to forward VPN traffic across the provider’s backbone, LSPs must be established between the PE router that learns the route and the PE router that advertises the route (Figure 3).
LSPs can be established and maintained across the service provider’s network using one of the following techniques.
• Label Distribution Protocol (LDP) for assigning labels associated with the PE loopback
• BGP for assigning VPN specific labels
• Resource Reservation Protocol (RSVP) for traffic engineering tunnels
Note that there can be a single LSP or several parallel LSPs (perhaps with different QoS capabilities) established between PE routers. Also, note that it is possible to use RSVP to assign labels for PE loopbacks, although this is not recommended. LDP provides more flexibility and is less manually intensive to configure.
Traffic Flow
Figure 4 shows the flow of VPN traffic across the service provider’s backbone from one customer site to another customer site. Assume that Host 1.2.3.4 at Site 2 wants to communicate with Server 2.1.3.8.
Host 1.2.3.4 forwards all data packets for Server 2.1.3.8 to its default gateway. When a packet arrives at CE 2, it performs a longest-match route lookup and forwards the IPv4 packet to PE 2.
PE 2 receives the packet, performs a route lookup in VRF Green. User traffic is forwarded from PE 2 to PE 1 using MPLS with a label stack containing two labels. For this data flow, PE 2 is the ingress LSR for the LSP and PE 1 is the egress LSR for the LSP. Before transmitting a packet, PE 2 pushes the label, 426 in this example, onto the label stack making it the bottom (or inner) label. This label is originally installed in VRF Green when PE 2 receives PE 1’s IBGP advertisement for the route 12.1/24. Next, PE 2 pushes the label stack making it the top (or outer) label. When the packet arrives from CE2, PE2 inserts a VPN label for that customer (inner label), does a lookup in the proper VPN FIB (LFIB), and then inserts a label for forwarding to PE1 (outer label).
After creating the label stack, PE 2 forwards the MPLS packet on the outgoing interface to the first P router along the LSP from PE 2 to PE 1. P routers switch packets across the core of the provider’s backbone network based on the top (outer) label. The penultimate router to PE 1 pops the top label (exposing the bottom or inner label) and forward the packet to PE 1.
When PE 1 receives the packet, it pops the label creating a native IPv4 packet. PE 1 uses the bottom label (426) to identify the directly attached CE that is the next hop to 12.1/16. Finally, PE 1 forwards the native IPv4 packet to CE 1, which forwards the packet to Server 2.1.3.8 at Site 1.
For additional information on MPLS, http://www.cisco.com/go/mpls contains references to MPLS and MPLS-VPNs.
