It has been nearly 20 years since VLANs were introduced. A move to make them virtual with VXLAN (Virtual Extensible VLAN) is now generating some interesting threads of resistance. A thread by Ken Duda tries to tease out architecture concerns.
Denton: the simple way to think about VXLAN is that each neighbor VTEP [VXLAN Tunnel End Point] is like a switchport (bridging endpoint) and ordinary 802.1d MAC learning/aging/unknown-DA-flooding applies, where IP multicast takes the place of LAN broadcast. So, when some endstation moves, the next time they send a broadcast or send a unicast to you, you say to yourself, “gee, I didn’t expect to see that (segment, MAC address) come from that VTEP IP source address,” and then you update your MAC table accordingly. Just like ordinary layer 2 bridging. Likewise with VRRP [Virtual Router Redundancy Protocol] — if the new VRRP active router sends gratuitous ARP requests (as per the VRRP spec), then these ARPs are delivered via VXLAN-encapsulated IP multicast to all VTEP’s (that carry the router interface’s segment and thus subscribed to the IP multicast group), and they all then update the router’s MAC address in their MAC tables accordingly.
Encapsulation of MAC in IP might seem scary and more prone to hijack, but then again encapsulation logically follows computers inside computers.
The question should not be whether we can get old tools to handle all change. That’s always a risk of progress and it can be a good problem to have — market for new tools.
Given that tools evolve a question also then is not whether we lose the ability to see inside (encapsulated does not have to mean opaque/crypto), but whether encapsulated assets can be given controls as secure/robust as their wrapper.
To this end, Denton Gentry has written up a nicely illustrated follow-up to the thread started by Ken.
The encapsulated packet retains its Inner MAC header and optional Inner VLAN, but has no Inner CRC. When VMs send packets to other VMs within a server they do not calculate a CRC, one is added by a physical NIC when the packet leaves the server. As the VTEP is a software component within the server, prior to hitting any NIC, the frames have no CRC when the VTEP gets them. Therefore there is no integrity protection end to end, from the originating VM to receiving. This is another case where even on L2 networks, the Ethernet CRC does not work the way our intuition would suggest.
