<translate>

'''Virtual Ethernet device''' is an Ethernet-like device that can be used

inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device

himself, including IPs, gateways, etc.

A virtual Ethernet device consists of two Ethernet devices,

one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are

connected to each other. If a packet is sent to one device it will come out the other device.

The <code>vzethdev</code> module should be loaded. You can check it with the following commands.

<pre>

</pre>

In case it is not loaded, load it:

<pre>

</pre>

The following steps to generate a MAC address are not necessary, since newer versions

of vzctl will automatically generate a MAC address for you. These steps are provided

in case you want to set a MAC address manually.

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.

MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.

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:

./easymac.sh -R

Here

* <tt>ifname</tt> is the Ethernet device name in the CT

* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)

{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified.}}

Example:

If you want to specify everything:

If you want to use independent communication through the bridge:

If you want to specify the bridge and autogenerate the other values:

Here

* <code>dev_name</code> is the Ethernet device name in the [[CT]].

{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}

Example:

Module <tt>vzethdev</tt> must be loaded to operate with veth devices.

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.

This allocates a MAC address and associates it with the host eth0 port.

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.

<pre>

</pre>

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.

<pre>

</pre>

Notes:

* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier

** http://openvz.org/pipermail/users/2005-November/000020.html

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

Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.

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'').

We want to give this directly routed IPv4 address to a container (CT).

This allocates a MAC address and associates it with the host eth0 port.

<pre>

[host-node]# ifconfig veth101.0 0

</pre>

You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.

The problem here is that the ''veth'' interface appears in 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.

Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:

<pre>

# This script source VPS configuration files in the same order as vzctl does

# if one of these files does not exist then something is really broken

[ -f /etc/vz/vz.conf ] || exit 1

[ -f $VE_CONFFILE ] || exit 1

# source both files. Note the order, it is important

. /etc/vz/vz.conf

. $VE_CONFFILE

# Configure veth with IP after VPS has started

{

</pre>

<pre>

[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward

You can permanently set this by using <tt>/etc/sysctl.conf</tt>.

1. Configure IP address

2. Add gateway

3. Add default route

<pre>

[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255

</pre>

In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:

<pre>

</pre>

See the [[VEs and HNs in same subnets]] article.

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.

To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices using FE:FF:FF:FF:FF:FF as a [[CT0]] veth side MAC address and then follow these steps.

<pre>

[host-node]# brctl addbr vzbr0

</pre>

<pre>

[host-node]# brctl addif vzbr0 veth101.0

</pre>

<pre>

[host-node]# ifconfig vzbr0 0

</pre>

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]].

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.

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

auto vzbr0

iface vzbr0 inet static

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.

These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.

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"

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.

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.

Like the above example, here it is how to add the veth device to a bridge in a persistent way.

vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.

Just create /etc/vz/vznet.conf containing the following.

<pre>

EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"

</pre>

Or just run command

<pre>

</pre>

The script uses 'vmbr0' as default bridge name when no bridge is specified.

This configuration can be done by adding vlan device to the previous configuration.

* [[Virtual network device]]

* [[Differences between venet and veth]]

* Troubleshooting: [[Bridge doesn't forward packets]]

* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]

* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]