Article ID: 119882, created on Jan 29, 2014, last review on May 11, 2014

  • Applies to:
  • Virtuozzo
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor


  1. A couple (or more) of containers experience network troubles: high percentage of packet loss and totally unstable network connectivity.
  2. Containers are configured in bridged mode.
  3. A traffic capture on the host's physical interface, to which the container is bridged, shows no loss of packets, while a traffic capture inside the containers shows packets delivered intermittently.


Two (or more) containers have the same MAC and HOST_MAC addresses, which causes a network conflict:

[root@vz ~]# vzlist -ao veid,mac,host_mac | grep :
       101 00:18:51:B8:53:8A 00:18:51:CD:38:50  <----!!!
       102 00:18:51:E2:38:C2 00:18:51:FB:66:D0
       103 00:18:51:0F:1A:E0 00:18:51:2A:D7:9B
     11011 00:18:51:B8:53:8A 00:18:51:CD:38:50  <----!!!
     11012 00:18:51:81:73:F6 00:18:51:78:90:9D

Such situation may occur in case of a backup restoration to a different container ID or as a result of manual actions on the configuration of containers.


To fix the issue, it is necessary to change both MACs with the following command:

# vzctl set $CTID --save --ifname eth0 --mac 00:18:51:XX:XX:XX --host_mac 00:18:51:XX:XX:XX

MACs can be picked randomly and should be unique in LAN-scope. Prefix 00:18:51 should be preserved.

Troubleshooting Steps

  1. Start pinging the container's IP address and launch the following monitor in a separate window:

    [root@bm07 ~]# while sleep 1 ; do brctl showmacs br2 | grep ce:5b ; done
     11     bc:ae:c5:0a:66:86       no                 2.53
     11     bc:ae:c5:0a:66:86       no                 3.53
     11     bc:ae:c5:0a:66:86       no                 4.53
      3     bc:ae:c5:0a:66:86       no                 0.10
      3     bc:ae:c5:0a:66:86       no                 0.33
      3     bc:ae:c5:0a:66:86       no                 1.34
      3     bc:ae:c5:0a:66:86       no                 2.34
     11     bc:ae:c5:0a:66:86       no                 0.66
     11     bc:ae:c5:0a:66:86       no                 1.66

    Here, bc:ae:c5:0a:66:86 is the MAC address of the problematic container.

    The first column shows the port, where a certain MAC address is bound to, and it can be seen as changing intermittently from 3 to 11.

  2. Check what else is plugged into both ports:

    [root@bm07 ~]# brctl showmacs br2 | egrep "^[[:space:]]*3|^[[:space:]]*11"
     11     bc:ae:c5:0a:66:86       no                 1.32
     11     bc:ae:c5:18:f4:b2       yes                0.00

    Port 11 is additionally associated with the physical address bc:ae:c5:18:f4:b2.

  3. Check this address on the host:

    [root@bm07 ~]# ip a l | grep -B1 f4:b2
    46: veth103.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
        link/ether bc:ae:c5:18:f4:b2 brd ff:ff:ff:ff:ff:ff
    59: veth108.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
        link/ether bc:ae:c5:18:f4:b2 brd ff:ff:ff:ff:ff:ff

    Here's where the conflict occurs, as the same MAC is owned by two virtual adapters simultaneously.

Search Words

high package loss

a26b38f94253cdfbf1028d72cf3a498b 2897d76d56d2010f4e3a28f864d69223 d02f9caf3e11b191a38179103495106f e8e50b42231236b82df27684e7ec0beb 0dd5b9380c7d4884d77587f3eb0fa8ef

Email subscription for changes to this article
Save as PDF