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 providers 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 customers
  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 customers
  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 customers 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