Article ID: 120930, created on Apr 6, 2014, last review on Jun 17, 2016

  • Applies to:
  • Odin Business Automation Standard 4.5
  • Virtuozzo
  • Virtuozzo containers for Linux 4.7
  • Virtuozzo containers for Linux 4.6
  • Virtuozzo hypervisor


In Odin virtualization products, virtual environments can be configured to access network in routed mode. How does it work?


Routing rules on the host server.

In routed mode, a hardware node acts as a router for hosted virtual environments. Network packets are accepted by the hardware node and forwarded to the interface venet0 (for containers, packets are appended with a container's ID to be picked up by processes of a container) or to vmeXXXXX.N (for virtual machines).

This is done by configuring routing rules for IP addresses of virtual environments:

~# ip route list | egrep '\<(venet0|vme)' dev venet0  scope link  metric 1000 dev venet0  scope link  metric 1000 dev vme7bf29cfb.0  scope link dev vme7bf29cfb.0  proto kernel  scope link  src 


  1. In order to forward network packets, the node should have net.ipv4.ip_forward set to "1" in /etc/sysctl.conf.
  2. IPtables rules should allow traffic through the chain FORWARD.
  3. Offline Management (Power Panel) might keep a route with metric 1000.
  4. The default gateway for host-routed virtual machines is automatically assigned the IP address of

    NOTE: This special IP address was taken from the Automatic Private IP Addressing (APIPA) range ` to` 
    According to RFC-3927, the reserved APIPA address range was set to, thus doesn't fit in this range anymore. This will be changed in scope of the product issue with internal ID #PSBM-38735

Other configuration performed on the host server.

To let other network devices in the local network segment access virtual environments, the hardware node acts as an ARP proxy for IP addresses of running virtual environments. To allow network communication right on environment's start, ARP announcements are sent through all active ARP-capable interfaces with a configured IP address. The latter point is done mostly to detect possible IP collision in the network.

If IP collision detection is not disabled (global variable SKIP_ARPDETECT is not defined or it set to value other than "yes"), the following command is invoked for every interface (depending on its name, well-known interfaces are defined by a mask) which is active (state UP) and without flags NOARP, LOOPBACK, and SLAVE:

~# arpsend -c 1 -w 1 -D -e $IP1 -e $IP2 {... -e $IPn} $IFACE

If no IP collision is detected, then the request to update ARP table is sent for every IP address of an environment being started:

~# arpsend -c 1 -w 1 -U -i $IPn -e $IPn $IFACE

To answer ARP requests in the future, ARP proxy is enabled for every IP address on every active Ethernet interface:

~# ip neigh add proxy $IPn dev $IFACE

Enabled ARP proxy can be checked by looking for "PERM" records:

~# arp -an | grep '\<PERM\>'
? ( at * PERM PUP on eth0
? ( at * PERM PUP on eth0.5
? ( at * PERM PUP on eth0
? ( at * PERM PUP on eth0.5
? ( at * PERM PUP on eth0
? ( at * PERM PUP on eth0.5
? ( at 00:1c:42:26:6d:eb [ether] PERM on vme7bf29cfb.0

Important notes:

  1. ARP announcements in detection and update commands might fail if no IPv4 address is assigned to the interface.
  2. The list of interfaces to check as a regular expression is defined in the function "vzgetnetdev()", in /etc/sysconfig/vz-scripts/vz-functions.
  3. ARP check can produce false positives if a router-as-a-bridge presents in the network segment, bridging several LANs into a single segment.
  4. Offline Management (Power Panel) keeps ARP proxy enabled for IP addresses of stopped environments.
  5. Plugging several interfaces of a hardware node to the same switch needs additional configuration: either setting up an aggregate interface or disabling reverse path checking.

What do other hosts do to reach environments?

Simplifying the process, a network device does the following:

  1. it looks for an ARP entry for a given IP address to get a MAC address and an interface to sent packets to; typically, APR record contains "IP address", "MAC address", "Port/interface number/name"; if there is such entry, then it sends packets to that MAC which is known to be accessible on that interface;

    • the port or interface can be a physical port, some VLAN tagged interface, or an aggregate interface (LACP);
  2. without any matching ARP entry, routing rules are checked:

    • if there is a rule pointing to some interface, ARP resolution is used to determine a MAC address of a peer to use; the local ARP table is populated if there is any positive answer;
    • if there is a rule pointing to some host as a gateway, packets are sent to that host, which should be directly accessible.

Important notes:

  1. Network devices might flush ARP table, causing interruption of connections.
  2. Certain configuration options prevent ARP table update, which can lead to connectivity issues.
  3. If a network segment contains devices with IP addresses from several subnetworks, then all subnetworks should be configured as directly accessible for network devices - this is necessary for ARP resolution to work properly.
  4. Plugging several interfaces of a hardware node to the same switch without setting up bonding might cause asymmetric flow of packets and this should be avoided.

See also

  • KB #120266 vz-net_add WARNING: arpsend FAILED: IP is detected on another computer
  • KB #120677 When container is being (re)started arpsend warnings are displayed, what do they indicate?
  • KB #120136 Why do ARP entries still exist on the node when the container is stopped?
  • KB #115346 How to set up network for containers on node with two NICs

Search Words

prlctl hangs when adding many IPv6 address

pcs: networking

gateway not set


Not able to use other persistent routes with privnets

container network routed can't ping gateway


venet network mask

IPv6 on pcs


container not accessable

container can't ping gateway


network stop working in virtuozzo container

gå nu væk


virtuozzo networking

register hardware node


a26b38f94253cdfbf1028d72cf3a498b 2897d76d56d2010f4e3a28f864d69223 e8e50b42231236b82df27684e7ec0beb d02f9caf3e11b191a38179103495106f 0dd5b9380c7d4884d77587f3eb0fa8ef 0c05f0c76fec3dd785e9feafce1099a9 400e18f6ede9f8be5575a475d2d6b0a6 caea8340e2d186a540518d08602aa065 624ca542e40215e6f1d39170d8e7ec75 70a5401e8b9354cd1d64d0346f2c4a3e 36627b12981f68a16405a79233409a5e

Email subscription for changes to this article
Save as PDF