Category: VPN

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.

To understand the principles of DMVPN Phase I, remember these facts:

Arnold sent me an excellent question yesterday; he bought my Deploying Zone-Based Firewalls book, but found no sample configurations using IPSec VPN. I was able to find a few sample configurations on CCO, but none of them included the self zone. The truly interesting bit of the puzzle is the traffic being received or sent by the router (everything else is self-explanatory if you’ve read my book), so those configurations are not of great help.

Realizing that this is a bigger can of worms than I’ve expected, I immediately fixed the slides in my Choose the Optimal VPN Service webinar, which now includes the security models for GRE, VTI and DMVPN-based VPN services.

Ever since I’ve figured out how to explain complex topics to bright engineers, I wanted to develop content (books, courses, documents) that explained (in this order):

• The Big Picture and WIIFM (What will the student gain by understanding and deploying something based on what I’m describing).
• How the technology we’re using actually works (remember: knowledge, not recipes) and finally
• How to configure, monitor and troubleshoot the actual boxes used to build the solution.

I’m positive you agree this approach makes perfect sense, and every now and then I’ve managed to get it right (for example, in the MPLS VPN books). Unfortunately, you’re often facing an uphill battle, as people want to focus on hands-on topics and hate to learn why things work the way they do instead of memorizing recipes like “Thou shalt not have more than 3 OSPF areas per router”.