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