Building network automation solutions

9 module online course

Start now!

So-Called Modern VPNs: Marketing and Reality

Someone left a “killer” comment1 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 design2, but let’s unpack the “pub-sub” bit.

According to Wikipedia, “publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be”. The author of that comment somehow failed to realize that’s a perfect description of an L3VPN or EVPN design using BGP route reflectors and RT-based Outbound Route Filters. I already mentioned that in the LISP blog post, but it’s obviously too much of a nuisance to read the whole article before writing a dismissive comment.

As for network-as-a-service, I’m old enough to remember industry pundits telling us how networking is dead because every endpoint will use mobile networks with LTE VPNs. More than a decade later, we’re still slogging through the networking morass even though it should be easier to build networks with no wires. Also, according to the pundits, routing is dead because we have SD-WAN, and BGP and MPLS are obsolete. What’s funny is that people having these opinions couldn’t publish them without BGP and (oftentimes) MPLS doing their job in the background.

But wait, it gets better:

VPN overlays starts at the end points compute or mobile device and seamlessly and dynamically interconnects endpoints.

Time to go back to taxonomy. There are endpoint VPNs that the author of this comment is so excited about, and infrastructure VPNs implemented in routers3, firewalls, or dedicated encryption boxes… All of them could be implemented as an overlay on top of another network4, and all of them need some sort of control plane or orchestration system.

From the VPN traffic flow perspective, we have hub-and-spoke VPNs where all devices communicate through a set of central servers and peer-to-peer VPNs where the VPN devices can communicate directly. Traditional IPsec endpoint VPNs with VPN concentrators are a perfect example of hub-and-spoke VPN. Interestingly, BGP/MPLS L3VPN5 was one of the first peer-to-peer VPNs.

It’s also worth pointing out that endpoint peer-to-peer VPNs are nothing new. My kids were playing Minecraft using Hamachi (released in 2004) a decade ago, and I’m positive Hamachi was not the first peer-to-peer VPN6.

Finally, there are customer-operated VPNs (DMVPN, SD-WAN…) and provider-operated VPNs (Carrier Ethernet, VPLS, BGP/MPLS L3VPN…). We even build VPNs within data centers to implement virtual networks (VXLAN/EVPN, Cisco ACI, VMware NSX, all public cloud infrastructure).

There are great use cases for any technology or product I mentioned above, and saying “one of them sucks, you should only use the other one” makes as much sense as saying “Python and C/C++ are dead, you should use Swift or TypeScript”. There’s a slight difference between a fanboy and an engineer – an engineer considers the requirements and selects the optimal set of technologies that meet the requirements with minimum complexity.

We’re not done yet. Next comes a jab at the service providers:

Examples of VPNs are not EVPN or L3VPNs – those are SP customer locking tools.

L3VPN is a lock-in tool if you’re gullible enough to believe marketing slides and outsource your core routing to a third party. Numerous CxOs are in that category to the delights of various service providers. Smart customers use L2VPN and build their own networks on top of that, or use L3VPN as pure IP transport and build their own overlay on top of that transport (see also: SD-WAN).

EVPN is usually used to implement L2VPN (aka Carrier Ethernet) and if you manage to get locked into a single Carrier Ethernet… I’ll stop right there.

For a more thorough overview of VPN technologies, their applicability, and associated gotchas (including lock-in considerations) watch the Choose the Optimal VPN Service webinar.

Now for the final bit of that wonderful comment:

Real VPNs of current times are ZeroTier, TailScale etc.., LISP falls into the same modern camp.

ZeroTier and TailScale excel as endpoint VPNs, although both of them support gateway (relay) nodes7. If I had to implement an endpoint VPN these days, I would definitely consider them before thinking about IPsec clients and concentrators.

LISP is a totally different story. While there are endpoint LISP implementations, the only products pushing LISP (that I’m aware of) use it to implement infrastructure VPNs. Furthermore, based on the comments I got to recent blog posts, it looks like LISP refocused from cache-based forwarding towards a control plane that’s functionally equivalent to EVPN or L3VPN control plane.

To round up the VPN confusion: there are endpoint EVPN implementations (we discussed them in December 2021 Design Clinic), so what’s the difference between real VPNs and SP customer locking tools8? It’s obviously not the technology, but the way it’s used.


  1. Assuming you’re playing Buzzword Bingo ↩︎

  2. In the meantime, TRILL and SPBM are mostly dead, as are all proprietary fabric solutions like FabricPath, VCS Fabric, or Virtual Chassis Fabric. Everyone is building fabrics on top of layer-3 networks. Go figure… ↩︎

  3. An SD-WAN device is a router regardless of what the vendor marketing is telling you. So are all boxes called switches that happen to forward packets based on network-layer addresses. ↩︎

  4. Ever heard of IPsec tunnel mode? ↩︎

  5. The official name of this technology is (according to RFC 4364) BGP/MPLS IP Virtual Private Networks (VPNs). I will use L3VPN throughout this post to differentiate it from L2VPN. ↩︎

  6. Pointers to “prior art” are most welcome. ↩︎

  7. I’ve heard great things about TailScale coming from an environment that will definitely need gateway nodes. ↩︎

  8. Apart from I love shiny new toys and hate stuff that I had to work with in the past ↩︎

2 comments:

  1. From #RFC1925

    (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.

        (6a) (corollary). It is always possible to add another level of
             indirection (sometimes called a "modern VPN")
    
  2. I've been reading your blog for years, and all of your predictions have been spot on. Vendors can throw as many buzzwords as they want, but they can't change the fundamentals of how things work.

    Replies
    1. > All of your predictions have been spot on.

      Not at all. I'm constantly stumbling on old blog posts and saying "what were you thinking at that time 🥴". LISP on Nexus 1000v immediately comes to mind.

      > Vendors can throw as many buzzwords as they want, but they can't change the fundamentals of how things work.

      That's not about to change any time soon... it's just the question of how many people care about reality 🤷‍♂️

Add comment
Sidebar