Common Networking HOWTOs

While other pages do a great job of going into the details of veth and venet networking, this page is all about getting the results you want quickly.

Private VEs (not directly visible from the LAN)

When starting with a new VE that should not be directly visible on the LAN it is important to choose an appropriate IP address. By running "ifconfig -a" on the host it is possible to see all the networks the host is connected to. The VE should reside on a a new private network, choosing one of the 192.168.X.Y/24 subnets is a good choice.

For example, on a host which is already on a 192.168.1.0/24 subnet then the 192.168.2.0/24 subnet would be a reasonable choice (unless the host is already on that subnet too).

In these examples the host has eth0 with address 192.168.1.53, and 192.168.2.0/24 is free so we will give the VE 192.168.2.1. The VE (101) is assumed to be freshly created and started, with no networking currently set up.

Venet

Venet routed networking is probably the simplest to set up, simply add the IP address to the VE:

[host-node]# vzctl set 101 --ipadd 192.168.2.1 --save

After this the host should be able to ping the VE.

To allow the VE to access the rest of the LAN we must enable forwarding and masquerading, as all activity on the LAN must look like it is coming directly from host (with its IP address).

[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward
[host-node]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Veth

This is a stub

Public VEs (with their own IP addresses)

Static addresses

This is very similar to using private addresses, except there is no need for masquerading and the VE will be visible to others on the LAN.

In this example the host has eth0 with address 192.168.1.53, and the VE will be set up with 192.168.1.101. The VE (101) is assumed to be freshly created and started, with no networking currently set up.

[host-node]# vzctl set 101 --ipadd 192.168.1.101 --save
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward

DHCP supplied addresses

For this section the following assumptions have been made:

• The host is connected to the LAN by eth0, and also uses DHCP.
• The DHCP server is another machine on the LAN.

To make the VEs truly part of the LAN it is best to create a bridge that binds them, and the LAN, together. Configuring the host to use a bridge when it boots is distribution specific and beyond the scope of this article. It can be done from the command line as follows:

bring eth0 down (distro dependent)
[host-node]# /etc/init.d/net.eth0 down
-- or --
[host-node]# ifdown eth0
etc.

create the bridge
[host-node]# brctl addbr br0

add eth0
[host-node]# brctl addif br0 eth0

each bridge interface must be up, but with no ip address
[host-node]# ifconfig eth0 0

now run DHCP for the bridge (client dependent)
[host-node]# dhcpcd br0
-- or --
[host-node]# dhclient3 br0
etc.

At this stage the host should be present on the LAN (test with pings), much as it was before, only now it is using a bridge that can have other interfaces attached to it.

Starting with a new VE (101), which should have no networking configured and be running, it is now necessary to add a veth device. First the mac address of eth0 must be determined.

[host-node]# ifconfig eth0
...
HWaddress 00:12:34:56:78:9B
...

Now a new mac address must be invented, preferably higher than eth0's address.

[host-node]# easymac.sh -R
00:12:34:56:78:9A

The new veth device can be assigned using the above information.

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

Now add the new device to the bridge and bring it up on the host.

[host-node]# ifconfig veth101.0 0
[host-node]# brctl addif br0 veth101.0

Finally, the network should be fully in place, so run the DHCP client inside the VE

[host-node]# vzctl enter 101
101# dhcpcd venet0:0