Changes

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

For example, you want some of your VE's VEs 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 VE's VEs 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 VE'sVEs===Now that the HN is behaving as expected, let's add some VE's VEs and see what happens.

From the client system on you should be able to ping both VE'sVEs. 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 this shows is that each VE's IP address is associated with each HN's interface. Therefore each interface will respond to any ARP "who has" query.

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

All of the examples have been generated and tested using Debian Etch for the HN and Debian Stable for the VE'sVEs. 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.