MPLS L3 and L2 VPNs

1. MPLS L3 and L2 VPNs • Virtual Private Network • Connect sites of a customer over a public infrastructure • Requires: • Isolation of traffic • Terminology • PE, P or core, CE or CPE • Customer site • Provider

2. How VPNs used to look • Use Frame relay of ATM VCs to connect customers • Over the provider’s FR or ATM network • Good isolation of traffic • Separate FR DLCI or ATM VC to connect two customer sites • They all are called Virtual Circuits (VCs) • This is a L2 VPN • All types of traffic can flow over the VCs • As long as their encapsulation is defined

3. Models • The previous model is the “overlay” model • Provider gives customers p2p links between their sites • Customers run their own routing etc over them • But they must know how to manage routing • Routing can be sub-optimal if the connectivity between sites is not too good • A full mesh is expensive • Provider does not know anything about customer’s network • His life is simple • Can use multiple technologies for the VCs including IP tunnels • GRE, IPSec

4. Peer-to-peer model • Customers and providers exchange routing information • Their life is simple now • Provider can see information about the customer’s network • Its operation is more complex • Routing between sites may be better now • Adding a new site is simple • No need to configure multiple VCs between the new site and the existing sites • A CE connects to • A dedicated PE • Expensive • A PE shared with other customers • Risky, traffic may leak • All customers see the same address space • No two customers can have the same address in their network

5. Intra-nets etc… • Intra-net • Multiple sites belonging to the same customer/domain • Extra-net • Sites that belong to different customers/domains • Remote access • Remote users access the central network

6. Topologies • Determined by the structure of the customer • Hub-and-spoke • One/few central cite – hub • Has fewer VCs/cheaper • But routing is not too good • Extensions for redundancy • Redundant connections to two hubs etc. • Full + partial mesh • More paths • Better routing • Higher cost • Hybrids between the above

7. Problems • Overlay VPNs • Scaling and configuration is a problem • Peer-to-peer • Risky, traffic may leak between customers • In the shared PE • In the shared IP address space in the backbone • MPLS VPNs • Isolation similar to overlay VPNs • Scaling similar to peer-to-peer VPNs

8. VRF • PEs have different Virtual Router Forwarding tables • One per VPN • Contains customer routes • Routes from different VPNs do not get mixed up • Different VPNs can have the same route • PEs have one forwarding table for the backbone • Contains backbone (provider) routes • Each incoming customer packet is routed based on the information of this customer’s VRF • Each outgoing customer packet is also routed based on this VRF • There may be multiple PE links on the same VRF

9. Missing parts • How will PEs learn routes from the remote VPN sites? • How will be packets send to a destination in a remote site? • Backbone routers do not know anything about the VPN addresses • How will PEs learn routes from the local customers?

10. Learning routes from remote PEs • Need to learn all routes for all the remote sites of a VPN • Need to be added to the VRF for the VPN • Must talk to the remote PEs that have sites for the VPN • How do the PEs exchange routes? • There can be a lot of routes • Number of VPNs x number of routes/VPN • IGP would not scale to these sizes • Plus even P routers would have to see all these routes, not good

11. Use MP-BGP • not exactly what BGP is supposed to do but… • Use the multi-protocol capabilities of BGP • Can carry IPv4, IPv6 prefixes • And now… VPN routes • A VPN route is prefix + 64 bit route distinguisher (RD) • RD is unique for each VPN • RD + prefix is unique in the whole system • PEs talk to each other over iBGP • All PEs need to talk to all other PEs • Full mesh of iBGP sessions between PEs • But P routers do not have to see all these routes • Good scaling • And exchange VPN routes • PEs eventually will find out all the remote routes for the VPNs they carry • And the BGP next-hop which is the egress PE router

12. Good scaling • P routes do not need to see the customer VPN routes • They forward packets towards the egress PE • PEs need to maintain only routes for the VPN sizes they host

13. Packet transport • Need to send a packet to a destination in a remote VPN site • The route in the VRF will contain the BGP next-hop • The PE router for the remote site • Packet must be sent to this router • Packet must be tunneled to the PE • When it arrives somehow it must reach the VRF that corresponds to the remote site • Packet must contain some additional information for that • Called a de-multiplexer • There are many options for the tunneling and the de-multiplexer • GRE tunneling, L2TP, IPSec • And MPLS

14. MPLS VPNs • Each PE has an LSP to each other PE • Uses this LSP to reach the destination PE • Each packet carries another MPLS label that is used to selected the right VRF • VPN label • Label stacking • The VPN label is allocated by the egress PE • Advertised through MP-BGP • Ingress PEs store this label in their VRF together with the destination route • Packets are forwarder over the backbone based on the outer label • P routers do not look at the VPN label

15. Complications • How about extranets? • A site may belong to multiple VPNs • How do I control which routes does it learn? • Use extended communities and import export policies • Each route in the MP-BGP messages is marked with a route target (RT) • PEs are configured with import and export policies for these route targets • We can control which PEs will accept advertised routes • A site that belongs to two VPNs will be configured to import routes from both VPNs • Can build hub and spoke and other structures

16. Learning local customer routes • Can run any routing protocol between the CE and the PE routes • Many options: BGP, OSPF, RIP • Even static routes • There is only one routing process running on the PE router • Logically split into multiple ones • One per VRF

17. OSPF between CE and PE • There are no OSPF adjacencies between the PEs or between remote sites • Only OSPF adjacencies between a CE and its PE • Two sites may belong to the same or different OSPF areas • Including area 0 • Boundary between areas could be on PE, CE, or inside the site • If one site originates an OSPF route • This route has to appear on the remote sites • With the proper type • The route may be an external route for example • The remote PE will originate the route into the remote site • The type of the route is signaled over MP-BGP

18. More problems • Full mesh of MP-iBGP sessions between PEs • Very hard to add a new PE • Poor scalability • Use route reflectors (RR) • More than one for redundancy • May be inefficient • Advertises VPN routes to PEs that do not need them • They do not have any sites of a given VPN • Filter based on route target at the RRs • Even better filter at the source PEs

19. And more complexity • Carrier of Carriers • ISP with ISP customers • Customers may or may not run MPLS • Hierarchical VPNs • ISP with ISP customers that over VPN service • Inter-provider VPNs • A customer needs VPN service from two different ISPs • More difficult than above • Routing information needs to be communicated between ISPs • Multi-hop eBGP between customer sites