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.
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:
Unfortunately, the VPLS service is never totally transparent. While you might get STP running across VPLS (but probably only if you ask), I would be extremely surprised if the CE-switches could exchange LACP/PAgP packets; these packets would be usually intercepted by the first switch in the carrier’s network.
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.
Whenever you want to transport your data over a third-party IP infrastructure without exposing your addressing and routing structure (example: building a VPN across a public IP infrastructure), you need a mechanism that allows you to encapsulate your IP packets (which are not routable by the third-party IP infrastructure) into routable IP envelopes.
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.
A while ago, Packet Pushers did a Q&A podcast (or was it this one ... they’re all great) and one of the questions was “should I buy MPLS/VPN or VPLS service?” Greg’s response was along the lines of “Ivan would be the right one to answer this question” and as my regular readers and attendees of my webinars know, you can get a very comprehensive version of the answer in my Choose the optimal VPN service webinar (register here or buy a recording).
Brad asked me about the availability of a DCI webinar (short answer: early next year) and continued “As an enterprise engineer, I know very little of how the service providers engineer their networks. I'm aware you do have a service provider webinar as well but I am wondering which one of those would be most beneficial for me to attend.”
As we’ve already discussed some of his DC issues, I knew that he’s in the “sane” part of the DC universe (pure layer-3 interconnect, no vMotion or bridging between data centers) and thus has to solve a traditional routing design challenge.
For him, it makes no sense to wait for the DCI webinar; that one will cover the designs and technologies you need when everyone else is pushing you to implement long-distance bridging. It might also include LISP in DC and the load balancing tricks F5 does ... and I’ll try to give you as much ammunition as I can to help you persuade your boss that there are other things beyond bridge-everywhere craze.
During the Choose the Optimal VPN Service webinar (register here) I got this interesting question: “What are the (customer network) licensing requirements for various VPN solutions?” (the webinar covers MPLS/VPN, VPLS, pseudowires, GRE, GRE-over-IPSec, IPSec VTI, GETVPN, DMVPN and hybrid designs).
All MPLS-based solutions require no special license on the customer side; they are implemented by the Service Provider, the customer requires basic IP routing functionality. Furthermore, BGP is now included in the IP Base image that you get with every ISR router and it’s part of the base 6500/7600 image for quite a while.
GRE and DMVPN (w/o IPSEC) are (according to Feature Navigator) available in IP Base image. I’m positive the GRE part is true; I would check the DMVPN functionality on an actual box before placing the order (or order Advanced IP Services image). For IPSec you need Advanced IP Services or Advanced Security image.
According to an ISR G2 licensing document, you need SECK9 license for both DMVPN and IPSec.
Webinars are great (say most of the attendees ;) but I miss meeting people. Webinars are just the right mechanism for brief technology updates, overviews or in-depth configuration discussions, but it’s nearly impossible to do a lively design discussion involving a reasonably-sized group of engineers over the web. The desire to do a live event was thus slowly brewing for almost a year and finally turned into reality: on September 15th you can join me in San Jose for the first ever Ioshints Live event.
We’ll discuss two hot topics: data centers (I simply had to use the vapor word in the title) and VPN solutions. Both sessions will be focused on design issues and your real-life needs. The registration is open; if you decide to join us for the whole day, just register for both sessions.
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.