<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.openvz.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Tony</id>
	<title>OpenVZ Virtuozzo Containers Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.openvz.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Tony"/>
	<link rel="alternate" type="text/html" href="https://wiki.openvz.org/Special:Contributions/Tony"/>
	<updated>2026-05-02T12:40:40Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.31.1</generator>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=14820</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=14820"/>
		<updated>2013-11-26T13:20:10Z</updated>

		<summary type="html">&lt;p&gt;Tony: Added GATEWAY to ifcfg-eth0 example.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the brN interface config scripts (ifcfg-br0 and ifcfg-br1).  Ie. the host IP configuration will now reside on the brN interfaces instead of the ethN interfaces.  The example also assumes IPv4 is configured statically, whereas IPv6 is auto-configured.&lt;br /&gt;
&lt;br /&gt;
==Configure host bridge interfaces==&lt;br /&gt;
&lt;br /&gt;
Steps 1 through 4 are done only once on the host.&lt;br /&gt;
&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr br0&lt;br /&gt;
        /usr/sbin/brctl addbr br1&lt;br /&gt;
&lt;br /&gt;
If the above commands do not work you may need to install the bridge-utils package.&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Also, record the hardware MAC addresses of the ethernet interfaces from the output of 'ifconfig'.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0&lt;br /&gt;
        /sbin/ifconfig eth1 &lt;br /&gt;
&lt;br /&gt;
Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding brN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-brN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-brN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-br0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
        MACADDR=mm:mm:mm:mm:mm:mm&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-br1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
        MACADDR=nn:nn:nn:nn:nn:nn&lt;br /&gt;
&lt;br /&gt;
Note that TYPE 'Bridge' is case-sensitive.  Otherwise, the bridge interfaces will not initialize correctly during boot.&lt;br /&gt;
&lt;br /&gt;
The bridge MACADDR should be hard-coded to match the corresponding hardware MAC address of the ethernet interface.  Otherwise the default behaviour is to use the lowest MAC address of all the interfaces in the bridge.  This is to prevent the bridge MAC and any auto-configured IPv6 address on the bridge interface from changing as VEs are created, started, or stopped.&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its brN interfaces.&lt;br /&gt;
&lt;br /&gt;
==Create the VE veth interfaces==&lt;br /&gt;
5.  Create the VE as you normally would, except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl create 100 --ostemplate name --hostname name&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, use vzctl to remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0 --save&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1 --save&lt;br /&gt;
&lt;br /&gt;
The above updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.  When the VE is started, the veth100.0 and veth100.1 devices will be automatically created on the host.&lt;br /&gt;
&lt;br /&gt;
==Bridge the host and VE==&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (brN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either start the VE,&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl start 100&lt;br /&gt;
&lt;br /&gt;
Or if it's already started then manually add each VE interface to its corresponding bridge using:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif br0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif br1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
==Configure the VE networking==&lt;br /&gt;
9.  Enter the VE from the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
In the container create the ifcfg network scripts for each interface eth0 and eth1.  The ifcfg-ethN files  should look like standard ifcfg network scripts for a non-VE host.&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.  A minimum ifcfg-eth0 file using a static IPv4 address would have the following entries:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=yyy.yyy.yyy.yyy&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        GATEWAY=zzz.zzz.zzz.zzz  &lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
==Additional VEs==&lt;br /&gt;
12.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
==Notes on IPv6 autoconfiguration==&lt;br /&gt;
If your CT0 is also performing routing duties, you might chance upon the problem that IPv6 stateless autoconfiguration using radvd is not working for the CT's. The description below is specific for a Debian (Lenny) CT0 and Debian (Squeeze) CT.&lt;br /&gt;
&lt;br /&gt;
First check if your CT is actually receiving any router advertisements (RA's). This can be done by installing radvd (apt-get install radvd) and running radvdump. Simply wait for the next round of RA's from radvd, or trigger it (by restarting radvd on CT0, for example). If you do not receive any RA's there is a more fundamental problem. The following only concerns the scenario where the CT receives RA's but does not configure the network interfaces accordingly. Do not forget to remove the radvd package after checking.&lt;br /&gt;
&lt;br /&gt;
Because CT0 is performing routing services, all or some values under /proc/sys/net/ipv6/conf/*/forwarding and under /proc/sys/net/ipv6/conf/*/mc_forwarding are set to 1. This appears to override the defaults for these values in the /proc filesystems for the CT's. Unless you explicitly disable forwarding in /etc/sysctl.conf, your CT will also use these values. This means that, to the IPv6 Neighbour Discovery Protocol (NDP) responsible for router advertisements and autoconfiguration, your CT is a router and therefore not allowed to use the RA's to configure the interfaces. To fix this, add or change the following lines to /etc/sysctl.conf '''''on the CT, not on CT0''''':&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv6.conf.all.forwarding=0&lt;br /&gt;
net.ipv6.conf.all.mc_forwarding=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may also want to explicitly disable IPv4 forwarding since the CT is not a router. To do this, also change the line:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv4.ip_forward=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now reload sysctl on the CT by executing&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
sysctl -p&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
and you will be good to go. The CT will now autoconfigure the network interfaces the next time it sees an RA.&lt;br /&gt;
&lt;br /&gt;
NOTE: Due to bug [http://bugzilla.openvz.org/show_bug.cgi?id=1723 1723] this setup might not work: Enabling the routing on CT0 can effectively kill all IPv6 connectivity for the CT, depending on the setup. (This bug is reported to be solved since 2011-06-07, so this shouldn't be an issue anymore.)&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[IPv6]]&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=IPv6&amp;diff=14778</id>
		<title>IPv6</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=IPv6&amp;diff=14778"/>
		<updated>2013-11-17T04:35:01Z</updated>

		<summary type="html">&lt;p&gt;Tony: /* ip6tables */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
IPv6 works best when veth devices are used to bridge VEs to their host.  An IPv6 compliant method of using veth interfaces for VEs can be found in the [[VEs and HNs in same subnets]] article.  &lt;br /&gt;
&lt;br /&gt;
venet devices are not fully IPv6 compliant, but still works if you statically assign IPv6 addresses.  They do not properly support MAC addresses and consequently link local addresses and can not play nice with neighbor discovery or router advertisements, router discovery, or auto-conf.  They also require additional modifications to the layer 3 forwarding behaviour of the host via sysctl.&lt;br /&gt;
&lt;br /&gt;
== Configure the Node ==&lt;br /&gt;
In order for IPv6 to work for containers you must have a fully functioning IPv6 interface on the host node.&lt;br /&gt;
&lt;br /&gt;
== CentOS Node Configuration for IPv6 ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;Add the below to the file /etc/sysconfig/network&lt;br /&gt;
&lt;br /&gt;
NETWORKING_IPV6=yes&lt;br /&gt;
IPV6FORWARDING=yes&lt;br /&gt;
IPV6_DEFAULTDEV=eth0&lt;br /&gt;
IPV6_DEFAULTGW=aaaa:bbbb:a01a::1&lt;br /&gt;
IPV6_AUTOCONF=no&lt;br /&gt;
&lt;br /&gt;
Add the below to the file /etc/sysconfig/network-scripts/ifcfg-ethX   X being your interface number&lt;br /&gt;
&lt;br /&gt;
IPV6INIT=yes&lt;br /&gt;
IPV6ADDR=aaaa:bbbb:cccc:0000:0100::1&lt;br /&gt;
&lt;br /&gt;
/etc/sysctl.conf also needs&lt;br /&gt;
&lt;br /&gt;
net.ipv6.conf.default.forwarding = 1&lt;br /&gt;
net.ipv6.conf.all.forwarding = 1&lt;br /&gt;
net.ipv6.conf.all.proxy_ndp = 1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== venet example ==&lt;br /&gt;
(tests done on CentOS kernel 2.6.18-194.26.1.el5.028stab079.2)&lt;br /&gt;
&lt;br /&gt;
=== Adding an IPv6 address to a container ===&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# vzctl set &amp;lt;id&amp;gt; --ipadd &amp;lt;ipv6_addr&amp;gt; --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In my tests, the container had to be restarted before it would respond to ICMP6 echo requests.&lt;br /&gt;
&lt;br /&gt;
In other tests on 2.6.32-042stab044.11 kernel, container failed to receive Neighbor Solicitation requests and replies, so I had to enable proxy_ndp:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# sysctl -w net.ipv6.conf.all.proxy_ndp=1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
(and later add appropriate line to /etc/sysctl.conf).&lt;br /&gt;
&lt;br /&gt;
=== Removing an IPv6 address from a container ===&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# vzctl set &amp;lt;id&amp;gt; --ipdel &amp;lt;ipv6_addr&amp;gt; --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Removal is effective immediately and the host stops replying to echo requests.&lt;br /&gt;
&lt;br /&gt;
==ip6tables==&lt;br /&gt;
If you will be using connection tracking in any container ip6tables firewall rules (i.e. '-m state --state'), you'll need to enable additional kernel modules in the host /etc/vz.conf.  Add 'ipt_state' to IPTABLES and 'nf_conntrack_ipv6' to IP6TABLES.  They should look something like this:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
IPTABLES=&amp;quot;ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state&amp;quot;&lt;br /&gt;
&lt;br /&gt;
IP6TABLES=&amp;quot;ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT nf_conntrack_ipv6&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;br /&gt;
&lt;br /&gt;
== External Links ==&lt;br /&gt;
* A user success story / howto on SixXS wiki [https://www.sixxs.net/wiki/User:JNN2-SIXXS/OpenVZ].&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=IPv6&amp;diff=14777</id>
		<title>IPv6</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=IPv6&amp;diff=14777"/>
		<updated>2013-11-17T04:29:01Z</updated>

		<summary type="html">&lt;p&gt;Tony: Added connection state kernel modules needed for ip6tables.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
IPv6 works best when veth devices are used to bridge VEs to their host.  An IPv6 compliant method of using veth interfaces for VEs can be found in the [[VEs and HNs in same subnets]] article.  &lt;br /&gt;
&lt;br /&gt;
venet devices are not fully IPv6 compliant, but still works if you statically assign IPv6 addresses.  They do not properly support MAC addresses and consequently link local addresses and can not play nice with neighbor discovery or router advertisements, router discovery, or auto-conf.  They also require additional modifications to the layer 3 forwarding behaviour of the host via sysctl.&lt;br /&gt;
&lt;br /&gt;
== Configure the Node ==&lt;br /&gt;
In order for IPv6 to work for containers you must have a fully functioning IPv6 interface on the host node.&lt;br /&gt;
&lt;br /&gt;
== CentOS Node Configuration for IPv6 ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;Add the below to the file /etc/sysconfig/network&lt;br /&gt;
&lt;br /&gt;
NETWORKING_IPV6=yes&lt;br /&gt;
IPV6FORWARDING=yes&lt;br /&gt;
IPV6_DEFAULTDEV=eth0&lt;br /&gt;
IPV6_DEFAULTGW=aaaa:bbbb:a01a::1&lt;br /&gt;
IPV6_AUTOCONF=no&lt;br /&gt;
&lt;br /&gt;
Add the below to the file /etc/sysconfig/network-scripts/ifcfg-ethX   X being your interface number&lt;br /&gt;
&lt;br /&gt;
IPV6INIT=yes&lt;br /&gt;
IPV6ADDR=aaaa:bbbb:cccc:0000:0100::1&lt;br /&gt;
&lt;br /&gt;
/etc/sysctl.conf also needs&lt;br /&gt;
&lt;br /&gt;
net.ipv6.conf.default.forwarding = 1&lt;br /&gt;
net.ipv6.conf.all.forwarding = 1&lt;br /&gt;
net.ipv6.conf.all.proxy_ndp = 1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== venet example ==&lt;br /&gt;
(tests done on CentOS kernel 2.6.18-194.26.1.el5.028stab079.2)&lt;br /&gt;
&lt;br /&gt;
=== Adding an IPv6 address to a container ===&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# vzctl set &amp;lt;id&amp;gt; --ipadd &amp;lt;ipv6_addr&amp;gt; --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
In my tests, the container had to be restarted before it would respond to ICMP6 echo requests.&lt;br /&gt;
&lt;br /&gt;
In other tests on 2.6.32-042stab044.11 kernel, container failed to receive Neighbor Solicitation requests and replies, so I had to enable proxy_ndp:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# sysctl -w net.ipv6.conf.all.proxy_ndp=1&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
(and later add appropriate line to /etc/sysctl.conf).&lt;br /&gt;
&lt;br /&gt;
=== Removing an IPv6 address from a container ===&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
# vzctl set &amp;lt;id&amp;gt; --ipdel &amp;lt;ipv6_addr&amp;gt; --save&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Removal is effective immediately and the host stops replying to echo requests.&lt;br /&gt;
&lt;br /&gt;
==ip6tables==&lt;br /&gt;
If you will be using connection tracking in ip6tables (i.e. '-m state --state'), you'll need to enable extra kernel modules in the host /etc/vz.conf.  Add 'ipt_state' to IPTABLES and 'nf_conntrack_ipv6' to IP6TABLES.  They should look something like this:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
IPTABLES=&amp;quot;ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state&amp;quot;&lt;br /&gt;
&lt;br /&gt;
IP6TABLES=&amp;quot;ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT nf_conntrack_ipv6&amp;quot;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;br /&gt;
&lt;br /&gt;
== External Links ==&lt;br /&gt;
* A user success story / howto on SixXS wiki [https://www.sixxs.net/wiki/User:JNN2-SIXXS/OpenVZ].&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12673</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12673"/>
		<updated>2012-07-15T12:01:14Z</updated>

		<summary type="html">&lt;p&gt;Tony: /* Configure host bridge interfaces */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the brN interface config scripts (ifcfg-br0 and ifcfg-br1).  Ie. the host IP configuration will now reside on the brN interfaces instead of the ethN interfaces.  The example also assumes IPv4 is configured statically, whereas IPv6 is auto-configured.&lt;br /&gt;
&lt;br /&gt;
==Configure host bridge interfaces==&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr br0&lt;br /&gt;
        /usr/sbin/brctl addbr br1&lt;br /&gt;
&lt;br /&gt;
If the above commands do not work you may need to install the bridge-utils package.&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding brN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-brN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-brN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-br0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-br1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Note that TYPE 'Bridge' is case-sensitive.  Otherwise, the bridge interfaces will not initialize correctly during boot.&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its brN interfaces.&lt;br /&gt;
&lt;br /&gt;
==Create the VE veth interfaces==&lt;br /&gt;
5.  Create the VE as you normally would, except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl create 100 --ostemplate name --hostname name&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, use vzctl to remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0 --save&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1 --save&lt;br /&gt;
&lt;br /&gt;
The above updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.  When the VE is started, the veth100.0 and veth100.1 devices will be automatically created on the host.&lt;br /&gt;
&lt;br /&gt;
==Bridge the host and VE==&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (brN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either start the VE,&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl start 100&lt;br /&gt;
&lt;br /&gt;
Or if it's already started then manually add each VE interface to its corresponding bridge using:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif br0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif br1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
==Configure the VE networking==&lt;br /&gt;
9.  Enter the VE from the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
In the container create the ifcfg network scripts for each interface eth0 and eth1.  The ifcfg-ethN files  should look like standard ifcfg network scripts for a non-VE host.&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.  A minimum ifcfg-eth0 file using a static IPv4 address would have the following entries:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=yyy.yyy.yyy.yyy&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
==Additional VEs==&lt;br /&gt;
12.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
==Notes on IPv6 autoconfiguration==&lt;br /&gt;
If your CT0 is also performing routing duties, you might chance upon the problem that IPv6 stateless autoconfiguration using radvd is not working for the CT's. The description below is specific for a Debian (Lenny) CT0 and Debian (Squeeze) CT.&lt;br /&gt;
&lt;br /&gt;
First check if your CT is actually receiving any router advertisements (RA's). This can be done by installing radvd (apt-get install radvd) and running radvdump. Simply wait for the next round of RA's from radvd, or trigger it (by restarting radvd on CT0, for example). If you do not receive any RA's there is a more fundamental problem. The following only concerns the scenario where the CT receives RA's but does not configure the network interfaces accordingly. Do not forget to remove the radvd package after checking.&lt;br /&gt;
&lt;br /&gt;
Because CT0 is performing routing services, all or some values under /proc/sys/net/ipv6/conf/*/forwarding and under /proc/sys/net/ipv6/conf/*/mc_forwarding are set to 1. This appears to override the defaults for these values in the /proc filesystems for the CT's. Unless you explicitly disable forwarding in /etc/sysctl.conf, your CT will also use these values. This means that, to the IPv6 Neighbour Discovery Protocol (NDP) responsible for router advertisements and autoconfiguration, your CT is a router and therefore not allowed to use the RA's to configure the interfaces. To fix this, add or change the following lines to /etc/sysctl.conf '''''on the CT, not on CT0''''':&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv6.conf.all.forwarding=0&lt;br /&gt;
net.ipv6.conf.all.mc_forwarding=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may also want to explicitly disable IPv4 forwarding since the CT is not a router. To do this, also change the line:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv4.ip_forward=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now reload sysctl on the CT by executing&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
sysctl -p&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
and you will be good to go. The CT will now autoconfigure the network interfaces the next time it sees an RA.&lt;br /&gt;
&lt;br /&gt;
NOTE: Due to bug [http://bugzilla.openvz.org/show_bug.cgi?id=1723 1723] this setup might not work: Enabling the routing on CT0 can effectively kill all IPv6 connectivity for the CT, depending on the setup. (This bug is reported to be solved since 2011-06-07, so this shouldn't be an issue anymore.)&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[IPv6]]&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12672</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12672"/>
		<updated>2012-07-15T11:59:18Z</updated>

		<summary type="html">&lt;p&gt;Tony: Renaming of openvz-centric bridge interface names to generic interface names.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the brN interface config scripts (ifcfg-br0 and ifcfg-br1).  Ie. the host IP configuration will now reside on the brN interfaces instead of the ethN interfaces.  The example also assumes IPv4 is configured statically, whereas IPv6 is auto-configured.&lt;br /&gt;
&lt;br /&gt;
==Configure host bridge interfaces==&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr br0&lt;br /&gt;
        /usr/sbin/brctl addbr br1&lt;br /&gt;
&lt;br /&gt;
If the above commands do not work you may need to install the bridge-utils package.&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding brN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-brN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-brN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-br0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-br1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Note that TYPE 'Bridge' is case-sensitive.&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its brN interfaces.&lt;br /&gt;
&lt;br /&gt;
==Create the VE veth interfaces==&lt;br /&gt;
5.  Create the VE as you normally would, except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl create 100 --ostemplate name --hostname name&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, use vzctl to remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0 --save&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1 --save&lt;br /&gt;
&lt;br /&gt;
The above updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.  When the VE is started, the veth100.0 and veth100.1 devices will be automatically created on the host.&lt;br /&gt;
&lt;br /&gt;
==Bridge the host and VE==&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (brN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either start the VE,&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl start 100&lt;br /&gt;
&lt;br /&gt;
Or if it's already started then manually add each VE interface to its corresponding bridge using:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif br0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif br1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
==Configure the VE networking==&lt;br /&gt;
9.  Enter the VE from the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
In the container create the ifcfg network scripts for each interface eth0 and eth1.  The ifcfg-ethN files  should look like standard ifcfg network scripts for a non-VE host.&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.  A minimum ifcfg-eth0 file using a static IPv4 address would have the following entries:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=yyy.yyy.yyy.yyy&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
==Additional VEs==&lt;br /&gt;
12.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
==Notes on IPv6 autoconfiguration==&lt;br /&gt;
If your CT0 is also performing routing duties, you might chance upon the problem that IPv6 stateless autoconfiguration using radvd is not working for the CT's. The description below is specific for a Debian (Lenny) CT0 and Debian (Squeeze) CT.&lt;br /&gt;
&lt;br /&gt;
First check if your CT is actually receiving any router advertisements (RA's). This can be done by installing radvd (apt-get install radvd) and running radvdump. Simply wait for the next round of RA's from radvd, or trigger it (by restarting radvd on CT0, for example). If you do not receive any RA's there is a more fundamental problem. The following only concerns the scenario where the CT receives RA's but does not configure the network interfaces accordingly. Do not forget to remove the radvd package after checking.&lt;br /&gt;
&lt;br /&gt;
Because CT0 is performing routing services, all or some values under /proc/sys/net/ipv6/conf/*/forwarding and under /proc/sys/net/ipv6/conf/*/mc_forwarding are set to 1. This appears to override the defaults for these values in the /proc filesystems for the CT's. Unless you explicitly disable forwarding in /etc/sysctl.conf, your CT will also use these values. This means that, to the IPv6 Neighbour Discovery Protocol (NDP) responsible for router advertisements and autoconfiguration, your CT is a router and therefore not allowed to use the RA's to configure the interfaces. To fix this, add or change the following lines to /etc/sysctl.conf '''''on the CT, not on CT0''''':&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv6.conf.all.forwarding=0&lt;br /&gt;
net.ipv6.conf.all.mc_forwarding=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may also want to explicitly disable IPv4 forwarding since the CT is not a router. To do this, also change the line:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv4.ip_forward=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now reload sysctl on the CT by executing&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
sysctl -p&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
and you will be good to go. The CT will now autoconfigure the network interfaces the next time it sees an RA.&lt;br /&gt;
&lt;br /&gt;
NOTE: Due to bug [http://bugzilla.openvz.org/show_bug.cgi?id=1723 1723] this setup might not work: Enabling the routing on CT0 can effectively kill all IPv6 connectivity for the CT, depending on the setup. (This bug is reported to be solved since 2011-06-07, so this shouldn't be an issue anymore.)&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[IPv6]]&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12671</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12671"/>
		<updated>2012-07-15T11:57:51Z</updated>

		<summary type="html">&lt;p&gt;Tony: Renamed openvz-centric bridge interface names to more generic names.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the brN interface config scripts (ifcfg-br0 and ifcfg-br1).  Ie. the host IP configuration will now reside on the brN interfaces instead of the ethN interfaces.  The example also assumes IPv4 is configured statically, whereas IPv6 is auto-configured.&lt;br /&gt;
&lt;br /&gt;
==Configure host bridge interfaces==&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr br0&lt;br /&gt;
        /usr/sbin/brctl addbr br1&lt;br /&gt;
&lt;br /&gt;
If the above commands do not work you may need to install the bridge-utils package.&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding brN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-brN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-brN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-br0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-br1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Note that TYPE 'Bridge' is case-sensitive.&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its brN interfaces.&lt;br /&gt;
&lt;br /&gt;
==Create the VE veth interfaces==&lt;br /&gt;
5.  Create the VE as you normally would, except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl create 100 --ostemplate name --hostname name&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, use vzctl to remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0 --save&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1 --save&lt;br /&gt;
&lt;br /&gt;
The above updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.  When the VE is started, the veth100.0 and veth100.1 devices will be automatically created on the host.&lt;br /&gt;
&lt;br /&gt;
==Bridge the host and VE==&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either start the VE,&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl start 100&lt;br /&gt;
&lt;br /&gt;
Or if it's already started then manually add each VE interface to its corresponding bridge using:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif br0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif br1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
==Configure the VE networking==&lt;br /&gt;
9.  Enter the VE from the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
In the container create the ifcfg network scripts for each interface eth0 and eth1.  The ifcfg-ethN files  should look like standard ifcfg network scripts for a non-VE host.&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.  A minimum ifcfg-eth0 file using a static IPv4 address would have the following entries:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=yyy.yyy.yyy.yyy&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
==Additional VEs==&lt;br /&gt;
12.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
==Notes on IPv6 autoconfiguration==&lt;br /&gt;
If your CT0 is also performing routing duties, you might chance upon the problem that IPv6 stateless autoconfiguration using radvd is not working for the CT's. The description below is specific for a Debian (Lenny) CT0 and Debian (Squeeze) CT.&lt;br /&gt;
&lt;br /&gt;
First check if your CT is actually receiving any router advertisements (RA's). This can be done by installing radvd (apt-get install radvd) and running radvdump. Simply wait for the next round of RA's from radvd, or trigger it (by restarting radvd on CT0, for example). If you do not receive any RA's there is a more fundamental problem. The following only concerns the scenario where the CT receives RA's but does not configure the network interfaces accordingly. Do not forget to remove the radvd package after checking.&lt;br /&gt;
&lt;br /&gt;
Because CT0 is performing routing services, all or some values under /proc/sys/net/ipv6/conf/*/forwarding and under /proc/sys/net/ipv6/conf/*/mc_forwarding are set to 1. This appears to override the defaults for these values in the /proc filesystems for the CT's. Unless you explicitly disable forwarding in /etc/sysctl.conf, your CT will also use these values. This means that, to the IPv6 Neighbour Discovery Protocol (NDP) responsible for router advertisements and autoconfiguration, your CT is a router and therefore not allowed to use the RA's to configure the interfaces. To fix this, add or change the following lines to /etc/sysctl.conf '''''on the CT, not on CT0''''':&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv6.conf.all.forwarding=0&lt;br /&gt;
net.ipv6.conf.all.mc_forwarding=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may also want to explicitly disable IPv4 forwarding since the CT is not a router. To do this, also change the line:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv4.ip_forward=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now reload sysctl on the CT by executing&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
sysctl -p&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
and you will be good to go. The CT will now autoconfigure the network interfaces the next time it sees an RA.&lt;br /&gt;
&lt;br /&gt;
NOTE: Due to bug [http://bugzilla.openvz.org/show_bug.cgi?id=1723 1723] this setup might not work: Enabling the routing on CT0 can effectively kill all IPv6 connectivity for the CT, depending on the setup. (This bug is reported to be solved since 2011-06-07, so this shouldn't be an issue anymore.)&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[IPv6]]&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12670</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=12670"/>
		<updated>2012-07-15T11:56:09Z</updated>

		<summary type="html">&lt;p&gt;Tony: Added note about case-sensitive Bridge TYPE and renamed openvz-centric bridge interface names to more generic names.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the vzbrN interface config scripts (ifcfg-vzbr0 and ifcfg-vzbr1).  Ie. the host IP configuration will now reside on the vzbrN interfaces instead of the ethN interfaces.  The example also assumes IPv4 is configured statically, whereas IPv6 is auto-configured.&lt;br /&gt;
&lt;br /&gt;
==Configure host bridge interfaces==&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr br0&lt;br /&gt;
        /usr/sbin/brctl addbr br1&lt;br /&gt;
&lt;br /&gt;
If the above commands do not work you may need to install the bridge-utils package.&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding brN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=br1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-brN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-brN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-br0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-br1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=br1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=Bridge&lt;br /&gt;
&lt;br /&gt;
Note that TYPE 'Bridge' is case-sensitive.&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its brN interfaces.&lt;br /&gt;
&lt;br /&gt;
==Create the VE veth interfaces==&lt;br /&gt;
5.  Create the VE as you normally would, except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl create 100 --ostemplate name --hostname name&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, use vzctl to remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0 --save&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1 --save&lt;br /&gt;
&lt;br /&gt;
The above updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.  When the VE is started, the veth100.0 and veth100.1 devices will be automatically created on the host.&lt;br /&gt;
&lt;br /&gt;
==Bridge the host and VE==&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=no&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either start the VE,&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl start 100&lt;br /&gt;
&lt;br /&gt;
Or if it's already started then manually add each VE interface to its corresponding bridge using:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif vzbr0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif vzbr1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
==Configure the VE networking==&lt;br /&gt;
9.  Enter the VE from the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
In the container create the ifcfg network scripts for each interface eth0 and eth1.  The ifcfg-ethN files  should look like standard ifcfg network scripts for a non-VE host.&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.  A minimum ifcfg-eth0 file using a static IPv4 address would have the following entries:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=yyy.yyy.yyy.yyy&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
==Additional VEs==&lt;br /&gt;
12.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
==Notes on IPv6 autoconfiguration==&lt;br /&gt;
If your CT0 is also performing routing duties, you might chance upon the problem that IPv6 stateless autoconfiguration using radvd is not working for the CT's. The description below is specific for a Debian (Lenny) CT0 and Debian (Squeeze) CT.&lt;br /&gt;
&lt;br /&gt;
First check if your CT is actually receiving any router advertisements (RA's). This can be done by installing radvd (apt-get install radvd) and running radvdump. Simply wait for the next round of RA's from radvd, or trigger it (by restarting radvd on CT0, for example). If you do not receive any RA's there is a more fundamental problem. The following only concerns the scenario where the CT receives RA's but does not configure the network interfaces accordingly. Do not forget to remove the radvd package after checking.&lt;br /&gt;
&lt;br /&gt;
Because CT0 is performing routing services, all or some values under /proc/sys/net/ipv6/conf/*/forwarding and under /proc/sys/net/ipv6/conf/*/mc_forwarding are set to 1. This appears to override the defaults for these values in the /proc filesystems for the CT's. Unless you explicitly disable forwarding in /etc/sysctl.conf, your CT will also use these values. This means that, to the IPv6 Neighbour Discovery Protocol (NDP) responsible for router advertisements and autoconfiguration, your CT is a router and therefore not allowed to use the RA's to configure the interfaces. To fix this, add or change the following lines to /etc/sysctl.conf '''''on the CT, not on CT0''''':&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv6.conf.all.forwarding=0&lt;br /&gt;
net.ipv6.conf.all.mc_forwarding=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You may also want to explicitly disable IPv4 forwarding since the CT is not a router. To do this, also change the line:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
net.ipv4.ip_forward=0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Now reload sysctl on the CT by executing&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
sysctl -p&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
and you will be good to go. The CT will now autoconfigure the network interfaces the next time it sees an RA.&lt;br /&gt;
&lt;br /&gt;
NOTE: Due to bug [http://bugzilla.openvz.org/show_bug.cgi?id=1723 1723] this setup might not work: Enabling the routing on CT0 can effectively kill all IPv6 connectivity for the CT, depending on the setup. (This bug is reported to be solved since 2011-06-07, so this shouldn't be an issue anymore.)&lt;br /&gt;
&lt;br /&gt;
==See also==&lt;br /&gt;
* [[IPv6]]&lt;br /&gt;
* [[Virtual Ethernet device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=IPv6&amp;diff=8102</id>
		<title>IPv6</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=IPv6&amp;diff=8102"/>
		<updated>2010-01-25T01:52:14Z</updated>

		<summary type="html">&lt;p&gt;Tony: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
IPv6 works best when veth devices are used to bridge VEs to their host.  A Networking HOWTO illustrating an IPv6 compliant method of using veth interfaces for VEs can be found in the [[VEs and HNs in same subnets]] article.  &lt;br /&gt;
&lt;br /&gt;
venet devices are not fully IPv6 compliant.  They do not properly support MAC addresses and consequently link local addresses and can not play nice with neighbor discovery or router advertisements, router discovery, or auto-conf.  They also require additional modifications to the layer 3 forwarding behaviour of the host via sysctl.&lt;br /&gt;
&lt;br /&gt;
veth devices do require iptables and ip6tables exceptions on the host for each VE address.&lt;br /&gt;
&lt;br /&gt;
= See also =&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=IPv6&amp;diff=8101</id>
		<title>IPv6</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=IPv6&amp;diff=8101"/>
		<updated>2010-01-25T01:39:55Z</updated>

		<summary type="html">&lt;p&gt;Tony: New page: Category:HOWTO Category:Networking IPv6 works best when veth devices are used to bridge VEs to their host.  A Networking HOWTO illustrating an IPv6 compliant method of using veth i...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
IPv6 works best when veth devices are used to bridge VEs to their host.  A Networking HOWTO illustrating an IPv6 compliant method of using veth interfaces for VEs can be found in the [[VEs and HNs in same subnets]] article.  &lt;br /&gt;
&lt;br /&gt;
venet devices are not fully IPv6 compliant.  They do not properly support MAC addresses and consequently link local addresses and can not play nice with neighbor discovery or router advertisements, router discovery, or auto-conf.  &lt;br /&gt;
&lt;br /&gt;
= See also =&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8100</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8100"/>
		<updated>2010-01-25T01:17:14Z</updated>

		<summary type="html">&lt;p&gt;Tony: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the vzbrN interface config scripts (ifcfg-vzbr0 and ifcfg-vzbr1).  Ie. the host IP configuration will now reside on the vzbrN interfaces instead of the ethN interfaces.&lt;br /&gt;
&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr0&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr1&lt;br /&gt;
&lt;br /&gt;
If the above commands do not work you may need to install the bridge-utils package.&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding vzbrN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-vzbrN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-vzbrN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-vzbr0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-vzbr1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its vzbrN interfaces.&lt;br /&gt;
&lt;br /&gt;
5.  Create the VE as you normally would except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1&lt;br /&gt;
&lt;br /&gt;
The above creates corresponding veth100.0 and veth100.1 devices on the host and updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.&lt;br /&gt;
&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either do another 'service network restart' on the host, or manually add each VE interface to its corresponding bridge by running:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif vzbr0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif vzbr1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
9.  In the container create the ifcfg network scripts for each interface eth0 and eth1.  The scripts should look like standard ifcfg network scripts for a host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
After entering the VE:&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Add FORWARD ACCEPT statements to the host iptables and ip6tables for each VE IPv4 and IPv6 address.  You do NOT need to enable any special network forwarding via sysctl.&lt;br /&gt;
&lt;br /&gt;
iptables:&lt;br /&gt;
        -A FORWARD -s xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
ip6tables:&lt;br /&gt;
        -A FORWARD -s xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
Then restart both iptables and ip6tables on the host:&lt;br /&gt;
&lt;br /&gt;
        service iptables restart&lt;br /&gt;
        service ip6tables restart&lt;br /&gt;
&lt;br /&gt;
12.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
13.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
* [[Virtual network device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8099</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8099"/>
		<updated>2010-01-25T01:07:55Z</updated>

		<summary type="html">&lt;p&gt;Tony: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Category:HOWTO]]&lt;br /&gt;
[[Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the vzbrN interface config scripts (ifcfg-vzbr0 and ifcfg-vzbr1).  Ie. the host IP configuration will now reside on the vzbrN interfaces instead of the ethN interfaces.&lt;br /&gt;
&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr0&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr1&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding vzbrN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-vzbrN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-vzbrN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-vzbr0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-vzbr1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its vzbrN interfaces.&lt;br /&gt;
&lt;br /&gt;
5.  Create the VE as you normally would except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1&lt;br /&gt;
&lt;br /&gt;
The above creates corresponding veth100.0 and veth100.1 devices on the host and updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.&lt;br /&gt;
&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either do another 'service network restart' on the host, or manually add each VE interface to its corresponding bridge by running:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif vzbr0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif vzbr1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
9.  In the container create the ifcfg network scripts for each interface eth0 and eth1.  The scripts should look like standard ifcfg network scripts for a host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
After entering the VE:&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Add FORWARD ACCEPT statements to the host iptables and ip6tables for each VE IPv4 and IPv6 address.  You do NOT need to enable any special network forwarding via sysctl.&lt;br /&gt;
&lt;br /&gt;
iptables:&lt;br /&gt;
        -A FORWARD -s xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
ip6tables:&lt;br /&gt;
        -A FORWARD -s xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
Then restart both iptables and ip6tables on the host:&lt;br /&gt;
&lt;br /&gt;
        service iptables restart&lt;br /&gt;
        service ip6tables restart&lt;br /&gt;
&lt;br /&gt;
12.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
13.  For each additional VE, start at step #5.&lt;br /&gt;
&lt;br /&gt;
== See also ==&lt;br /&gt;
* [[Virtual network device]]&lt;br /&gt;
* [[Differences between venet and veth]]&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8098</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8098"/>
		<updated>2010-01-25T00:59:25Z</updated>

		<summary type="html">&lt;p&gt;Tony: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[{Category:Networking]]&lt;br /&gt;
This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the vzbrN interface config scripts (ifcfg-vzbr0 and ifcfg-vzbr1).  Ie. the host IP configuration will now reside on the vzbrN interfaces instead of the ethN interfaces.&lt;br /&gt;
&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr0&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr1&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding vzbrN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-vzbrN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-vzbrN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-vzbr0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-vzbr1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its vzbrN interfaces.&lt;br /&gt;
&lt;br /&gt;
5.  Create the VE as you normally would except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1&lt;br /&gt;
&lt;br /&gt;
The above creates corresponding veth100.0 and veth100.1 devices on the host and updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.&lt;br /&gt;
&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either do another 'service network restart' on the host, or manually add each VE interface to its corresponding bridge by running:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif vzbr0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif vzbr1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
9.  In the container create the ifcfg network scripts for each interface eth0 and eth1.  The scripts should look like standard ifcfg network scripts for a host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
After entering the VE:&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Add FORWARD ACCEPT statements to the host iptables and ip6tables for each VE IPv4 and IPv6 address.  You do NOT need to enable any special network forwarding via sysctl.&lt;br /&gt;
&lt;br /&gt;
iptables:&lt;br /&gt;
        -A FORWARD -s xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
ip6tables:&lt;br /&gt;
        -A FORWARD -s xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
Then restart both iptables and ip6tables on the host:&lt;br /&gt;
&lt;br /&gt;
        service iptables restart&lt;br /&gt;
        service ip6tables restart&lt;br /&gt;
&lt;br /&gt;
12.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
13.  For each additional VE, start at step #5.&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8097</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8097"/>
		<updated>2010-01-25T00:53:04Z</updated>

		<summary type="html">&lt;p&gt;Tony: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of their own in the same subnets or VLAN as the host.  This method makes use of the Virtual Ethernet device and bridges between the host and its containers.  This technique has the advantage of allowing IPv6 network configurations to work on both VEs and hosts as they normally would.  In particular, both hosts and VEs can use IPv6 autoconfiguration.  The network configuration of a VE can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are setting up the network configuration for VE 100.  The host IP configuration is moved out of the ethN interface configs and into the vzbrN interface config scripts (ifcfg-vzbr0 and ifcfg-vzbr1).  Ie. the host IP configuration will now reside on the vzbrN interfaces instead of the ethN interfaces.&lt;br /&gt;
&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr0&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr1&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN files.  Then, modify the ifcfg-ethN files on the host so that they ONLY bridge to the corresponding vzbrN interface.  /etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-vzbrN files and copy the IP configuration that was previously in the ifcfg-ethN files into ifcfg-vzbrN.  Here's what host:/etc/sysconfig/network-scripts/ifcfg-vzbr0 would look like assuming the IPv4 address is assigned statically and IPv6 auto-configuration (SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-vzbr1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has both IPv4 and IPv6 connectivity to its vzbrN interfaces.&lt;br /&gt;
&lt;br /&gt;
5.  Create the VE as you normally would except do NOT specify any IP address, just the hostname.  Specifying an IP address during VE creation creates an unwanted venet interface which is not used in this configuration.&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, remove any venet devices - they will not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1&lt;br /&gt;
&lt;br /&gt;
The above creates corresponding veth100.0 and veth100.1 devices on the host and updates the host /etc/vz/conf/100.conf file with generated MAC addresses for the veth devices.&lt;br /&gt;
&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either do another 'service network restart' on the host, or manually add each VE interface to its corresponding bridge by running:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif vzbr0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif vzbr1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
9.  In the container create the ifcfg network scripts for each interface eth0 and eth1.  The scripts should look like standard ifcfg network scripts for a host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
After entering the VE:&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be created to be identical to standard ifcfg-eth* files from a non-virtualized host.&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Add FORWARD ACCEPT statements to the host iptables and ip6tables for each VE IPv4 and IPv6 address.  You do NOT need to enable any special network forwarding via sysctl.&lt;br /&gt;
&lt;br /&gt;
iptables:&lt;br /&gt;
        -A FORWARD -s xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
ip6tables:&lt;br /&gt;
        -A FORWARD -s xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
Then restart both iptables and ip6tables on the host:&lt;br /&gt;
&lt;br /&gt;
        service iptables restart&lt;br /&gt;
        service ip6tables restart&lt;br /&gt;
&lt;br /&gt;
12.  Verify the host and VE have connectivity to each other as well as to the rest of the network.&lt;br /&gt;
&lt;br /&gt;
13.  For each additional VE, start at step #5.&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
	<entry>
		<id>https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8096</id>
		<title>VEs and HNs in same subnets</title>
		<link rel="alternate" type="text/html" href="https://wiki.openvz.org/index.php?title=VEs_and_HNs_in_same_subnets&amp;diff=8096"/>
		<updated>2010-01-25T00:34:12Z</updated>

		<summary type="html">&lt;p&gt;Tony: New page: This describes a method of setting up networking for a host and its VEs such that the networking configuration for the VEs can be configured exactly as if the VEs were standalone hosts of ...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This describes a method of setting up networking for a host and its VEs&lt;br /&gt;
such that the networking configuration for the VEs can be configured&lt;br /&gt;
exactly as if the VEs were standalone hosts of their own in the same&lt;br /&gt;
subnets or VLAN as the host.  This method makes use of the Virtual&lt;br /&gt;
Ethernet device and bridges between the host and its containers.  This&lt;br /&gt;
technique has the advantage of allowing IPv6 network configurations to&lt;br /&gt;
work on VEs and hosts as they normally would.  In particular, both hosts&lt;br /&gt;
and VEs can use IPv6 autoconfiguration.  The network configuration of a VE&lt;br /&gt;
can be identical to that of a non-VE system.&lt;br /&gt;
&lt;br /&gt;
In the following example the host has two physical interfaces and we are&lt;br /&gt;
setting up the network configuration for VE 100.  The host IP&lt;br /&gt;
configuration is moved out of the ethN interface configs and into the&lt;br /&gt;
vzbrN interface config scripts (ifcfg-vzbr0 and ifcfg-vzbr1).  Ie. the&lt;br /&gt;
host IP configuration will now reside on the vzbrN interfaces instead of&lt;br /&gt;
the ethN interfaces.&lt;br /&gt;
&lt;br /&gt;
1.  (Optional) Verify that you can create a bridge interfaces for each&lt;br /&gt;
physical interface on the host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr0&lt;br /&gt;
        /usr/sbin/brctl addbr vzbr1&lt;br /&gt;
&lt;br /&gt;
2.  Make note of the existing IP configuration in the hosts ifcfg-ethN&lt;br /&gt;
files.  Then, modify the ifcfg-ethN files on the host so that they ONLY&lt;br /&gt;
bridge to the corresponding vzbrN interface.  &lt;br /&gt;
/etc/sysconfig/network-scripts/ifcfg-eth0 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth0&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Similarly ifcfg-eth1 will look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=eth1&lt;br /&gt;
        BOOTPROTO=none&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
Note that the ifcfg-ethN files on the host do not contain any IP&lt;br /&gt;
information anymore.&lt;br /&gt;
&lt;br /&gt;
3.  Create ifcfg-vzbrN files and copy the IP configuration that was&lt;br /&gt;
previously in the ifcfg-ethN files into ifcfg-vzbrN.  Here's what&lt;br /&gt;
host:/etc/sysconfig/network-scripts/ifcfg-vzbr0 would look like assuming&lt;br /&gt;
the IPv4 address is assigned statically and IPv6 auto-configuration&lt;br /&gt;
(SLAAC) is used:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr0&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=xxx.xxx.xxx.xxx&lt;br /&gt;
        NETMASK=aaa.aaa.aaa.aaa&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
Similarly, ifcfg-vzbr1 should look like:&lt;br /&gt;
&lt;br /&gt;
        DEVICE=vzbr1&lt;br /&gt;
        BOOTPROTO=static&lt;br /&gt;
        IPADDR=yyy.yyy.yyy.yyy&lt;br /&gt;
        NETMASK=bbb.bbb.bbb.bbb&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        TYPE=bridge&lt;br /&gt;
&lt;br /&gt;
4.  On the host, do a 'service network restart' and verify the host has&lt;br /&gt;
both IPv4 and IPv6 connectivity to its vzbrN interfaces.&lt;br /&gt;
&lt;br /&gt;
5.  Create the VE as you normally would except do NOT specify any IP&lt;br /&gt;
address, just the hostname.  Specifying an IP address during VE creation&lt;br /&gt;
creates an unwanted venet interface which is not used in this&lt;br /&gt;
configuration.&lt;br /&gt;
&lt;br /&gt;
However, if the VE already exists, remove any venet devices - they will &lt;br /&gt;
not be used:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --ipdel all --save&lt;br /&gt;
&lt;br /&gt;
6.  For each VE, create ethN devices (ignore warnings about &amp;quot;Container&lt;br /&gt;
does not have configured veth&amp;quot;) on the host:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth0&lt;br /&gt;
        /usr/sbin/vzctl set 100 --netif_add eth1&lt;br /&gt;
&lt;br /&gt;
The above creates corresponding veth100.0 and veth100.1 devices on the&lt;br /&gt;
host and updates the host /etc/vz/conf/100.conf file with generated MAC&lt;br /&gt;
addresses for the veth devices.&lt;br /&gt;
&lt;br /&gt;
7.  Next we add the host vethN interfaces to the host bridged&lt;br /&gt;
interfaces (vzbrN).&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.0&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.0&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr0&lt;br /&gt;
&lt;br /&gt;
Create host:/etc/sysconfig/network-scripts/ifcfg-veth100.1&lt;br /&gt;
&lt;br /&gt;
        DEVICE=veth100.1&lt;br /&gt;
        ONBOOT=yes&lt;br /&gt;
        BRIDGE=vzbr1&lt;br /&gt;
&lt;br /&gt;
To make the above take effect, either do another 'service network restart'&lt;br /&gt;
on the host, or manually add each VE interface to its corresponding bridge&lt;br /&gt;
by running:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl addif vzbr0 veth100.0&lt;br /&gt;
        /usr/sbin/brctl addif vzbr1 veth100.1&lt;br /&gt;
&lt;br /&gt;
8.  Verify each bridge includes the host interface and the veth interfaces &lt;br /&gt;
for each VE:&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/brctl show&lt;br /&gt;
&lt;br /&gt;
9.  In the container create the ifcfg network scripts for each interface&lt;br /&gt;
eth0 and eth1.  The scripts should look like standard ifcfg network&lt;br /&gt;
scripts for a host.&lt;br /&gt;
&lt;br /&gt;
        /usr/sbin/vzctl enter 100&lt;br /&gt;
&lt;br /&gt;
After entering the VE:&lt;br /&gt;
&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth0&lt;br /&gt;
        vi /etc/sysconfig/network-scripts/ifcfg-eth1&lt;br /&gt;
&lt;br /&gt;
As noted above, the ifcfg-ethN files in the VE should be identical to&lt;br /&gt;
standard ifcfg-eth* files containing any required IP configuration info.&lt;br /&gt;
&lt;br /&gt;
10.  Initialize the interfaces and restart the network service on the&lt;br /&gt;
container.&lt;br /&gt;
&lt;br /&gt;
        /sbin/ifconfig eth0 0&lt;br /&gt;
        /sbin/ifconfig eth1 0&lt;br /&gt;
        /sbin/service network restart&lt;br /&gt;
&lt;br /&gt;
Alternatively, just restart the VE from the host.&lt;br /&gt;
&lt;br /&gt;
11.  Add FORWARD ACCEPT statements to the host iptables and ip6tables for&lt;br /&gt;
each VE IPv4 and IPv6 address.  You do NOT need to enable any special &lt;br /&gt;
network forwarding via sysctl.&lt;br /&gt;
&lt;br /&gt;
iptables:&lt;br /&gt;
        -A FORWARD -s xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxx.xxx.xxx.xxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
ip6tables:&lt;br /&gt;
        -A FORWARD -s xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
        -A FORWARD -d xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx -j ACCEPT&lt;br /&gt;
&lt;br /&gt;
Then restart both iptables and ip6tables on the host:&lt;br /&gt;
&lt;br /&gt;
        service iptables restart&lt;br /&gt;
        service ip6tables restart&lt;br /&gt;
&lt;br /&gt;
12.  Verify the host and VE have connectivity to each other as well as to &lt;br /&gt;
the rest of the network.&lt;br /&gt;
&lt;br /&gt;
13.  For each additional VE, start at step #5.&lt;/div&gt;</summary>
		<author><name>Tony</name></author>
		
	</entry>
</feed>