Never in my time would I have thought I would see such a large divide between “old school” and the new way of doing things. What brought this up? VMware NSX, plain and simple.
In the Traditional model we’re tagging links to Vmware hosts. Some environments are more precise than others about what tagged traffic goes where and others just leave the default all, Cisco, and everything floods to the hypervisor. Once inside the hypervisor you can have many virtual machines attached to a specific vswitch and different port groups. If you need East-to-West traffic (that is, one virtual machine that needs to talk with another on the same hypervisor having different VLAN IDs attached to a port group on the same vswitch or virtual machines on different vswitches) that traffic must leave the hypervisor, go through the physical link and be routed back down, possibly the same, physical link into the appropriate vswitch/port group. Now, imagine that you have to vMotion between hypervisors configured at different points in history, on different physical switching infrastructure. Unless these were exact duplicates, you’re likely to miss something and you’re going to require a change in the logical setup of the physical switch, something that can take time if you are in a change controlled environment. Even then, at worst, you have created downtime in your business and people aren’t happy. None-the-less, you’re looking at coordinating efforts between multiple groups and then you have to wait for all this configuration to take place, regardless of whether this is done with some software to manage the switches, home brew scripts (blah!), or by hand at the CLI.
Welcome to the new era – NSX
Now imagine if we, network people, build a strong backbone network, either Layer 3 to the hypervisor or traditional layer 2, make it highly available and never have to worry too much about virtual machines moving between guests? Well, in my strong opinion, this is possible with a layer 3 implementation to the hypervisor using ECMP with a protocol such as OSPF, BGP or ISIS. In an OSPF implementation you could, lets say, have each “rack” bet a different OSPF area connecting to your physical backbone (area 0). Once you have this setup you’re going to push all the Layer 2 setup into the hypervisor. Now, your east-to-west traffic will no longer leave the hypervisor; thus, never traversing that physical link and routed/switched in the software, much faster than through the wire, into a physical device and back into the hypervisor. However, this is only part of what NSX and overlay networking can provide you the ability to span layer 2 VxLAN segments on IP (Layer 3) backbone, seamlessly. This means, in our scenario of having each rack/pod be an OSPF area, we could span that VxLAN across the IP infrastructure and no one knows anything different.
VxLANS brought us many new and interesting innovations to the networking world; however, NSX has taken it a step farther and even simplified it. In the traditional VxLAN world we needed multicast support, something even some CCIEs I have met still aren’t well versed in, and NSX doesn’t require the use of it. NSX is much more intelligent and helps to reduce traffic overhead by placing more intelligence with controllers alongside the NSX manager. These are just a few pieces of the puzzle, I don’t want to delve into specifics or bore you with details; however, the network is finally changing and those who were riding the wave of virtualization are poised to have a smooth landing; however, those who resisted, or are still resisting, will have a long and painful road ahead of them.