Difference between revisions of "Virtual network device"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(Kernel module)
(Adding IP address to a container)
 
(28 intermediate revisions by 12 users not shown)
Line 1: Line 1:
Vitual network device (<code>venet</code>) is the default network device for a [[VE]]. This network device looks like a peer-to-peer connection between [[VE]] and the [[VE0|host system]]. It does packet switching based on IP header. This is a default network device for VE (an alternative is [[veth]] device).
+
Virtual network device (<code>venet</code>) is the default network device for a [[container]]. Due to [[w:Network_Layer|Layer 3]] employed by OpenVZ's venet, this network device looks like a point-to-point connection between [[container]] and the [[CT0|host system]]. It does packet switching based on IP header. This is a default network device for container (an alternative is [[veth]] device).
  
Venet device is created automatically on [[VE]] start. Vzctl scripts set up an appropriate IP address and other settings on venet inside a VE.
+
Venet drop ip-packets '''from''' the container with a source address, and '''in''' the container with the destination address, which is not corresponding to an ip-address of the container.
 +
 
 +
Venet device is created automatically on [[container]] start. Vzctl scripts set up an appropriate IP address and other settings on venet inside a container.
  
 
==  Usage ==
 
==  Usage ==
Line 18: Line 20:
 
You might want to check /etc/init.d/vz script to make sure the module gets loaded during startup.
 
You might want to check /etc/init.d/vz script to make sure the module gets loaded during startup.
  
=== Adding IP address to a VE ===
+
=== Adding IP address to a container ===
 
<pre>
 
<pre>
vzctl set <VEID> --ipadd <IP1>[,<IP2>,...] [--save]
+
vzctl set <CTID> --ipadd <IP1>[,<IP2>,...] [--save]
 
</pre>
 
</pre>
 +
 +
Address can optionally have a netmask specified in the CIDR notation (e.g. 10.1.2.3/25).
  
 
{{Note|This option is incremental, so IP addresses are added to already existing ones.}}
 
{{Note|This option is incremental, so IP addresses are added to already existing ones.}}
Line 27: Line 31:
 
==== Example ====
 
==== Example ====
 
<pre>
 
<pre>
vzctl set 101 --ipadd 10.0.0.1 --save
+
vzctl set 101 --ipadd 10.0.0.1 --save
 +
vzctl set 101 --ipadd fd00::101 --save
 
</pre>
 
</pre>
After executing this command IP address 10.0.0.1 will be added to VE 101 and IP configuration will be saved to a VE configuration file.
+
After executing this command IP address 10.0.0.1 will be added to container 101 and IP configuration will be saved to a container configuration file.
  
=== Removing IP address from a VE ===
+
=== Removing IP address from a container ===
 
<pre>
 
<pre>
vzctl set <VEID> --ipdel <IP1>[,<IP2>,...] [--save]
+
vzctl set <CTID> --ipdel <IP1>[,<IP2>,...] [--save]
vzctl set <VEID> --ipdel all [--save]
+
vzctl set <CTID> --ipdel all [--save]
 
</pre>
 
</pre>
  
Line 40: Line 45:
 
<pre>
 
<pre>
 
vzctl set 101 --ipdel 10.0.0.1
 
vzctl set 101 --ipdel 10.0.0.1
 +
vzctl set 101 --ipdel fd00::101
 
</pre>
 
</pre>
After executing this command IP address 10.0.0.1 will be removed from VE 101, but IP configuration will not be changed in VE config file. And after VE reboot IP address 10.0.0.1 will be assigned to this VE again.
+
After executing this command IP address 10.0.0.1 will be removed from container 101, but IP configuration will not be changed in container config file. And after container reboot IP address 10.0.0.1 will be assigned to this container again.
 +
 
 +
== Specific aspects of venet network device ==
 +
 
 +
{{Note|If you require a feature which venet is lacking (from the list below), please consider using [[veth]] device (which have [[w:Data_Link_Layer|layer 2]] support.)}}
 +
 
 +
=== No [[w:Address_Resolution_Protocol|ARP]] protocol support ===
 +
Venet network device is explicitly NOARP, so there is no MAC address.
 +
Consequently, it's not possible to make broadcasts inside a [[container]], so software like Samba server or DHCP server will not function (under a container with a venet network device).
 +
 
 +
=== No [[w:Network_bridge|bridge]] support ===
 +
Venet network device cannot be bridged together and/or with other devices.
 +
 
 +
=== No possiblity to assign an IP from the CT ===
 +
With venet device, only OpenVZ [[hardware node]] administrator can assign an IP address to a [[container]].
 +
 
 +
=== Limited packet sniffing support ===
 +
Some applications using libpcap and similar packages will report an error.
 +
 
 +
=== No full support of IPv6 stack ===
 +
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, to get your venet devices working.
 +
Please have a look at the [[Quick installation#sysctl]] section.
 +
 
 +
veth devices do require iptables and ip6tables exceptions on the host for each VE address.
 +
 
 +
You'll need to use the veth bridging device if you want full IPv6 compliance.  See the [[VEs and HNs in same subnets]] article for an example.
  
 
== See also ==
 
== See also ==

Latest revision as of 16:59, 10 February 2013

Virtual network device (venet) is the default network device for a container. Due to Layer 3 employed by OpenVZ's venet, this network device looks like a point-to-point connection between container and the host system. It does packet switching based on IP header. This is a default network device for container (an alternative is veth device).

Venet drop ip-packets from the container with a source address, and in the container with the destination address, which is not corresponding to an ip-address of the container.

Venet device is created automatically on container start. Vzctl scripts set up an appropriate IP address and other settings on venet inside a container.

Usage[edit]

Kernel module[edit]

First of all, check that vznetdev module is loaded:

# lsmod | grep vznetdev

If it is not, load the module:

# modprobe vznetdev

You might want to check /etc/init.d/vz script to make sure the module gets loaded during startup.

Adding IP address to a container[edit]

vzctl set <CTID> --ipadd <IP1>[,<IP2>,...] [--save]

Address can optionally have a netmask specified in the CIDR notation (e.g. 10.1.2.3/25).

Yellowpin.svg Note: This option is incremental, so IP addresses are added to already existing ones.

Example[edit]

vzctl set 101 --ipadd 10.0.0.1  --save
vzctl set 101 --ipadd fd00::101 --save

After executing this command IP address 10.0.0.1 will be added to container 101 and IP configuration will be saved to a container configuration file.

Removing IP address from a container[edit]

vzctl set <CTID> --ipdel <IP1>[,<IP2>,...] [--save]
vzctl set <CTID> --ipdel all [--save]

Example[edit]

vzctl set 101 --ipdel 10.0.0.1
vzctl set 101 --ipdel fd00::101

After executing this command IP address 10.0.0.1 will be removed from container 101, but IP configuration will not be changed in container config file. And after container reboot IP address 10.0.0.1 will be assigned to this container again.

Specific aspects of venet network device[edit]

Yellowpin.svg Note: If you require a feature which venet is lacking (from the list below), please consider using veth device (which have layer 2 support.)

No ARP protocol support[edit]

Venet network device is explicitly NOARP, so there is no MAC address. Consequently, it's not possible to make broadcasts inside a container, so software like Samba server or DHCP server will not function (under a container with a venet network device).

No bridge support[edit]

Venet network device cannot be bridged together and/or with other devices.

No possiblity to assign an IP from the CT[edit]

With venet device, only OpenVZ hardware node administrator can assign an IP address to a container.

Limited packet sniffing support[edit]

Some applications using libpcap and similar packages will report an error.

No full support of IPv6 stack[edit]

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, to get your venet devices working. Please have a look at the Quick installation#sysctl section.

veth devices do require iptables and ip6tables exceptions on the host for each VE address.

You'll need to use the veth bridging device if you want full IPv6 compliance. See the VEs and HNs in same subnets article for an example.

See also[edit]