The State of VXLAN in the Industry, and the Overlay Solution
It’s been over 6-month since I last wrote anything about VXLAN. So I thought of re-visiting it and see what are the latest developments in the world of “Overlay Networking.”
VXLAN technology has evolved a lot over the last couple of years. I have seen many vendors support VXLAN on their platform and also offer VXLAN-based SDN solutions. There are also competing technologies in the market, primarily NVGRE and STT. Perhaps there was a reason why IETF draft Geneva (Generic Network Virtualization Encapsulation) came alive. One standard to rule them all!
I see three kind of VXLAN solution available (or soon to be available) in the market:
- Multicast based VXLAN (IETF draft)
- Unicast-only VXLAN
- OVSDB VXLAN (this one can be put into the same category as 2nd, but for this blog I’ll kept it separate).
This is based on the IETF draft, which describes how VXLAN host discovery should work. As I covered in my previous post, each VTEP sends multicast packet for unknown, broadcast, and multicast host packets. While multicast may be common, many vendors thought that this would not be the best way to discover the end host. This also required a multicast-enabled network. This is where I saw lot of vendors started offering unicast-only VXLAN.
In a unicast-only VXLAN each VTEP is configured with remote VTEPs, and local VTEPs use the remote VTEP as destination for all Host communication. The VTEPs can be manually configured. A lot of vendors offer proprietary methods to configure them using a central controller. Most of the methods are proprietary, but recently a VTEP schema for OVSDB was made available for VXLAN so that a VTEP can be configured using OVSDB protocol.
This is actually a form of unicast-only VXLAN, but I see it as a separate method as OVSDB is an IETF specification. The VTEP schema is available publicly for anyone to use. In this version, each VTEP has an OVSDB client where the OVSDB server can program the database using the VTEP schema. The database contains the entry for the remote VTEP entry. VTEP can also request the OVSDB server for information for unknown destination.
We should see more mature VXLAN implementation, and perhaps a standardization of unicast-only VXLAN solution in future. The Geneva draft does address this at a very high level, but I still see a need to standardize the programming interface for VTEP. The OVSDB could be that protocol!
Ixia VXLAN Test solution