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 de-multiplexer • 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