2,253
edits
Changes
m
Robot: Automated text replacement (-VE +container)
Let's say you have three network interfaces on the HN, all with IP addresses on the same subnet. Each of your containers also have IP addresses on the same subnet. But now you ''do'' care which interface your containers use.
For example, you want some of your containers to always use <code>eth3</code>, and some to use <code>eth4</code>. But none of the VE container traffic should use <code>eth0</code>, which is reserved for use by the HN only. This makes sense if you have 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.
===Example Network Setup===
Now that the HN is behaving as expected, let's add some containers and see what happens.
====VE container Network Setup====
The case we are addressing is when the containers are on the same subnet as the HN. So we create two new containers and assign the addresses as follows.
|}
====Example Three - VE container ARP Flux====From the client system on you should be able to ping both containers. However, looking at the ARP traffic with tcpdump you'll see that once again the network address associated with each VE container will be subject to ARP flux, drifting between all three link layer addresses over time.
<pre>
</pre>
What this shows is that each VE container IP address is associated with each HN interface. Therefore each interface will respond to any ARP "who has" query.
====The Cause====
Manually editing the vzarp script is a quick fix, but not advised. Creating your own ''fork'' of OpenVZ is difficult to maintain and may have unintended side affects.
Fortunately there is a feature which will allow custom scripts to run during VE container startup.
This approach is also described in [[virtual Ethernet device]].
In the VE container configuration file, /etc/vz/conf/$CTID.conf, add the line
<pre>
