I wrote (and spoke) at length about layer-2 and layer-3 gateways between VLANs and overlay virtual networks, but I still get questions along the lines of “how will you connect legacy servers to the new cloud infrastructure that uses VXLAN?”

Gateway Types

You can connect an overlay virtual network and a physical subnet with:

• A network services device (firewall, load balancer …);
• Layer-3 gateway (router);
• Layer-2 gateway (bridge).

A network services device is the best choice if you have to connect a wholly virtualized application stack to the outside world, or if you’re connecting components that have to be isolated by a firewall or load balancer anyway.

Layer-3 gateway is the best option when you’re connecting physical and virtual subnets and don’t have to retain IP addresses of newly virtualized physical servers. Layer-2 gateway is the last-resort option used when you have to stretch the same IP subnet across physical and virtual domains.

Physical or virtual gateways?

It doesn’t make sense to waste our gray matter on this question in low-bandwidth environments (up to 1Gbps of traffic between the legacy servers and the overlay virtual networks). VM-based virtual gateways are good enough and extremely easy to deploy. You’re also avoiding any hardware lock-in – it’s pretty simple to replace the gateway solution if you don’t like it.

Some overlay virtual networking solutions (example: unicast VXLAN on Cisco Nexus 1000V don’t work with any existing hardware gateway anyway).

x86-based gateways can provide at least 10Gbps of throughput. If you need more than that across a single VLAN or tenant you should be looking at dedicated hardware. If you need more than 10Gbps aggregate throughput, but not more than a Gbps or two per tenant, you might be better served with a scale-out farm of x86-based gateways – after all, you might be able to reuse them if your needs change (and there’s no hardware lock-in).

How many gateways should one have?

Short answer: as few as possible.

Every gateway has to be managed and configured. Numerous gateways between physical and virtual worlds are a potential source of forwarding or routing loops, and some vendors limit the number of gateways you can have anyway.

In the ideal world, you’d have just two gateways (for redundancy purposes) connecting the legacy servers to the cloud infrastructure using overlay virtual networking; you might need more than that in high-bandwidth environments if you decide to use VM-based or x86-based gateways (see above).

The gateways would run in either active/backup configuration (example: Cisco VXLAN gateway, VM-based or x86-based VMware NSX gateways) or in MLAG-type deployment where two physical switches present themselves as a single VTEP (IP address) to the overlay virtual networking fabric (example: Arista VXLAN gateways, NSX VTEP on Brocade Logical Chassis, Cisco Nexus 9300).

More information

• VMware NSX Architecture webinar (free);
• Overlay virtual networking webinar
• Other cloud computing networking webinars on ipSpace.net

Buy the webinar subscription to get immediate access to all webinars.

I can also help you evaluate the suitability of overlay virtual networks in your environment or design your new cloud infrastructure, either online or on-site.