Category: MPLS VPN
We had the usual gloomy December weather during the end-of-year holidays, and together with the partial lockdown (with confusing ever-changing rules only someone in Balkans could dream up) it managed to put me in OCD mood… and so I decided to remove broken links from the old blog posts.
While doing that I figured out how fragile our industry is – I encountered a graveyard of ideas and products that would make Google proud. Some of those blog posts were removed, I left others intact because they still have some technical merits, and I made sure to write sarcastic update notices on product-focused ones. Consider those comments Easter eggs… now go and find them ;))
Remember how earlier releases of Nexus-OS started dropping configuration commands if you were typing them too quickly (and how it was declared a feature ;)?
Mark Fergusson had a similar experience on Cisco IOS. All he wanted to do was to use Ansible to configure a VRF, an interface in the VRF, and OSPF routing process on Cisco CSR 1000v running software release 15.5(3).
Here’s what he was trying to deploy. Looks like a configuration straight out of an MPLS book, right?
Steve Krause created a full-blown network services deployment solution, including post-deployment validation of OSPF and BGP routing, while attending Building Network Automation Solutions online course (I prefer course attendees working on real-life problems instead of artificial ones).
Hope you’ll enjoy exploring it ;)
I think that EVPN is an excellent standard for those who love Layer 2 (L2) services, we may say that it is an evolution of the implementation of the VPLS service, which addresses some limits in the original standard (RFCs 4761 and 4762).
I might be missing something, but in my opinion there’s no similarity between EVPN and VPLS (apart from the fact that they’re trying to solve the same problem).
I always encourage the students attending the Building Network Automation Solutions online course to create solutions for problems they’re facing in their networks instead of wasting time with vanilla hands-on assignments.
Francois Herbet took the advice literally and decided to create a solution that would configure PE-routers and create full-blown device configurations for CE-routers.
Here’s a question I got on one of my ancient blog posts:
How many OSPF process ID can be used in a single VRF instance?
Seriously? You have to ask that? OK, maybe the question isn’t as simple as it looks. It could be understood as:
Over a month ago I decided to create a lab network to figure out how to solve an interesting Inter-AS MPLS/VPN routing challenge. Instead of configuring half a dozen routers I decided to develop a fully-automated deployment because it will make my life easier.
I finally got to a point where OSPF, LDP, BGP (IPv4 and VPNv4) and MPLS/VPN configurations are created, deployed and verified automatically.
I got into an interesting discussion with Johannes Luther on the need for VRFs and he wrote:
If VRF = L3 virtualization technologies, then I saw that link. However, VRFs are again just a tiny piece of the whole story.
Of course he’s right, but it turns out that VRFs are the fundamental building block of most L3 virtualization technologies using a shared infrastructure.
The only answer I could give is “it depends” (it’s like asking “Do animals need wings?”), and here’s my attempt at building a decision tree:
You can use the decision tree to figure out whether you need VRFs in your data center or in your enterprise WAN.
One of my readers sent me interesting feedback after reading my explanation of why I’d try not to use OSPF as a routing protocol between hosts and ToR switches. He said:
Unfortunately we can’t use BGP because IBM mainframes support only OSPF or RIP, so we decided to use VRFs instead.
Here’s what they did:
One of my users couldn’t get the inter-VRF NAT to work after watching the DMVPN webinars (no real surprise there, the VRF lite concept is covered in more details in the Enterprise MPLS/VPN webinar) so I decided to write a short document describing the details.
After discussing the basics of MPLS and LDP in our Tech Talks chat, Seamus Gilchrist and myself focused on a concept that perplexes many networking engineers entering the MPLS world: the relationship between Forward Equivalence Classes (FEC), LDP and BGP.
One of my readers sent me an interesting challenge:
We have two MPLS providers sending us default routes and it seems like whenever we have problem with SP1 our failover is not happening properly and actually we have to go in manually and influence our traffic to forward via another path.
Welcome to the wondrous world of byzantine routing failures ;)
MPLS bottom-of-stack bit confused one of my readers. In particular, he had a problem with the part where the egress MPLS Label Switch Router (LSR) should go from labeled (MPLS) to unlabeled (IPv4, IPv6) packets and has to figure out what’s in the packet.
Someone recently sent me this scenario:
Our CIO has recently told us that he wants to get rid of MPLS because it is too costly and is leaning towards big Internet lines running IPSEC VPNs to connect the whole of Africa.
He was obviously shopping around for free advice (my friend Jeremy Stretch posted his answers to exactly the same set of questions not so long ago); here are the responses I wrote to his questions: