Category: overlay networks
Found this “gem” describing the differences between layer-2 and layer-3 on an unnamed $vendor web site.
Layer 2 is mainly concerned with the local delivery of data frames between network devices on the same network or local area network (LAN).
So far so good…
I published a blog post describing how complex the underlay supporting VMware NSX still has to be (because someone keeps pretending a network is just a thick yellow cable), and the tweet announcing it admittedly looked like a clickbait.
[Blog] Do We Need Complex Data Center Switches for VMware NSX Underlay
Martin Casado quickly replied NO (probably before reading the whole article), starting a whole barrage of overlay-focused neteng-versus-devs fun.
I spent a lot of time during this summer figuring out the details of NSX-T, resulting in significantly updated and expanded VMware NSX Technical Deep Dive material… but before going into those details let’s do a brief walk down the memory lane ;)
You might remember a startup called Nicira that was acquired by VMware in mid-2012… supposedly resulting in the ever-continuing spat between Cisco and VMware (and maybe even triggering the creation of Cisco ACI).
One of my readers sent me a series of questions regarding a new cloud deployment where the cloud implementers want to run VXLAN and EVPN on the hypervisor hosts:
I am currently working on a leaf-and-spine VXLAN+ EVPN PoC. At the same time, the systems team in my company is working on building a Cloudstack platform and are insisting on using VXLAN on the compute node even to the point of using BGP for inter-VXLAN traffic on the nodes.
Using VXLAN (or GRE) encap/decap on the hypervisor hosts is nothing new. That’s how NSX and many OpenStack implementations work.
In Episode 69 of Software Gone Wild we discussed ways of increasing visibility into VXLAN transport fabric. Another thing we badly need is visibility into the virtual edge behavior, and to help you get there Iwan Rahabok created a set of vRealize dashboards that include the virtual edge networking components. Hope you’ll find them useful.
Running Linux containers on a single host is relatively easy. Building private multi-tenant networks across multiple hosts immediately creates the usual networking mess.
After explaining the basics of Linux containers, Dinesh Dutt moved on to the basics of Docker networking, starting with an in-depth explanation of how a container communicates with other containers on the same host, with containers residing on other hosts, and the outside world.
Three years ago I was speaking with one of the attendees of my overlay virtual networking workshop @ Interop Las Vegas and he asked me how soon I thought the overlay virtual networking technologies would be accepted in the enterprise networks.
My response: “you might be surprised at the speed of the uptake.” Turns out, I was wrong (again). Today I’m surprised at the lack of that speed.
The featured webinar in May 2016 is the Overlay Virtual Networking webinar and in the featured videos (the ones marked with a star) you'll find introduction to overlay virtual networking and deep dive into flooding and MAC address learning in layer-2 overlay virtual networks.
A few months ago VMware launched NSX version 6.2, and I asked my friend Anthony Burke to tell us more about the new features. Not surprisingly, we quickly started talking about troubleshooting, routing problems, and finished with route-health-injection done with a Python script. The end result: Episode 50 of Software Gone Wild. Enjoy!
A year and a half ago, Docker networking couldn’t span multiple hosts and used NAT with port mapping to expose container-based services to the outside world.
Docker is the hottest Linux container solution these days. Want to know more about it? Matt Oswalt is running Introduction to Docker webinar in a few days.
In August 2014 a small startup decided to change all that. Docker bought them before they managed to get public, and the rest is history.
When I wrote a blog post explaining the difference between centralized control and centralized control plane, John Casey, CEO of CPLANE Networks wrote a comment saying “yeah, that’s exactly what we’re doing.”
You might remember all the fuss about various encapsulations used in overlay virtual networking… just because one wouldn’t be good enough (according to Andrew Lerner “we provide users with choice” actually means “we can’t decide which product to offer you”).
One of my readers wondered whether one still needs traditional firewalls in microsegmented environments like VMware NSX.
As always, it depends.
Network Address Translation (NAT) is one of those stateful services that’s almost impossible to scale out, because you have to distribute the state of the service (NAT mappings) across all potential ingress and egress points.
Midokura implemented distributed stateful services architecture in their Midonet product, but faced severe scalability challenges, which they claim to have solved with more intelligent state distribution.