1 / 19

MPLS L3 and L2 VPNs

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. How VPNs used to look. Use Frame relay of ATM VCs to connect customers

mizell
Download Presentation

MPLS L3 and L2 VPNs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related