Understanding Eucalyptus EDGE Mode

Eucalyptus EDGE mode offers the most features of the EC2 Classic-compatible networking modes. It is designed to integrate into already extant (or straightforward to deploy) underlying network topologies. However, EDGE mode can impose constraints in certain environments.

In EDGE networking mode, the components responsible for implementing Eucalyptus VM networking artifacts are running at the edge of a Eucalyptus deployment: the Linux host machines acting as Node Controllers (NCs). On each NC host machine, a Eucalyptus stand-alone service, eucanetd, runs side-by-side with the NC service. The eucanetd service receives dynamically changing Eucalyptus networking views and is responsible for configuring the Linux networking subsystem to reflect the latest view.

EDGE networking mode integrates with your existing network infrastructure, allowing you to inform Eucalyptus, through configuration parameters for EDGE mode, about the existing network, which Eucalyptus then will consume when implementing the networking view.

EDGE networking mode integrates with two basic types of pre-existing network setups:

One flat IP network used to service Eucalyptus component systems, Eucalyptus VM public IPs (elastic IPs), and Eucalyptus VM private IPs.
Two networks, one for Eucalyptus components and Eucalyptus VM public IPs, and the other for Eucalyptus VM private IPs.

Important: EDGE networking mode integrates with networks that already exist. If the network, netmask, and router don't already exist, you must create them outside Eucalyptus before configuring EDGE mode.

EDGE Mode Requirements

Each NC host machine must have an interface configured with an IP on a VM public and a VM private network (which can be the same network).
- There must be unused IP addresses on the VM public network for Eucalyptus to assign VM elastic IPs.
- There must be unused IP addresses on the VM private network for Eucalyptus to assign VM private IPs.
There must be IP connectivity from each NC host machine (where eucanetd runs) and the CLC host machine, so that network path from instances to the metadata server (running on the CLC host machine) can be established.
There must be a functioning router in place for the private network. This router will be the default gateway for VM instances.
The private and public networks can be the same network, but they can also be separate networks.
The NC host machines need a bridge configured on the private network, with the bridge interface itself having been assigned an IP from the network.
If you're using a public network, the NC host machines need an interface on the public network as well (if the public and private networks are the same network, then the bridge needs an IP assigned on the network).
If you run multiple zones, each zone can use the same network as its private network, or they can use separate networks as private networks. If you use separate networks, you need to have a router in place that is configured to route traffic between the networks.
If you use private addressing only, the CLC host machine must have a route back to the VM private network.

EDGE Mode Limitations

Global network updates (such as security group rule updates, security group VM membership updates, and elastic IP updates) are applied through an "eventually consistent" mechanism, as opposed to an "atomic" mechanism. That is, there may be a brief period of time where one NC has the new state implemented but another NC has the previous state implemented.
Mappings between VM MAC addresses and private IPs are strictly enforced. This means that instances cannot communicate using addresses the cloud has not assigned to them.