Do We Still Need Subnets in Virtualized Networks?
The proponents of microsegmentation are quick to explain how the per-VM-NIC traffic filtering functionality replaces the traditional role of subnets as security zones, often concluding that “you can deploy as many tenants as you wish in a flat network, and use VM NIC firewall to isolate them.”
Unfortunately, we need multiple VLANs (or multiple routing domains) for other things besides security zones:
- Overlapping IP addresses in multi-tenant environments (or even across multiple cloned application stacks – I know that’s a Really Bad Idea, but I’ve seen environments where that was the only way to move forward). Good luck trying to figure out how to solve that with a stateful packet filter;
- Service insertion. The easiest way to insert a load balancer between application tiers is still to make the load balancer the first-hop router. You could use source-NAT (SNAT) on the load balancer to alleviate this requirement, but then you open a whole different can of worms.
We might stop misusing routing domains (or VLANs) for service insertion if we rewrite all the applications and make them service-aware, or once the virtualized networks start supporting proper service insertion functionality (in most cases it’s still done with VLAN stitching), but I haven’t yet heard of a solution that would allow duplicate IP addresses in the same VLAN/IP subnet.
Everything, and I mean everything, in the networking world has standardized on IP and Ethernet (or 802.2 framing). Thus for better for worse, the notion of a subnet or a mean to organize the IP addressing space will always be required.
What is happening with network virtualization, starting with MPLS actually, is dissociating things from IP that should have never been there in the first place... but we did not have much choices at the time. Things like proxying the identity of an individual, a group or a function via a subnet (HR department = subnet A or VoIP = subnet B), geo-location (subnet X exists only in data center A or city XX), etc.
IP is a forwarding mechanism, period. It has its characteristics that need to be engineered to work well and as such things like NAT and subnets will be required.
from a security perspective, relying on attributes that do not have any dependencies as to which address you have, network you came from or trying to reach (approach which is continuously failing us) is the right way to go.
Yes unfortunately I have heard that a flat network was just fine in the virtual world but I have heard more similar "truths" from the traditional networking and security teams which are just taking shortcuts rather than trying to understand how technology features can be associated and leveraged to deliver elegant solutions.
strangely enough what you described is exactly what we implemented 2 years ago at one of my previous employers.
The decision was to use /16 subnets for everything. So you would have a /16 for PROD, another one for DEV and another one for PREPROD etc.
Fully virtualized environment on ESX 4.1 with Nexus 1000v and Juniper vGW (imagine the support nightmware once the vendor blame game bagan).
Next hop gateway for VMs was vrf interface on Nexus 7k for respective environment. And Load balancer hanging off in one-arm mode off the 7k and SNAT. No physical DMZ for web servers, Web and App were all on the same bunch of ESX servers and security controlled by vGW kernel firewall. Definitely a powerpoint design that made it into production (and still running "somehow").
That being said I think this setup works but the moment you connect it to a traditional data center it becomes a huge mess. I can attest to it as I was there :). And to top it all off we had duplicate subnets in other environments protected by firewalls in the hope nobody would leak routes in and out of the respective "bubble".