Multiple network interfaces and ARP flux - Revision history

Kir: /* The Quick Fix */ remove CONFIG_CUSTOMIZED

2011-06-14T10:32:35Z

‎The Quick Fix: remove CONFIG_CUSTOMIZED

Kir: Protected "Multiple network interfaces and ARP flux" [edit=autoconfirmed:move=autoconfirmed]

2009-10-23T08:13:08Z

Protected "Multiple network interfaces and ARP flux" [edit=autoconfirmed:move=autoconfirmed]

Kir: Reverted edits by 59.92.22.225 (Talk) to last version by Kir

2009-10-23T08:12:22Z

Reverted edits by 59.92.22.225 (Talk) to last version by Kir

59.92.22.225: /* The Simple Case */

2009-10-23T01:02:37Z

‎The Simple Case

Kir: /* container Network Setup */ proper capitalization

2008-03-11T11:02:58Z

‎container Network Setup: proper capitalization

Botinki Kira: Robot: Automated text replacement (-VE +container)

2008-03-11T11:01:49Z

Robot: Automated text replacement (-VE +container)

Kir: /* The Simple Case */ ve->container

2008-03-11T10:37:42Z

‎The Simple Case: ve->container

Botinki Kira: Robot: Automated text replacement (-VEs +containers)

2008-03-11T09:47:47Z

Robot: Automated text replacement (-VEs +containers)

Botinki Kira: Robot: Automated text replacement (-VEID +CTID)

2008-03-11T09:42:36Z

Robot: Automated text replacement (-VEID +CTID)

Kir: /* The Quick Fix */ fix internal link

2008-03-05T12:27:39Z

‎The Quick Fix: fix internal link

@@ Line 269: / Line 269: @@
 This approach is also described in [[virtual Ethernet device]].
-In the container configuration file, /etc/vz/conf/$CTID.conf, add the line
+Create the file /etc/vz/vznet.conf or /etc/vz/vznetcfg.  Note that this will only work with a recent version of OpenVZ (vzctl-3.0.14) as the change was introduced in December, 2006.  The file name seems to have changed between the two listed here so some trial and error may be required.
 <pre>

@@ Line 1: / Line 1: @@
 This page discusses working with multiple network interfaces on the [[Hardware Node]] (HN), how this results in ARP Flux, and how to address this.
-Not sure if people use it, probably  because there is no driving factor now, but if google starts indexing that metadata, we'll see more videos have metadata injected in. ,
+==The Simple Case==
 ==A More Complex Case==

@@ Line 1: / Line 1: @@
 This page discusses working with multiple network interfaces on the [[Hardware Node]] (HN), how this results in ARP Flux, and how to address this.
-==The Simple Case==
+Not sure if people use it, probably  because there is no driving factor now, but if google starts indexing that metadata, we'll see more videos have metadata injected in. ,
 ==A More Complex Case==

@@ Line 169: / Line 169: @@
 Now that the HN is behaving as expected, let's add some containers and see what happens.
-====container Network Setup====
+==== 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.
+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.
 {| align="center" class="wikitable"

@@ Line 13: / Line 13: @@
 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 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.
+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 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===
@@ Line 169: / Line 169: @@
 Now that the HN is behaving as expected, let's add some containers and see what happens.
-====VE Network Setup====
+====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.
@@ Line 180: / Line 180: @@
 |}
-====Example Three - VE ARP Flux====
+====Example Three - 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 will be subject to ARP flux, drifting between all three link layer addresses over time.
+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 container will be subject to ARP flux, drifting between all three link layer addresses over time.
 <pre>
@@ Line 225: / Line 225: @@
 </pre>
-What this shows is that each VE IP address is associated with each HN interface.  Therefore each interface will respond to any ARP "who has" query.
+What this shows is that each container IP address is associated with each HN interface.  Therefore each interface will respond to any ARP "who has" query.
 ====The Cause====
@@ Line 265: / Line 265: @@
 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 startup.
+Fortunately there is a feature which will allow custom scripts to run during container startup.
 This approach is also described in [[virtual Ethernet device]].
-In the VE configuration file, /etc/vz/conf/$CTID.conf, add the line
+In the container configuration file, /etc/vz/conf/$CTID.conf, add the line
 <pre>

← Older revision	Revision as of 08:13, 23 October 2009
(No difference)

@@ Line 2: / Line 2: @@
 ==The Simple Case==
-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 (containers) also have IP addresses in the same subnet.  You don't care which interfaces your containers use.
+In the simple case you have multiple network interfaces on the HN, all with IP addresses in the same subnet.  Each of your containers also have IP addresses in the same subnet.  You don't care which interfaces your containers use.
 So, no action is required.  Everything just works.  Setup OpenVZ normally.

@@ Line 2: / Line 2: @@
 ==The Simple Case==
-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 (VEs) also have IP addresses in the same subnet.  You don't care which interfaces your VEs use.
+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 (containers) also have IP addresses in the same subnet.  You don't care which interfaces your containers use.
 So, no action is required.  Everything just works.  Setup OpenVZ normally.
@@ Line 11: / Line 11: @@
 ==A More Complex Case==
-Let's say you have three network interfaces on the HN, all with IP addresses on the same subnet.  Each of your VEs also have IP addresses on the same subnet.  But now you ''do'' care which interface your VEs use.
+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 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 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.
+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 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===
@@ Line 166: / Line 166: @@
 The desired affect has been achieved.  Only interface eth0 on the HN responds to the ARP message and the other interfaces are silent.
-===Adding some VEs===
+===Adding some containers===
-Now that the HN is behaving as expected, let's add some VEs and see what happens.
+Now that the HN is behaving as expected, let's add some containers and see what happens.
 ====VE Network Setup====
-The case we are addressing is when the VEs are on the same subnet as the HN.  So we create two new VEs and assign the addresses as follows.
+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.
 {| align="center" class="wikitable"
@@ Line 181: / Line 181: @@
 ====Example Three - VE ARP Flux====
-From the client system on you should be able to ping both VEs.  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.
+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 will be subject to ARP flux, drifting between all three link layer addresses over time.
 <pre>
@@ Line 258: / Line 258: @@
 What we see here is the result of vzarpipdetect, another function in vps_functions called by vps-net_add.  An ARP "who has" message is sent by each interface and answered by the other interfaces.
-What we want is to only add the IP addresses of our VEs to specific devices, not to all devices.  This will prevent the ARP flux problem for our VEs.
+What we want is to only add the IP addresses of our containers to specific devices, not to all devices.  This will prevent the ARP flux problem for our containers.
 ====The Quick Fix====
@@ Line 287: / Line 287: @@
 ==Testing Environment==
-All of the examples have been generated and tested using Debian Etch for the HN and Debian Stable for the VEs.  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.
+All of the examples have been generated and tested using Debian Etch for the HN and Debian Stable for the containers.  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.
 [[Category:HOWTO]]
 [[Category:Networking]]
 [[Category:Debian]]

@@ Line 173: / Line 173: @@
 {| align="center" class="wikitable"
-! VEID || IP
+! CTID || IP
 |-
 | 101 || 192.168.18.101
@@ Line 239: / Line 239: @@
 </pre>
-In addition, the following ARP messages are sent when VEID 101 is started.
+In addition, the following ARP messages are sent when CTID 101 is started.
 <pre>
@@ Line 269: / Line 269: @@
 This approach is also described in [[virtual Ethernet device]].
-In the VE configuration file, /etc/vz/conf/$VEID.conf, add the line
+In the VE configuration file, /etc/vz/conf/$CTID.conf, add the line
 <pre>