Today’s public clouds provide only limited access to layer 2 and network configuration. This makes networking in the cloud very different from the datacenter, where there is normally full layer 2 access and full control over network configurations (switches, routers, etc.).
Challenge of Layer 2 Networking and Network Configuration in the Cloud
In the datacenter, there’s usually full access to layer 2. This means that a server, via its network card, can send (and receive) arbitrary frames to and from the network, without any filtering. Obviously, the cloud has a L2 network, and the Virtual Machines in the cloud do have virtual Ethernet adapters that connect to a virtual L2 network – but the frames that are sent and received are heavily filtered. All major clouds, including Amazon EC2, Amazon VPC, Google Compute Engine and Microsoft Azure, allow only unicast datagrams with IP payloads. Broadcast datagrams and non-IP payloads are not allowed (with very limited exceptions to make parts of the essential ARP and DHCP protocols work).
The problem is that some applications require more than just the “unicast with IP payload”. For example:
- Load balancing of several servers through a virtual IP (VIP). This may be done through various services and appliances such as F5’s Big IP. This requires the ability to send specific ARP requests to the broadcast address, requests which are filtered out in the cloud.
- Using various network appliances such as network optimization and security services in the application’s environment. Many of these appliances require advanced network definitions such as use of vlans, trunk ports, promiscuous port and mirror port.
- DHCP service within the application’s environment. A DHCP service makes use of broadcast (see below).
- Some older protocols, such as “wake on LAN” protocol or network booting (PXE), use non-IP ethertypes.
Broadcasting and multicasting
Some services require the ability to send out broadcast Ethernet frames. This is not possible in any of the clouds we mentioned above. For broadcast and multicast at the IP level, we need layer 2 broadcast. But we know that that IP broadcasting and multicasting in the cloud is not going to work in standard cloud deployment scenarios. People have tried to work around the lack of multicasting using various OS level tools. Some of these approaches may have valid use cases but such solutions add significant complexity, and push what is essentially a network responsibility back into the OS.
Ravello’s Approach to Layer 2 Networking and Network Configuration
Without full layer 2 access and flexible network configuration, the cloud network cannot mirror the datacenter network, and various applications will not be able to function properly. In order to accurately mirror environments for dev and test, full network support needs to be made available in the cloud.
To provide full layer 2 access, Ravello has developed a Software Defined Network (SDN) that runs on top of the cloud provider network. The SDN implements an overlay network that encapsulates the layer 2 Ethernet frames and sends them as regular unicast IP packets so that they don’t get blocked by the cloud provider. Virtual machines that run as part of a Ravello application have virtual network adapters that are connected to this overlay network, and not to the actual cloud provider network. The overlay network is 100% L2 clean, meaning that arbitrary L2 frames may be sent and received by all VMs inside a Ravello application. This results in the ability to accurately mirror complex environments running in the private data center on top of the public cloud without any change.
Check out our recent webinar – Advanced Enterprise Networking In AWS EC2 – A Hands On Guide and learn how you can re-create your data center networking in AWS EC2. Hadas Birin, Customer Success Engineering at Ravello Systems, demonstrated networking configuration of AWS EC2, including:
- Configuring multiple NICs and multiple private/public IPs per VM
- Preserving your existing static IPs and DNS hostnames on EC2
- Configuring multiple subnets, VLANs, IP broadcast and multicast on EC2
- Configuring virtual appliances, such as Fortinet firewalls and F5 load balancers
We discussed real-life examples and explained different high availability, performance and connectivity options and demonstrated how to take an existing VMware application with complex networking and create a clone with identical networking in the public cloud.
About Ravello Systems
Ravello is the industry’s leading nested virtualization and software-defined networking SaaS. It enables enterprises to create cloud-based development, test, UAT, integration and staging environments by automatically cloning their VMware-based applications in AWS. Ravello is built by the same team that developed the KVM hypervisor in Linux.