You are here: Home / Blog / Cisco Easy Virtual Network – because MPLS is too complicated¡

Cisco Easy Virtual Network – Because MPLS Is Too Complicated¡

1st February 2012 by 13 Comments

Cisco has a protocol called Easy Virtual Networking. It’s a Cisco proprietary version of MPLS for Enterprises because it’s too complicated.

On the bad side, it’s proprietary, needs special line cards, offered on Catalyst 4500 and 6500 and the ASR 1000 only with special software requirements.

From the EVN Q&A

Q. Will EVN interoperate with my current VRF-Lite deployment?

A. EVN is backward compatible with VRF-Lite. The two technologies can be deployed in the same network for a smooth transition to EVN. Make sure the EVN “vnet tag” value matches the 802.1Q VLAN ID on the VRF-Lite device.

Q. Is there interoperability with existing WAN solutions?

A. EVN in the campus is completely compatible with the WAN solutions MPLS-VPN, MPLS-VPN over mGRE, and DMVPN.

Q. How many EVNs are supported per platform, and what are the scales and limitations?

A. Today 32 virtual networks are supported per platform. This may be increased in the future.

I’m at a loss for words. Why would Cisco create this proprietary standard ?

Anyone want to stand up and argue for this ?

Footnotes and Reference

Overview of Easy Virtual Network

Easy Virtual Network Q&A

Product Page

Configuration Guide

Filed Under: Blog Tagged With: ,
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://twitter.com/JuanLage Juan Lage

    Greg, glad to see you posting about this so soon … If I may, let me begin by highlighting a contradiction in your statement: “a proprietary standard”. If it’s proprietary it is not standard by definition no?

    Jokes aside, EVN isn’t a proprietary version of MPLS. It is proprietary yes, in the sense that runs only within Cisco devices, but it does not require new encapsulation or tagging technologies and certainly does not re-use MPLS in any sort of way. Why create it? There are many customers currently using VRF-Lite to implement small and mid-sized virtualized networks, connecting the VRFs using point to point vlans, etc. It is cumbersome to manage. Why not use MPLS you’d wonder? Because many customers don’t want to learn about MPLS VPN, don’t want to run a label switching mechanism which isn’t supported in all hardware, don’t want to manage LDP, BGP, etc. They prefer to keep it simple, yet they want to do better than using point to point vlans and interfaces to connect VRFs. Cisco is providing a solution for such customers. 

    • http://www.brianraaen.com/ Brian Christopher Raaen

      I would argue that Cisco should have rather than creating a new protocol, have just used the existing ones.  Customers are wanting Cisco to make it “just work”.  Why not just have some setting that auto-magically apply a cookie cutter based mlps config using the asdm gui.  The *PLS family, plus lldp ought to be able to transport the needed configs.  The only reason Cisco is adding a proprietary protocol is to create “vendor lock” with users who don’t understand the technology.

      Rather than reinventing a proprietary wheel, make the existing wheels easier to use.

    • http://twitter.com/yelfathi Youssef El Fathi

      Hello Juan, first of all thanks for your comment i understand your point of view but in the reality who’s gonna implement and support this technology not the final customer but rather the Cisco VAR and frankly we prefer proven protocols and keep our known best practices than a new protocol that will be only available for Cisco.
      I would like to see in the future how many customers are going to take that way.

      • http://twitter.com/JuanLage Juan Lage

        Hello Youssef, you raise a very valid point. In all truth, EVN is simple to get around and easy to troubleshoot because it relies on technologies that you are surely familiar with (dot1q tags, routing protocols,etc.). Granted that once you know something (i.e. MPLS) it is no longer complicated and you would just replicate that to other customer environments. I understand your point very well on that, however it is complicated to keep in balance the customer demand and the partner demand. While it is easy to say Cisco is doing this to favor vendor lock-in, the reality is that there is an interest in addressing a customer demand. Is Cisco addressing it in the best way? Time will tell …

        • aliguori

          It’s not new, it’s not propietary, its just vrf lite but with a new fashion way to configure the subinterfaces and pass the vlan over the trunks. I dont see big future on this.

  • http://twitter.com/paliasp Panagiotis Palias

    I think the same question goes to all of the rest proprietary standards and ideas of Cisco (isl, *grp, wildcards).
    Maybe they are bored to do the interconnection tests between Cisco stuff and other vendors and they create a new protocol.

    • Scott Hardin

      Wow, do some research. When EIGRP was introduced, it was because the options were RIPv2 and OSPF for enterprise routing. No one really knew OSPF, and EIGRP just worked. EIGRP is not a perfect protocol and has limits, but at the end of the day you didn’t need to know about OSPF area 0 repair, or why my NSSA ABR is not translating Type 7 LSA’s. Most “proprietary” things start as an attempt to fix some bigger issue or make things work better, like FabricPath, until standards-based solutions are ratified, like TRILL.

    • http://etherealmind.com Etherealmind

      It’s more complicated than that. ISL & HSRP are examples of Cisco tools that came well ahead of any standards development. FabricPath is a set of proprietary extensions to TRILL i.e. it’s a superset of the standard. At the time, they offer solutions to networking problems. 

      Both use cases are valid but cause problems for interoperability for many years afterwards. 

      Not so clear cut. 

  • http://twitter.com/WildSubnet Matthew Tighe

    Is this really a new protocol? Seems like VRF-lite rebranded.

  • Tim

    I work on a campus network created strictly from 6500s, 4500s, 3750 stacks, with Nexus 7ks in the core (no “routers”). I was really hoping that this technology would be supported on existing hardware, considering that all it really seems to be doing is using unnumbered interfaces based upon the IP tied to the vnet trunk.

    I would love to run MPLS in our environment. However, MPLS isn’t supported on 4500s and we aren’t going to get metro versions of the 3750s as they only have 24 ports.

    So we are left configuring VRF-lite in our environment. I just added 2k lines of code to each of our Nexus 7ks to support it. If EVN was supported on all of these devices, it would have been a lot less. (Obviously, if MPLS was supported, even better).

    I wouldn’t bash Cisco for creating an easier way of deploying VRF-lite. Better to focus on why MPLS isn’t supported on all of their gear.

  • gary proefke

    Greg, Thanks for posting accurate Q&A on EVN. I’ll identify myself as a Cisco person who would like to offer corrections to a couple of points… EVN is not a new protocol and not a new version of MPLS. As one of your commenters points out, it is really a simplification of VRF-Lite (about 10x simpler in terms of lines of code, in fact), fully compatible with VRF-Lite and for hand-offs to an MPLS PE. People who have used VRF-Lite will really appreciate the difference. No, it doesn’t require special line cards. It is limited to Catalyst 4500 and 6500 switches and ASR 1000 Series routers running the correct version of Cisco IOS Software at this time. Thanks again for creating a dialog about this new capability

  • Vinman1000

    There are and will always be two ways to do the same thing. The Cisco way and the standard way. Some examples include: TDP-LDP, dot1q-ISL, LACP-PAGP, MIST-MST, just to name a few. Cisco is in such a hurry to get to market first that they release their version as fast as possible. Then the standards get ratified and we have two. It makes it difficult on engineers as there are now two technologies to study. Job security I guess.

  • http://www.itel.ca/ Enterprise SIP Trunking Canada

    Nice discussion regarding EVN protocol. I was also searching such stuff for a long while and at last I found it here. I hope you will come in future more update. Keep it up.