Changes

In the simple case you have multiple network interfaces on the HN, all with IP addresses in the same subnet. Each of your Virtual Environments (VEscontainers) also have IP addresses in the same subnet. You don't care which interfaces your VEs containers use.

Let's say you have three network interfaces on the HN, all with IP addresses on the same subnet. Each of your VEs containers also have IP addresses on the same subnet. But now you ''do'' care which interface your VEs containers use.

For example, you want some of your VEs containers to always use <code>eth3</code>, and some to use <code>eth4</code>. But none of the VE traffic should use <code>eth0</code>, which is reserved for use by the HN only. This makes sense if you have VEs containers that may generate or receive a lot of traffic and you don't want your remote administration of the server over <code>eth0</code> to degrade or get blocked because of this.

===Adding some VEscontainers===Now that the HN is behaving as expected, let's add some VEs containers and see what happens.

The case we are addressing is when the VEs containers are on the same subnet as the HN. So we create two new VEs containers and assign the addresses as follows.

From the client system on you should be able to ping both VEscontainers. However, looking at the ARP traffic with tcpdump you'll see that once again the network address associated with each VE will be subject to ARP flux, drifting between all three link layer addresses over time.

What we want is to only add the IP addresses of our VEs containers to specific devices, not to all devices. This will prevent the ARP flux problem for our VEscontainers.

All of the examples have been generated and tested using Debian Etch for the HN and Debian Stable for the VEscontainers. VMware Workstation was used to create the test networks. The client is the BackTrack live CD from Remote Exploit. If you have different results from other releases of Linux please edit this page.