From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Appendix C

581 Words. Plan about 3 minute(s) to read this.

This close to the MPLS appendix covers deploying VPN services over a service provider MPLS architecture. Frankly, this was a devil of a topic. While I finally wrapped my head around how, exactly, frame-mode operations work and the rudiments of Label Distribution Protocol, reading this section on MPLS/VPN has left me in the dust. While I can regurgitate most of the key terminology, I could not take this to a whiteboard and explain it well to anyone. I’d need to sit in a lab and build it first. The book’s explanation left me scratching my head too often to understand exactly how the packets are getting forwarded across the cloud, and what protocols were influencing the forwarding decisions in what capacity.

So rather than fake a bogus explanation of something I’m really not getting (at least not in the depth I’m used to), what I’m going to do is restate the closing summary of this architecture, which in fact closes Appendix C on MPLS. And the book, for that matter. The summary has all the key points about MPLS/VPN, enough presumably to correctly answer a few test questions.

MPLS/VPN Architecture Overview

  • VPNs deployed in an MPLS environment benefit both from the isolation and security of a traditional overlay VPN and simple routing, provisioning and scalability of a peer-to-peer VPN.
  • Routers in this context are called customer (C), customer edge (CE), provider edge (PE) and provider (P) routers.
  • Each VPN the service provider provisions for his customer requires a unique VPN routing and forwarding instance (VRF) in each provider edge (PE) router. This will create isolation and allow the use of overlapping RFC1918 address space among the provider’s customer base.
  • There are cases where a central resource needs to participate in more than on VPN instance, i.e. and overlapping VPN. Therefore, VRFs can be made more granular than VPNs and can participate in more than one VPN at a time. To handle the potential confusion that could arise in this scenario, a “route target” identifies the VPNs that a specific VRF is participating in. A set of route targets can be associated with a VRF or a VPN route, lending design flexibility.
  • VPN addresses in the service provider network need to be unique. Therefore, VPN IP addresses get a 64-bit “route distinguisher” added to the front of the existing 32-bit address. The new 96-bit address is exchanges between provider edge routers, using multiprotocol BGP. BGP also carries route attributes such as the route route via “extended communities”.
  • All provider edge routers require a unique /32 router ID, generally a loopback address. This is used for allocating labels and forwarding VPN packets via label switching across the provider core.
  • All provider edge rotuers will assign a unique label to each route in each VRF (even if the next hop is the same). These labels are distributed in conjuction with the 96-bit VPN addresses via multiprotocol BGP.
  • Ingress PE routers (the routers taking traffic from the customer edge router) create a two-level label stack assigned to the inbound VPN packets. The stack will contain a label assigned by the egress PE router, plus an IGP label that identifies the PE router, assigned via normal MPLS label distribution. This VPN packet gets the label stack prepended, with the MPLS packet being forwarded across the provider core.

Having read the summary, I think I get this better than I did reading the whole appendix with the working example. Funny how that works sometimes.