VMware vShiled Manager - VXLAN limit

We all know that all technologies has some limits. Only important thing is to know about particular limits limiting your solution.

Do you know VMware vShield Manager has limit for number of virtual networks?

There is the limit 5,000 networks even you use VXLAN network virtualization. So even VXLAN can have theoretically up to 16M segments (24-bit segment ID) you are effectively limited to 5,000 which is not significantly more then old VLAN ID limit of 4,096 (12-bit segment ID).

The most strange thing is that this limit is not documented on vSphere Configuration Maximums. There are documented only following network limits:

• Static/Dynamic port groups per distributed switch = 6,500
• Ports per distributed switch = 60,000
• vCloud Director "Number of networks" = 10,000

Thanks Tom Fojta for this information and link to VMware KB 2042799.

On top of that the current VMware VXLAN implementation provide VXLAN based network overlay only in single vCenter domain so it will not help you with network tunnel for DR (VMware SRM) use case where two vCenters are required.   

So only two benefits of current VMware VXLAN implementation I see today are:

• software defined network segments in single vCenter domain allowing automation of VXLAN provisioning. Nice blog about it is here.
• split between physical networking segments (system VLANs, internet VLANs, MPLS VLANs, ...) and multi-tenant virtual network segments used for tenant's private use.

To be honest even those two benefits are very useful and limits will increase year by year as technology evolves and matures. That's usual technology behavior.

Network Overlays vs. Network Virtualization

Scott Lowe published very nice blog post (philosophy reflection) about "Network Overlays vs. Network Virtualization".

And this was my comment to his post ..

Scott, excellent write-up. As always. First of all I absolutely agree that good definitions, terminology, and conceptual view of particular layer is fundamental to fully understand any technology or system. Modern hardware infrastructure is complex and complexity is growing year on year.
Software programming has the same history. Who programs in assembler nowadays? Why we use object oriented programming more then 20 years? The answer is ... to avoid complexity and have control on system behavior. In software MVC model is often use and it stands for Model-View-Controller. Model is logical representation of something we want to run in software, View is simplified model presentation to end user and controller is engine behind the scene. The same concept apply to SDI (Software Defined Infrastructure) where SDN (Software Defined Network) is another example of the same story.
VMware did excellent job with infrastructure abstraction. Everything in VMware vSphere is object. Better to say managed object which has some properties and methods. So it is the model. vSphere Client or Web Client or vCLI or PowerCLI are different user interfaces into the system. So it is View. And who is Controller? Controller is vCenter because it orchestrates system behavior. vCenter controller includes prepackaged behavior (out-of-the-box) but it can be extended by custom scripts and orchestrated externally for example by vCenter Orchestrator. That's what I really love VMware vSphere. And it is from the begining architected to purely represent hardware infrastructure in software constructs.
Now back to Network Virtualization. In my opinion Network Overlay (for example VXLAN) is mandatory  component to abstract L2 from physical switches and have it in software. Particular Network overlay protocol must be implemented in "Network Hypervisor" which is software L2 switch. But "Network Hypervisor" has to implement also other protocols and components to be classified as "Network Virtualization" and not only as just another software vSwitch.
What Scott already mentioned in his post is that networking is not just L2 but also L3-7 network services so all network services must be available to speak about full "Network Virtualization". Am I correct Scott? And I feel the open question in this post ... who is the controller of "Network Virtualization"? :-)