In this mini-series of blog posts I will briefly go through the building blocks of layer 2 and layer 3 MPLS VPNs, the controls these provide and a few gotchas before finally exploring some ways to use and abuse the mechanisms to cause mischief on the network.
Introduction to the MPLS Security ModelIn addition to its unrivaled flexibility and scalability, the most significant benefit of MPLS is its very simple (and therefore fast) data plane:
- As frame enter at the MPLS edge, the PE adds (pushes / imposes) labels to the frame header.
- At each hop inside the MPLS core a simple table lookup is done on the outer label number. The lookup returns a replacement label, outgoing interface and encap to be written onto the outgoing frame (a label swap).
- As frames reach the edge of the MPLS core, the PE removes (pops) the outer label and acts on (i.e. routes, switches or processes) whatever it finds inside.
Labelled traffic can be queued / scheduled at the interface for QoS purposes but once traffic is labelled there's very little that can be done with regards to manipulation. ACLs can't be applied to filter labelled traffic and, since there is no "source" field in an MPLS header, uRPF checking is not possible.
The whole security model of MPLS is premised on the fact that traffic cannot pass without the right labels and route / label learning is restricted by the control plane. For anyone not familiar with MPLS VPNs, I'll provide a very high-level introduction to how this happens in practice.
Layer 3 VPNsIn order to maintain several, possibly overlapping, routing tables, an MPLS router uses the concept of VRFs. A VRF is a distinct routing instance, a bit like a virtual router, with its own interfaces, routing table and routing protocols. Internally the MPLS router uses a route distinguisher, or RD, to keep one VRF's routes separate from another's.
Separation is achieved by basically bolting the RD onto the beginning of every IP prefix known within the VRF. So for instance, if VRF "A" uses RD 100:100, when it learns a route to 10.10.10.0/24 that will be known internally as 100:100:10.10.10.0/24. If an identical prefix is learned in VRF "B" with an RD of 200:200, that will be known internally as 200:200:10.10.10.0/24. Since the extended versions of the two prefixes are different, there is no conflict and both can be used independently.
Layer 3 MPLS VPNs use MP-BGP to share routing information between devices. MP-BGP works with the extended prefixes described above and any VPN route that will be advertised to other devices must have a route target community attached (defined as an export route target for the VRF). That route can only be learned by another VRF, either locally or remotely, which is configured to import routes with that target.
In simple VPNs the import and export route targets match, meaning that every member VRF learns the routes that are present in every other member VRF. This produces a basic any-any connectivity model.
|Any-Any VRF Topology|
Clearly, since each VRF learns routes from every other VRF there is a full mesh of connectivity.
The import and export can be controlled independently, so a variety of topologies can be created quite simply. For example, to create a hub and spoke setup, simply configure the hub to export the hub route target while importing the spoke route target and configure the spokes to export the spoke route target while importing the hub route target.
|Hub and Spoke VRF Topology|
Another common application of multiple route targets is in setting up "grey management" VRFs - that is a single VRF containing centralised management platforms which are used for operational support and maintenance of devices in multiple customer VRFs.
|Grey Management VRF Topology|
GotchasIn both the hub-and-spoke and grey management scenarios there is a centralised point which has all the routing information and can communicate with everything, while the peripheral VRFs only learn a reduced set of routes and therefore can only communicate with the networks within their limited view. Spokes do not import the spoke route-target and therefore cannot "see" each other. Customer VRFs do not import each others' route targets and so separation is maintained.
One big mistake that can easily be made is for the spoke to accidentally advertise a summary or default route. The diagram below shows what happens in this case:
|Hub and Spoke Topology Broken by Default Route|
The workaround: don't summarise or default route within overlapping or partial mesh VRFs, particularly at hub sites.
Layer 2 VPNs (Pseudowires)MPLS pseudowires are essentially point-to-point tunnels that transport layer 2 frames using MPLS transport. A pseudowire simply takes a frame in one end and moves it, as is, to the other end. Pseudowires are typically signalled using targeted LDP - that is a Link Distribution Protocol connection directly between the PEs on each end of the pseudowire. The two endpoints communicate directly with each other to signal the labels to be used for a particular pseudowire, as differentiated by a virtual circuit identifier (VCID).
Since the necessary service labels are signalled directly between the two interested PEs, they are not known elsewhere in the network and no other devices can participate in the pseudowire, i.e. it is point-to-point.
Due to the simple nature of pseudowires, the gotchas are pretty minor. Provided the two peers are configured with matching VC IDs, most problems are going to be down to "schoolboy errors":
- Mismatched VC IDs
- Mismatched VC types (VLAN vs. Ethernet)
- Broken label-switched path between peers
- TLDP session unable to come up (control plane filters, mismatched LDP keys)
- Mismatched MTU (each vendor seems to count in a different way)
- Port MTU smaller than the configured VC MTU