Duncan Epping, the author of fantastic Yellow Bricks virtualization blog tweeted a very valid question following my vCDNI scalability (or lack thereof) post: “What you feel would be suitable alternative to vCD-NI as clearly VLANs will not scale well?”

Let’s start with the very basics: modern data center switches support anywhere between 1K and 4K (the theoretical limit based on 802.1q framing) VLANs. If you need more than 1K VLANs, you’ve either totally messed up your network design or you’re a service provider offering multi-tenant services (recently relabeled by your marketing department as IaaS cloud). Service Providers had to cope with multi-tenant networks for decades ... only they haven’t realized those were multi-tenant networks and called them VPNs. Maybe, just maybe, there’s a technology out there that’s been field-proven, known to scale, and works over switched Ethernet.

Guess what: hundreds of Service Providers worldwide use something called MPLS to scale their VPN offerings, be it on layer 2 (VPLS) or layer 3 (MPLS/VPN). Huge high-speed networks serving tens or hundreds of thousands of customers have been built on MPLS and they work well. While I might understand that the enterprise network designers feel uncomfortable considering MPLS (although MPLS/VPN can solve numerous enterprise problems as described in my Enterprise MPLS/VPN deployment webinar), there is no reason why service provides wouldn’t reuse the same technology they’ve used in their WAN networks for the last decade in their data centers.

Now imagine VMware would actually have done the right thing and implemented a VPLS-capable PE-router in their vSwitch instead of taking a product targeted at building labs, porting it from userland into kernel space and slapping a GUI on top of it.

The VPLS approach would not solve the security issues (MPLS backbone has to be trusted), but would solve the scalability ones (no need to bridge in the data center core), breeze by the VLAN numbering barrier, and enable instant inter-DC connectivity (or private-to-public cloud connections) without external bridging kludges when using mGRE or L2TPv3-based pseudowires. The full effect of the scalability improvements would only become visible after deploying P2MP LSPs in the network core, and I’m positive Juniper would be very happy to tell everyone they already have that built into their gear.

Moving further into dreamland, imagine VMware would do the very right thing and implement MPLS/VPN PE-router in their vSwitch. Zero bridging in the backbone, seamless L3 mobility, no need for bridging kludges, and layer-3 inter-DC connectivity with MPLS/VPN-over-mGRE. A few moronic solutions relying on layer-2 inter-server connectivity would break, but remember that we’re talking about public infrastructure clouds here, not your typical enterprise data center.

Obviously we won’t see either of these options in the near (or far) future. Implementing something that actually works and solves scalability problems using an old technology is never as sexy as inventing a new rounder wheel that just might never work in practice because it’s too brittle, not to mention that developing a PE-router functionality would require serious amount of work.

More information

Enterprise MPLS/VPN Deployment webinar describes the typical MPLS use cases in enterprise networks, the underlying technology and high-level design and implementation guidelines.

In the Data Center Interconnects webinar I’m describing how you can use MPLS/VPN to provide end-to-end path isolation across multiple data centers without deploying stretched VLANs or inter-DC bridging.