Category: VPN

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.

read more see 2 comments

Layer-3 Carrier Ethernet

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.

read more add comment

EVPN: The Great Unifying Theory of VPN Control Planes?

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).

read more add comment

Reinventing SSL VPN (RFC 1925 Strikes Again)

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.

read more see 2 comments

Who’s Pushing Layer-2 VPN Services?

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.

read more see 10 comments

Ethernet-over-VPN: What Could Possibly Go Wrong?

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?

read more see 10 comments

Midokura’s MidoNet: a Layer 2-4 virtual network 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.

read more see 23 comments

VPN Network Design: Selecting the Technology

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.

read more add comment

Solving the MPLS/VPN QoS Challenge

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.

Typical MPLS/VPN demarcation point

Typical MPLS/VPN demarcation point

read more see 6 comments

Tunnel Route Selection and DMVPN Tunnel Protection Don’t Work Together

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.

read more see 7 comments
Sidebar