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
• 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
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
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
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
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
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
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
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?
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
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
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
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 demultiplexer
• GRE tunneling, L2TP, IPSec
• And MPLS
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
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
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
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
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
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