Easy Virtual Network (EVN) – nothing new under the sun

For whatever reason, Easy Virtual Network (EVN), a configuration sugar-glaze on top of VRF-lite (oops, multi-VRF) that has been lurking in the shadows for the last 18 months erupted into the twittersphere after Cisco’s latest switching launch. I can’t possibly understand why the implementation of a decade-old technology on mature platform (Catalyst 4500 and Catalyst 6500) makes news at the time when 40GE and 100GE interfaces were launched, but the intricacies of marketing always somehow escaped me.

2012-02-08: Based on feedback from Andy Kessler (thank you!) I updated the post to include two facts I didn't notice before: EVN treats the global routing table like any VRF and it includes enhanced traceroute that displays VLAN tags and VRF names

Before going into the details, let’s clear the confusion created by people who don’t have the time to read the configuration guides:

  • EVN is not new. It’s been available on ASR 1000 for almost 18 months.
  • EVN is not an alternative to MPLS. VRF-lite has existed since the earliest days of MPLS/VPN (ok, OSPF was broken in the first release).
  • EVN is not proprietary. It’s VRF-lite over VLAN point-to-point subinterfaces. You can connect a Juniper or an HP box to the other end of the link and they'll work just fine.
  • EVN is not a technology (apart from route leaking between VRFs which happens within the router anyway). There's no new encapsulation scheme, packet format or protocol (apart from additional fields in ICMP response messages that enable enhanced traceroute functionality).
  • EVN is not Cisco’s evasive maneuver from the MPLS world. The design is old, the only new functionality is the simplified configuration CLI and improved route distribution between VRFs and global routing table.

I will not do a deep dive into EVN (unless there’s an outcry in the comments ;). The EVN whitepaper is pretty good, Q&A document gives you some more details, and the IOS XE configuration guide explains all the details.

Those of you who happen to have my first MPLS/VPN book can look up the technology behind the EVN configuration fa├žade at page 158 (Figure 8-5). Replace “Frame Relay” with “Ethernet/VLAN” and that 11-year-old diagram matches almost exactly Figure 3 from Cisco’s EVN White Paper.

I created an almost identical slide for the Enterprise MPLS/VPN Deployment webinar (included below). Notice the title: Multi-VRF Does Not Scale. A few reasons are given on the slide; you’ll find more of them in the book I already mentioned on page 157. Nothing fundamental has changed in the meantime. The CPUs are faster, but Multi-VRF still doesn’t scale (but since EVN is limited to 32 VRFs, I don’t really care).


Looks familiar?

If you need layer-3 path isolation for a few logical IP networks (VRFs) and are willing to run multiple copies of OSPF or EIGRP in your network (one per VRF), EVN just might be for you – it’s configuration is way less repetitive than traditional multi-VRF configuration, and it can import/export routes between VRFs and the global routing table without going through BGP (which is a major bonus). The enhanced traceroute functionality (displaying VRF names and VLAN tags on every hop) will also speed up your troubleshooting efforts.

Just remember what all those routing protocols do after every core link failure: each per-VRF routing protocol instance on every L3 switch in your EVN network will frantically chat, exchange data with its neighbors and try to recalculate the topology, even though all of them share the same physical topology.

16 comments:

  1. Thanks Ivan for this article.

    ReplyDelete
  2. My reading is the same as yours. But Light Reading article called it both "new" and "proprietary" and followed that statement by a quote from Cisco that kind of supported that supposition. I think that's why it blew up. If you google EVN you get Cisco articles from 2010 and 2011. Hardly "new". If you read them, it becomes apparent this is VRF-lite re-branded and cleaned up a bit (the configurations look almost identical, actually). The Light Reading article is here: http://www.lightreading.com/document.asp?doc_id=216987

    ReplyDelete
  3. Ironically, I'd followed up on this about an hour before I noticed this blog item among my RSS feeds. The docs say to check Feature Navigator (which I've never found very useful when I need it -- and it's running true to form).

    Searching it for "EVN" and "Easy Virtual" finds no feature hits. "Easy" comes up with many Easy VPN features -- different technology though. Anyway, that's exhausted my short list of obvious names for the feature in Feature Navigator. Knowing how well-implemented it is across platforms and in which code versions would certainly be useful.

    I'm interested because saving typing / simplification might be useful. We've deployed large-scale VRF-Lite (many devices, up to 10 VRF's) for some hospitals that need to isolate some gear, also a couple of L3 rural provider nets. Skills or skills depth and costs were drivers for VRF-Lite. Simplified CLI is a big deal. OTOH, old wine, new bottle, agree re the comments about dates on documents, etc.

    ReplyDelete
  4. I'm thinking it was announced today for its ability to *automate* virtual networks. Hehe. Fewer commands will auto-magically make it easy to configure multi-VRF now. Interesting day for announcement, however, I do think it will be valuable for the market. I don't think you agree, but with 6-7 VRFs required and deployed down to routed access layers...let's say 15 access switches. It will streamline configs without introducing MPLS in the campus. Don't ask what the problem with MPLS in the campus is ;)

    ReplyDelete
  5. Marketing...

    ReplyDelete
  6. So if I get you right EVN is basically Multi-VRF in the core over VLAN interfaces. Is my understanding correct?

    ReplyDelete
  7. FYI, I am a Cisco Employee working on EVN. EVN comes with a few very new things. One of them is Route Replication. It allows shared services between VRF in a more powerful way than BGP. It allows routes to be shared between the Global route table and other VRFs without limitations. BGP can only share 5 VRFs with 1000 routes per VRF in this situation.

    EVN has also improved the traceroute capability so that it will return the name of the VRF and VNET TAG on a hop by hop basis through the network. This uses some optional objects in ICMP defined by RFC4884.

    One of the reasons we say it is an alternative to MPLS is that it will run on platforms that don't support MPLS - such as the Catalyst 4500.

    If you want to read about these and the other options go to http://www.cisco.com/go/evn - or just google - Easy Virtual Network.

    ReplyDelete
  8. Andy, thanks for the excellent feedback!

    I did under-emphasize the fact that global routing table became just another RIB that behaves the same way as any othe (fixed) ... but then there were good reasons it did not when MPLS/VPN was used primarily in the Service Provider world.

    However I can't understand where you got the '5 VRFs with 1000 routes per VRF'. This is definitely not an architectural limitation of MPLS/VPN (as I have running networks doing the same thing on an order-of-magnitude higher numbers). Is it a platform-specific issue that you encountered?

    The improved traceroute capability is another nice feature that will definitely help enterprise network engineers.

    BTW, are there any plans to have EVN on non-IOS-XE platforms? I can see cases where it would be a perfect fit for small remote sites.

    Last but definitely not least, if you'd like to have a more in-depth conversation, why don't you contact me directly? http://www.ipspace.net/Contact

    ReplyDelete
  9. Hi Ivan,

    Yes, the '5 vrf 1000 routes' is not a MPLS/VPN limitation - its an IOS issue. Yes, it was a restriction requested by SP customers and we never removed it. Go ahead and google '1000 routes 5 vrf' and you'll see a Cisco doc. The doc I just read says only 5 VRFs but that the 1000 routes can be increased - I'll have to double check that.

    Yes, it would be nice to get EVN on non-IOS-XE platforms. If we get enough customer demand we can build the business case. Please mail to evn@cisco.com and request it ;-)

    I'd be happy to have an in-depth conversation.
    Lets set that up.
    Right now I need to go to sleep 8-)

    Andy

    ReplyDelete
  10. Ivan,

    Thanks for the update. The last point that I would comment on is about 'new-ness'. Yes, EVN shipped on the ASR1000 back in Nov 2010. That was mainly due to all the multiple variables associated with our release process - the ASR1000 team was ready and aggressive to ship EVN. But the fact is - is that EVN is really a technology focused on switched campus networks. What is new about the announcement last week is that EVN is now shipping on the Cat6500 and Cat4500. That is new and a much bigger deal and we can say that EVN has now 'Arrived'.

    We have been talking about EVN for years - but now - this week - it much more useful. And thats why we had press releases and announced it. Call it marketing if you want - but it is reality and timing.

    Andy

    ReplyDelete
  11. Ah, that one. Unless I'm grossly mistaken, the limits you mention apply only to import from global table into VRFs (which is a kludge anyway), and if I read between the lines correctly, the use case is global blackhole routing.

    If I would be a Service Provider leaking routes from global into VRF, I'd want to have some hard limits as well, otherwise the full Internet table could accidentally leak into numerous VRFs (fat fingers at work), blowing up the RIB and FIB.

    ReplyDelete
  12. These are excellent inputs Andy. Helps clarify things perfectly. Great job!!

    ReplyDelete
  13. I just wanted to add that EVN sounds very interesting to me from a multi-layer campus design perspective. We are looking for ways to isolate certain networks so that we can provide a centralized point of control, such as for point-of-sale systems.

    MPLS is not really feasible in our environment, as it could only run between a few core 6500s. We would still need to provision VRFs on all distribution routers (3750/4500) and use VRF-lite to connect them to VRFs on the core 6500s. EVN will greatly simplify these links, without the need to run MPLS and BGP.

    Lastly, the benefits of better troubleshooting with the "routing-context" command encourages me to implement VRFs also at the edge of our network (as opposed to buying twice the gear). This "routing-context" provides some of the same benefits as virtual-device-contexts (VDC) on the Nexus 7000.

    ReplyDelete
  14. does anyone see EVN appearing on the Nexus 5548/96 platform with the L3 card ?

    ReplyDelete
  15. My AM & SE pointed me at the 4500-x 16 port 10G switch to replace the old 3750G-12S in my distribution layer. With the enterprise license it now supports EVN and MPLS. So it's both cheaper and better then the 3560E-12D-E. Oh, how nice, there is now an EOL announcement for the 3560E-12D...

    I'm still very nervous about doing an MPLS campus deployment, but EVN doesn't help support isolating stupidly vulnerable medical systems, credit card systems, etc on my metro ethernet network. I really don't want to deploy EVN for the 30 campus sites and then have the same guys have to learn MPLS anyhow to support the clinics.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.