Virtual Networking Implementation Taxonomy

I’m not sure I wrote about the taxonomy of numerous virtual networking implementations. Just in case, here it is ;)

Layer-2 or layer-3 networks?

Some virtual networking solutions emulate thick coax cable (more precisely, layer-2 switch), giving their users the impression of having regular VLAN-like layer-2 segments.

Examples: traditional VLANs, VXLAN on Nexus 1000v, VXLAN on VMware vCNS, VMware NSX, Nuage Networks Virtual Services Platform, OpenStack Open vSwitch Neutron plugin.

Other solutions perform layer-3 forwarding at the first hop (vNIC-to-vSwitch boundary), implementing a pure layer-3 network.

Examples: Hyper-V Network Virtualization, Juniper Contrail, Amazon VPC.

Layer-2 networks with layer-3 forwarding

Every layer-2 virtual networking solution allows you to implement layer-3 forwarding on top of pure layer-2 segments with a multi-NIC VM.

Some virtual networking solutions provide centralized built-in layer-3 gateways (routers) that you can use to connect layer-2 segments.

Examples: inter-VLAN routing, VMware NSX, OpenStack

Other layer-2 solutions provide distributed routing – the same default gateway IP and MAC address are present in every first-hop switch, resulting in optimal end-to-end traffic flow.

Examples: Cisco DFA, Arista VARP, Juniper QFabric, VMware NSX, Nuage VSP, Distributed layer-3 forwarding in OpenStack Icehouse release.

Layer-3 networks and dynamic IP addresses

Some layer-3 virtual networking solutions assign static IP addresses to end hosts. The end-to-end layer-3 forwarding is determined by the orchestration system.

Example: Amazon VPC

Other layer-3 virtual networking solutions allow dynamic IP addresses (example: customer DHCP server) or IP address migration between cluster members.

Examples: Hyper-V network virtualization in Windows Server 2012 R2, Juniper Contrail

Finally, there are layer-3 solutions that fall back to layer-2 forwarding when they cannot route the packet (example: non-IP protocols).

Example: Juniper Contrail

A picture is worth a 1000 words

Why does it matter?

In a nutshell: the further away from bridging a solution is, the more scalable it is from the architectural perspective (there’s always an odd chance of having clumsy implementation of a great architecture). No wonder Amazon VPC and Hyper-V network virtualization (also used within the Azure cloud) lean so far toward pure layer-3 forwarding.

Need more?


  1. I would want to know what scope virtual networks offer from a network design or from en engineering point of view as well as network troubleshooting point of view...

    I mean apart from inital deployment ....orchestration systems will do thier work...what scope do Network enginners have in this cloud system?
  2. Yes, I wanted to know about this one. Do Azure or Amazon Clouds have Network Engineers to maintain the 'Network' part in case of connectivity issues within the cloud? Do they employ phy switches? If yes are they Cisco ones (if anyone is aware)....?
    1. They have more than 100.000 servers in a single data center? How do you think those servers are connected? Of course they're using physical switches, see also

      With 50 server-facing ports on a switch, a typical large cloud data center would have thousands of ToR switches and "a few" core switches. Don't you think you need a dedicated team to take care of them? Does it matter what job titles that team has?
    2. However, these engineers are plumbers providing 'connectivity'. All of the routing, addressing, firewalling, etc. is managed by the unwashed masses (developers / sys. admins). Yet it works day in and day out.
  3. You mean Devops Sysadmins know about routing very well??

    Then what we were doing all these years for?

    There are no dedicated plumbers....there are cloud architects doing all of these...

    Well you guys are not giving us any choice but to enter VM/Storage space and it will create job issues for VM/SAN guys as well....
    1. "Then what we were doing all these years for?" Getting in the way?

      I design and build these solutions for a living. The network architects I have worked with are outstanding. However once the design is complete, the physical remains fairly static (except for expansion). Its primary job is to provide an IP bus for the virtualized solutions above.

      I see a future wherein all of the supporting functions are subsumed by the virtual console. Network, compute storage, and security will be registered to the 'brain' and all configuration and operations orchestrated from the top down.

      Compute and storage have already been solved. Today, I can click a link and spin up a physical server, deploy the platform, and finish configuration. Same for storage, but to a limited degree.

      Some large automated networks have cracked the code as well. Their switches PXE boot, register to the controller, and are programmed accordingly. This could come to the consumer market within a few years.

      The tide is shifting from those who can administer to those who can orchestrate.
  4. Precisely....And that would be Network Admins Donning the role of VM/SAN and Cloud architects...and not the other way....
    Meaning NSX/ACI/SDN will create job issues for VM/SAN engss and not for Network what this Industry is harping about...
    1. Umm, no. Virtualized environments have pushed out server admins, and is working on storage. The next will be networking (within the datacenter).

      I can do it today with VMware/OpenStack/CloudStack. Once the plumbing is up, I can create, router, firewall, etc. multiple networks with no interaction from the network team.

      ACI will fail as it is going the wrong direction. Applications are the focus. The app/dev personnel will be able to deploy an application, attach compute and storage, then deploy networking. When they click go, all of the resources will be configured to support the Application.

      The network engineer will have to adapt as have the compute and storage admins. The Borg is the VM side of the house. All else will be assimilated. Even then, the app/dev will drive the VM side of the house.
  5. Thats what I am also implying the same..that we will....we will not stop only at SDN/NSX...we network engineers will ALSO ENTER VM and STORAGE....get it once for all.....we will be the be all and end need for VM/Storage engg like you...

    Also what about network outside of the DC? Do you think Enterprises will let a seprate team handle the physical netywork and VM team handle the virtualised network? Hell no... Virtualised network will also be handled by Seasoned Network engineers......and then once we get our hands on the VMware tools...we will slowly moved forwards understanding everything....

    For ACI, app are the main focus...looks like you have no clue on ACI.
    Also when we get our access to NSX..we may as well steer it towards ACI..who knows?? And we wont stop at that..we will go after Storage and VM and what you guys have learnt in 8 yrs, we will get there under 1 yr short we will ensure we will not go the admin will be out this time...we will setup networks, firewalls, VM, storage in one click...and when VM experts leave....we will intake only people with network background and train them on VM.Storage.

    First you handle a produciton NSX network and let me know....when there is connectivity blackout and the top mgmt is blowing down your will understand...
    1. Sorry to have hit a personal nerve. Was attempting to discuss the technology and culture shifts coming. I have designed, built, certified, and operated enterprise datacenters (including the network) so I have no sacred cows.

      I would ask, if network personnel are going to take over the everything, then why are they the last to the virtualization and next generation table?

      Thank you for a spirited conversation. However, I cannot compete with you at such degenerated level.
  6. Am sorry are the 'wrong' one then..I was pissed of with the rants going on...till I decided to plunge into VM/Storage....Well I was coming purely from this angle only and was not suggesting Network cannot or should not be virtualized...
    The industry did no good by insiting at the very beginning of the SDN that Network personnel were a gone extermely passionate about Networking...
  7. Hey Ivan,

    I am a L3/L4 Network engineer working purely on Cisco Products and Network technologies as of now with 10 years of experience. Am CCNP Certified.

    I have worked on almost all the LAN/WAN/Nexus technologies.

    How long will it take for a typical person like me to get a foothold into VM/SAN?
    VM/SAN work purely on L1/Physical....there is no routing/switching logic like in traditional networks. So I reckon we just need to know the facts. Build factual working knowledge of VM/SAN.

    I just attended an NSX walkthrough of building a simple network via NSX. Well there is nothing in it to build expertise on.

    Currently am involved with Network Automations but that's just a starting point.

    I just need a ball park figure. I know there is no definite answer.
    1. The only realistic answer I can give you is "It depends" ;) It took me a few months; but it all depends on how much time you have to study and how much real-life exposure you can get. However, things are not as complex (nor as easy) as they might seem.
Add comment