Category: VXLAN

From the moment Cisco and VMware announced VXLAN some networking engineers complained that they'd lose visibility into the end-to-end path. It took a long while, but finally the troubleshooting tools started appearing in VXLAN environment: NVO3 working group defined Fault Managemnet framework for overlay networks and Cisco implemented at least parts of it in recent Nexus OS releases.

You'll find more details in Software Gone Wild Episode 69 recorded with Lukas Krattiger in November 2016 (you can also watch VXLAN Technical Deep Dive webinar to learn more about VXLAN).

I got a long list of VXLAN-related questions from one of my subscribers. It started with an easy one:

Does Cisco ACI use VXLAN inside the fabric or is something else used instead of VXLAN?

ACI uses VXLAN but not in a way that would be (AFAIK) interoperable with any non-Cisco product. While they do use some proprietary tagging bits, the real challenge is the control plane.

One of my friends plans to replace existing FabricPath data center infrastructure, and asked whether it would make sense to stay with FabricPath (using the new Nexus 5600 switches) or migrate to ACI.

I proposed a third option: go with simple VXLAN encapsulation on Nexus 9000 switches. Here’s why:

Do you need VXLAN in your data center or could you continue using traditional bridging? Do layer-2 fabrics make sense or are they a dead end in the evolution of virtual networking?

I tried to provide a few high-level answers in the Introduction to VXLAN video which starts the VXLAN Technical Deep Dive webinar. The public version of the video is now available on ipSpace.net Free Content web site.

One of my readers stumbled upon blog post from 2011 explaining the potential implementations of VXLAN hardware gateways, and asked me if that information is still relevant.

I knew that I’d included tons of information in the Data Center Fabrics and VXLAN Deep Dive webinars, but couldn’t find anything on the web, so I decided to fix that in 2015.

Every now and then someone actually looks at the VXLAN packet format and eventually figures out that VXLAN encapsulation doesn’t provide any intrinsic security.

TL&DR Summary: That’s old news, the sky is not falling, and deploying VXLAN won’t make your network less secure than traditional VLAN- or MPLS-based networks.

Even though I wrote about the challenges of routing from VXLAN VNI to VLAN segment on a certain popular chipset a while ago, many engineers obviously still find the topic highly confusing (no surprise there, it is).

Maybe a video is worth a thousand words ;) – I published the part of recent VXLAN webinar where I described the issue in as many details as I could.

Last week I ran the second part of the updated (4-hour) VXLAN webinar. The raw videos are already online and cover these topics:

• VXLAN-related technologies, including encapsulation, IP multicast use, unicast VXLAN, and VXLAN-over-EVPN;
• VXLAN implementations, including Cisco Nexus 1000v, VMware vCNS, VMware NSX, Nuage VSP and Juniper Contrail;
• VXLAN gateways, including Arista, Brocade, Cisco and Juniper;
• Hardware VTEP integration with OVSDB and EVPN;
• VXLAN-based data center fabrics, including Cisco’s ACI.

I’m still getting questions about layer-2 data center interconnect; it seems this particular bad idea isn’t going away any time soon. In the face of that sad reality, let’s revisit what I wrote about layer-2 DCI over VXLAN.

VXLAN hasn’t changed much since the time I explained why it’s not the right technology for long-distance VLANs.

VXLAN is becoming de-facto encapsulation standard for overlay virtual networks (at least according to industry pundits and marketing gurus working for companies with VXLAN-based products) – even Juniper Contrail, which was traditionally a pure MPLS/VPN architecture uses it.

Not so fast – Contrail is using VXLAN packet format to carry MPLS labels between hypervisors and ToR switches.

Most recently launched data center switches use the Trident 2 chipset, and yet we know almost nothing about its capabilities and limitations. It might not work at linerate, it might have L3 lookup challenges when faced with L2 tunnels, there might be other unpleasant surprises… but we don’t know what they are, because you cannot get Broadcom’s documentation unless you work for a vendor who signed an NDA.

Interestingly, the best source of Trident 2 technical information I found so far happens to be the Cisco Live Nexus 9000 Series Switch Architecture presentation (BRKARC-2222). Here are a few tidbits I got from that presentation and Broadcom’s so-called datasheet.

A while ago I wrote “vMotion over VXLAN is stupid and unnecessary” in a comment to a blog post by Duncan Epping, assuming everyone knew the necessary background details. I was wrong (again).

A networking engineer was trying to persuade me of importance of hardware VXLAN VTEPs. We quickly agreed physical-to-virtual gateways are the primary use case, and he tried to illustrate his point by saying “Imagine you have 1000 servers in your data center and you manage to virtualize 80% of them. How will you connect them to the other 200?” to which I replied, “That doesn’t make any sense.” Here’s why.

Brook Reams sent me an interesting tidbit: Brocade is the first vendor that actually shipped a VXLAN VTEP controlled by a VMware NSX controller. It’s amazing to see how Brocade leapfrogged everyone else (they also added tons of other new functionality in NOS releases 4.0 and 4.1).

Gordon sent me a whole list of NSX gateway questions:

• Do you need a virtual gateway for each VXLAN segment or can a gateway be the entry/exit point across multiple VXLAN segments?
• Can you setup multiple gateways and specify which VXLAN segments use each gateway?
• Can you cluster gateways together (Active/Active) or do you setup them up as Active/Standby?

The answers obviously depend on whether you’re deploying NSX for multiple hypervisors or NSX for vSphere. Let’s start with the former.