Category: overlay networks

VMware NSX Update on Software Gone Wild

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!

see 3 comments

Docker Networking on Software Gone Wild

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.

read more see 2 comments

CPLANE Networks on Software Gone Wild

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 sayingyeah, that’s exactly what we’re doing.

It took us a while to get the stars aligned, but finally we managed to sit down and chat about what they’re doing, resulting in Episode 46 of Software Gone Wild.

add comment

Video: Scale-Out NAT

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.

read more see 5 comments

Hardware Gateways in Overlay Virtual Networks

Whenever I’m running an SDDC workshop or doing on-site SDN/SDDC-related consulting, the question of hardware gateways between overlay virtual networks and physical world inevitably pops up.

My usual answer: You have to understand (A) what type of gateway you need, (B) what performance you need and (C) what form factor will give you that performance. For more details, watch the Hardware Gateways video from Scaling Overlay Virtual Networks webinar

add comment

Availability Zones in Overlay Virtual Networks

Amazon Web Services was (AFAIK) one of the first products that introduced availability zones – islands of infrastructure that are isolated enough from each other to stop the propagation of failure or outage across their boundaries.

Not surprisingly, multiple availability zones shouldn’t rely on a central controller (as Amazon found out a few years back), and there are only few SDN controller vendors that are flexible enough to meet this requirement. For more details, watch the free Availability Zones video on my web site (part of Scaling Overlay Virtual Networking webinar).

add comment

Scaling Overlay Networks: Scale-Out Control Plane

A week or so ago I described why a properly implemented hypervisor-based overlay virtual networking data plane is not a scalability challenge; even though the performance might decrease slightly as the total number of forwarding entries grow, modern implementations easily saturate 10GE server uplinks.

Scalability of the central controller or orchestration system is a totally different can of worms. As I explained in the Scaling Overlay Networks, the only approach that avoids single failure domain and guarantees scalability is scale-out control plane architecture.

add comment

Scaling Overlay Networks: Distributed Data Plane

Thou Shalt Have No Chokepoints” is one of those simple scalability rules that are pretty hard to implement in real-life products. In the Distributed Data Plane part of Scaling Overlay Networks webinar I listed data plane components that can be easily distributed (layer-2 and layer-3 switching), some that are harder to implement but still doable (firewalling) and a few that are close to mission-impossible (NAT and load balancing).

add comment