Category: VPN

Yesterday’s blog post discussed the traffic flow and the routing information flow in a hub-and-spoke VPN design (a design in which all traffic between spokes flows through the hub site). It’s time to implement and test it, starting with the simplest possible scenario: a single PE router using inter-VRF route leaking to connect the VRFs.

Béla Várkonyi wrote a succinct comment explaining why so many customers prefer layer-2 VPNs over layer-3 VPNs:

The reason of L2VPN is becoming more popular by service providers and customers is about provisioning complexity.

Someone left a “killer” comment¹ after reading the Should We Use LISP blog post. It start with…

I must sadly say that your view on what VPN is all about is pretty rusty and archaic :( Sorry! Modern VPNs are all pub-sub based and are already turning into NaaS.

Nothing new there. I’ve been called old-school guru from an ivory tower when claiming TRILL is the wrong direction and we should use good old layer-3-based design², but let’s unpack the “pub-sub” bit.

One of ipSpace.net subscribers asked for my opinion about Adaptive IP, a concept promoted by one of the optical connectivity vendors. As he put it:

My interest in Carrier Ethernet moving up to Layer 3 is to see if it would be something to account for in the future.

A quick search resulted in a marketecture using Segment Routing (of course) and an SDN controller (what else could one be using today) using Path Computation Element Protocol (PCEP) to program the network devices… and then I hit a regwall. They wanted to collect my personal details to grace me with their whitepaper, and I couldn’t find even a link to the product documentation.

I claimed that “EVPN is the control plane for layer-2 and layer-3 VPNs” in the Using VXLAN and EVPN to Build Active-Active Data Centers interview a long long while ago and got this response from one of the readers:

To me, that doesn’t compute. For layer-3 VPNs I couldn’t care less about EVPN, they have their own control planes.

Apart from EVPN, there’s a single standardized scalable control plane for layer-3 VPNs: BGP VPNv4 address family using MPLS labels. Maybe EVPN could be a better solution (opinions differ, see EVPN Technical Deep Dive webinar for more details).

Some of my readers got annoyed when I mentioned Google’s BeyondCorp and RFC 1925 in the same sentence (to be perfectly clear, I had Rule#11 in mind). I totally understand that sentiment – reading the reactions from industry press it seems to be the best thing that happened to Enterprise IT in decades.

Let me explain in simple terms why I think it’s not such a big deal and definitely not something new, let alone revolutionary.

Here’s another great point Tiziano Tofoni raised in his comment to my EVPN in small data center fabrics blog post:

I cannot understand the usefulness of L2 services. I think that the preference for L2 services has its origin in the enterprise world (pushed by well known $vendors) while ISPs tend to work at Layer 3 (L3) only, even if they are urged to offer L2 services by their customers.

Some (but not all) ISPs are really good at offering IP transport services with fixed endpoints. Some Service Providers are good at offering per-tenant IP routing services required by MPLS/VPN, but unfortunately many of them simply don’t have the skills needed to integrate with enterprise routing environments.

One of my readers sent me this question:

I'm having an internal debate whether to use firewall-based VPNs or DMVPN to connect several sites if our MPLS connection goes down. How would you handle it? Do you have specific courses answering this question?

As always, the correct answer is it depends, in this case on:

One of my readers sent me a link to SoftEther, a VPN solution that

[…] penetrates your network admin's troublesome firewall for overprotection. […] Any deep-packet inspection firewalls cannot detect SoftEther VPN's transport packets as a VPN tunnel, because SoftEther VPN uses Ethernet over HTTPS for camouflage.

What could possibly go wrong with such a great solution?

Almost everyone agrees the current way of implementing virtual networks with dumb hypervisor switches and top-of-rack kludges (including Edge Virtual Bridging – EVB or 802.1Qbg – and 802.1BR) doesn’t scale. Most people working in the field (with the notable exception of some hardware vendors busy protecting their turfs in the NVO3 IETF working group) also agree virtual networks running as applications on top of IP fabric are the only reasonable way to go ... but that’s all they currently agree upon.

One of the answers I got to my “How would you use VPLS transport in L2 DCI” question was also “Can’t you just order two VPLS services, use them as P2P links and bundle the two links into a multi-chassis link aggregation group (MLAG)?” like this:

After all the DMVPN-related posts I’ve published in the last days, we’re ready for the OSPF-over-DMVPN design challenge, but let’s step back a few more steps and start from where every design project should start: deriving the technical requirements and the WAN network design from the business needs.

Do I Need a VPN?

Whenever considering this question, you’re faced with a buy-or-build dilemma. You could buy MPLS/VPN (or VPLS) service from a Service Provider or get your sites hooked up to the Internet and build a VPN across it. In most cases, the decision is cost-driven, but don’t forget to consider the hidden costs: increased configuration and troubleshooting complexity, lack of QoS over the Internet and increased exposure of Internet-connected routers.

After I made the “duct tape of networking” joke, I quickly became a GRE lover (according to @Neelixx – another Twitter account lost in the mists of time). Jokes aside, let’s see where it makes sense to use GRE.

Two weeks ago I wrote about the challenges you’ll encounter when trying to implement end-to-end QoS in an enterprise network that uses MPLS/VPN service as one of its transport components. Most of the issues you’ll encounter are caused by the position of the user-SP demarcation point. The Service Providers smartly “assume” the demarcation point is the PE-router interface… and everything up to that point (including their access network) is your problem.

Cisco has introduced Tunnel Route Selection, another “somewhat” underdocumented feature in IOS release 12.4(11)T (reading the sparse documentation, it appears to be a half-baked kludge implemented for a specific customer). I was wondering for a long time why I would ever want to use this feature, until Floris Martens asked me a question about a redundant DMVPN network using two ISPs, and all of a sudden it all made a perfect sense.