Changes

<translate><!--T:1-->'''Virtual ethernet Ethernet device ''' is ethernet an Ethernet-like device which that can be used inside a [[VEcontainer]]. Unlikea [[venet ]] network device, a [[veth ]] device has a MAC address. Due to thisTherefore, it can be used in more configurations, when . When veth is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as anethX or other device and VPS independent host on the network. The container's user fully setups his can set up all of the networking himself, including IPs, gateways , etc.

Virtual ethernet <!--T:2-->A virtual Ethernet device consist consists of two ethernet Ethernet devices - ,one in [[VE0CT0]] (e.g., vethN.0) and another a corresponding one in VECT (e. These devices g., eth0) that are connected to each other, so if . If a packet goes is sent to onedevice it will come out from the other device.

== Differences between venet and veth Virtual Ethernet device usage ==* veth allows broadcasts in VE, so you can use even dhcp server inside VE or samba server with domain broadcasts or other such stuff.* veth has some security implications, so is not recommended in untrusted environments like HSP. This is due to broadcasts, traffic sniffing, possible IP collisions etc. i.e. VE user can actually ruin your ethernet network with such direct access to ethernet layer.* With venet device, only node administrator can assign an IP to a VE. With veth device, network settings can be fully done on VE side. VE should setup correct GW, IP/mask etc and node admin then can only choose where your traffic goes.* veth devices can be bridged together and/or with other devices. For example, in host system admin can bridge veth from 2 VEs with some VLAN eth0.X. In this case, these 2 VEs will be connected to this VLAN.* venet device is a bit faster and more efficient.* With veth devices IPv6 auto generates an address from MAC.<!--T:3-->

=== Kernel module === <!--T:4-->The brief summary:<code>vzethdev</code> module should be loaded. You can check it with the following commands.<pre>{# lsmod | class="wikitable"grep vzethvzethdev 8224 0vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcptvzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota</pre>|+ '''Differences between veth and venet'''<! Feature --T:5-->In case it is not loaded, load it:<pre># modprobe vzethdev</pre> === MAC addresses === <!--T:6-->The following steps to generate a MAC address are not necessary, since newer versionsof vzctl will automatically generate a MAC address for you. These steps are providedin case you want to set a MAC address manually. <! veth --T:7-->You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions. <!! venet|--T:8-->! MAC addressaddresses must be entered in XX:XX:XX:XX:XX:XX format. | + || <!--T:9-->|There is a utility script available for generating MAC addresses: https://github.com/moutai/eucalyptus-utils/blob/master/easymac.sh. It is used like this:  <! Broadcasts inside VE--T:10-->| chmod + || x easymac.sh ./easymac.sh -R|=== Adding veth to a CT === <!--T:11-->  <! Traffic sniffing--T:12-->| + || vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]|<!--T:13-->! Network securityHere* <tt>ifname</tt> is the Ethernet device name in the CT* <tt>mac</tt> is its MAC address in the CT* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])| low * <tt>host_mac<ref/tt>Due to broadcastsis its MAC address on the host ([[CT0]]), if you want independent communication with the Container through the bridge, sniffing and possible IP collisions etcyou should explicitly specify multicast MAC address here (FE:FF:FF:FF:FF:FF).* <tt>bridge</reftt> || hi|- ! Can is an optional parameter which can be used in bridgescustom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)| + || <!--|T:14-! Performance| fast || fastest|->{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified.}} <references/!--T:15-->Example:

=== Adding veth to a VE === <pre!--T:18-->vzctl set <VEID> 101 --veth_add <dev_name>netif_add eth0,<dev_addr>00:12:34:56:78:9A,<ve_dev_name>veth101.0,00:12:34:56:78:9B --save <ve_dev_addr!--T:19-->If you want to use independent communication through the bridge:  </pre!--T:20-->Here vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,FE:FF:FF:FF:FF:FF,vzbr0 --save * <tt!--T:21-->dev_name</tt> is ethernet device name in If you want to specify the bridge and autogenerate the [[VE0|host system]]other values: * <tt!--T:22-->dev_addrvzctl set 101 --netif_add eth0,,,,vzbr0 --save === Removing veth from a CT === </tt!--T:23--> is its MAC address* <tt!--T:24-->ve_dev_name</tt> is an ethernet device name in the VE* vzctl set <ttCTID>ve_dev_addr--netif_del </ttdev_name> is its MAC address|all

MAC addresses must be entered in XX<!--T:XX:XX:XX:XX:XX format. Note that this option25-->Here* <code>dev_name</code> is incremental, so devices are added to already existing onesthe Ethernet device name in the [[CT]].

==== Examples ====<pre>vzctl set 101 !--veth_add veth101.0,00T:12:34:56:78:9A,eth0,00:12:34:56:78:9B 26--save</pre>After executing this command <tt>veth</tt> device will be created for VE 101 and veth configuration will be saved {{Note|If you want to a VE configuration file.Host-side ethernet device will have <tt>veth101.0</tt> name and <tt>00:12:34:56:78:9A</tt> MAC address.VE-side ethernet device will have <tt>eth0remove all Ethernet devices in CT, use </ttcode> name and <tt>00:12:34:56:78:9Ball</ttcode> MAC address.{{Note|Use random MAC addresses. Do not use MAC addresses of real eth devices, beacuse this can lead to collisions.}}

=== Removing veth from a VE ===<pre>vzctl set <VEID> !--T:27--veth_del <dev_name></pre>Here <tt>dev_name</tt> is the ethernet device name in the [[VE0|host system]].Example:

==== Example ==== <pre!--T:28-->vzctl set 101 --veth_del veth101.0 netif_del eth0 --save</pre>After executing this command veth device with host-side ethernet name veth101.0 will be removed from VE 101 and veth configuration will be updated in VE config file.

== Common configurations with virtual ethernet Ethernet devices ==<!--T:29-->

=== Simple configuration with virtual ethernet Ethernet device ===<!--T:30-->

<!--T:31-->Assuming that 192.168.0.0/24 is being used on your LAN, the following sections show how to configure a container for the LAN using veth. ==== Start a VE CT ====<!--T:32-->  <pre!--T:33-->

==== Add veth device to VE CT ====<!--T:34-->  <pre!--T:35-->[host-node]# vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,netif_add eth0,00:12:34:56:78:9B --save </pre!--T:36-->This allocates a MAC address and associates it with the host eth0 port.

==== Configure devices in VE0 CT0 ====<!--T:37-->The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.

[host-node]# ifconfig veth101.0 up0

==== Configure device in VE CT ====<!--T:38-->The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.

[ve-101]# /sbin/ifconfig eth0 up0

<!--T:39-->Notes:* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.* The "ip route" tells all traffic to head to "device eth0"* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it** http://openvz.org/pipermail/users/2005-November/000020.html ==== Add route in [[VE0CT0]] ====<pre!--T:40-->Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination. [host-node]# ip route add 192.168.0.101 dev veth101.0 === Using a directly routed IPv4 with virtual Ethernet device === <!--T:41--> ==== Situation ==== <!--T:42-->Hardware Node (HN/CT0) has 192.168.0.1/pre24 with router 192.168.0.254. <!--T:43-->We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP''). <!--T:44-->We want to give this directly routed IPv4 address to a container (CT).

=== Virtual ethernet device with IPv6 =Start container ==== <!--T:45-->

==== Start [[VE]] ==== <pre!--T:46-->

==== Add veth device to CT ==== <!--T:47-->  <!--T:48-->[[VE]host-node] # vzctl set 101 --netif_add eth0 --save <!--T:49-->This allocates a MAC address and associates it with the host eth0 port. ==== Configure device and add route in CT0 ====<!--T:50--> <!--T:51-->

[host-node]# vzctl set 101 ifconfig veth101.0 0[host--veth_add node]# ip route add 10.0.0.1 dev veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save

==== Configure devices <!--T:52-->You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>. <!--T:53-->The problem here is that the ''veth'' interface appears in [[VE0]] ====CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route. <!--T:54-->Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:

[host#!/bin/bash# This script source VPS configuration files in the same order as vzctl does <!--T:55--node]># ifconfig veth101.0 upif one of these files does not exist then something is really broken[host-node]# echo 1 > f /procetc/sys/net/ipv6vz/vz.conf/veth101.0/forwarding] || exit 1[host-nodef $VE_CONFFILE ]# echo || exit 1  <!--T:56--> # source both files. Note the order, it is important. /procetc/sys/net/ipv6vz/vz.conf/eth0/forwarding[host. $VE_CONFFILE <!--T:57--node]># echo Configure veth with IP after VPS has started{ IP=X.Y.Z.T DEV=veth101.0 while sleep 1 > ; do /procsbin/sysifconfig $DEV 0 >/netdev/ipv6null 2>&1 if [ $? -eq 0 ]; then /confsbin/all/forwardingip route add $IP dev $DEV break fi done} &

==== Configure device Make sure IPv4 forwarding is enabled in [[VE]] CT0 ====<!--T:58--> <!--T:59-->

[host-node]# vzctl enter 101echo 1 > /proc/sys/net/ipv4/ip_forward[vehost-101node]# echo 1 > /sbinproc/sys/net/ipv4/conf/ifconfig eth0 up/forwarding[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding

==== Start router advertisement daemon (radvd) for IPv6 Configure device in VE0 CT ====First you need to edit radvd configuration file. Here is a simple example of <tt>/etc/radv.conf</tt>!--T:<pre60-->interface veth101.0{ AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvHomeAgentFlag off;

prefix 3ffe<!--T:2400:0:0::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; };61-->};1. Configure IP address

prefix 3ffe<!--T:0302:0011:0002::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off;63--> };};</pre>3. Add default route

Then, start radvd<!--T:64-->

[hostve-node101]# /etcsbin/initifconfig eth0 10.d0.0.1 netmask 255.255.255.255[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0[ve-101]# /radvd startsbin/ip route add default via 192.168.0.1

[host-node]# ip addr add dev veth101auto eth0iface eth0 inet static address 10.0.0 3ffe:2400::212:34ff:fe56:789a.1 netmask 255.255.255.255 up /sbin/64[host-node]# ip addr route add 192.168.0.1 dev eth0 3ffe:0302:0011:0002:211:22ff:fe33:4455 up /sbin/64ip route add default via 192.168.0.1

=== Virtual ethernet devices can be joined Ethernet device with IPv6 === <!--T:66--> <!--T:67-->See the [[VEs and HNs in one same subnets]] article. === Independent Virtual Ethernet communication through the bridge ===<!--T:68-->Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]] or event the routing.Perform <!--T:69-->To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several VEs containers and/or veth devicesusing FE:FF:FF:FF:FF:FF as a [[CT0]] veth side MAC address and then follow these steps.

==== Create bridge device ====<!--T:70-->

==== Add veth devices to bridge ====<!--T:71-->

==== Configure bridge device ====<!--T:72--><pre>[host-node]# ifconfig vzbr0 0</pre> === Automating the bridge === <!--T:73-->The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]]. <!--T:74-->In Debian, configure the network interface on [[CT0]] to plug into a bridge in /etc/network/interfaces. The [[CT0]] physical device is added to the bridge as the "uplink" port to the physical network. You need to have bridge-utils installed for this to work. <!--T:75-->The bridge forwarding delay is set to 0 seconds so that forwarding begins immediately when a new interface is added to a bridge. The default delay is 30 seconds, during which the bridge pauses all traffic to listen and figure out where devices are. This can interrupt services when a container is added to the bridge. If you aren't running the spanning tree protocol (off by default) and the bridge does not create a loop in your network, then there is no need for a forwarding delay.<pre>iface eth0 inet manual <!--T:76-->auto vzbr0iface vzbr0 inet static bridge_ports eth0 bridge_fd 0 address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.254</pre>Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules. Note that as discussed in the troubleshooting section below, bridged packets by default pass through the FORWARD iptables chain. Take care when adding rules to that table that bridged packets are not mistakenly blocked. This behavior can be disabled, if desired (sysctl: <code>net.bridge.bridge-nf-call-iptables</code>). === Making a veth-device persistent === <!--T:77-->These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference. <!--T:78-->According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced" <!--T:79-->See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section. <!--T:80-->That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network. === Making a bridged veth-device persistent === <!--T:81--> <!--T:82-->Like the above example, here it is how to add the veth device to a bridge in a persistent way.  <!--T:83-->vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch. <!--T:84-->Just create /etc/vz/vznet.conf containing the following. <!--T:85-->

[host-node]# ifconfig vzbr0 up[host-node]# echo 1 > EXTERNAL_SCRIPT="/procusr/syssbin/net/ipv4/conf/vzbr0/forwarding[host-node]# echo 1 > /proc/sys/net/ipv4/conf/vzbr0/proxy_arpvznetaddbr"

[host-node]# ip route add 192echo 'EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"' > /etc/vz/vznet.168.101.1 dev vzbr0...[host-node]# ip route add 192.168.101.n dev vzbr0[host-node]# ip route add 192.168.102.1 dev vzbr0......[host-node]# ip route add 192.168.XXX.N dev vzbr0conf

Thus you<!--T:87-->The script uses 'll have more convinient configuration, i.e. all routes to VEs will be through this vmbr0' as default bridge name when no bridge and VEs can communicate with each other even without these routesis specified.

=== Virtual ethernet Ethernet devices + VLAN ===<!--T:88-->

== See also == <!--T:89-->* [[Virtual network device]]* [[Differences between venet and veth]]* [[Using private IPs for Hardware Nodes]]* Patch: [[Disable venet interface]]* Troubleshooting: [[Bridge doesn't forward packets]] == External links ==<!--T:90-->