Bug 583139 - Network bridge reassigned with the lowest MAC address among the attached devices, including tun/tap interfaces
Summary: Network bridge reassigned with the lowest MAC address among the attached devi...
Keywords:
Status: CLOSED DUPLICATE of bug 571991
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Daniel Veillard
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-16 19:16 UTC by Dan Yasny
Modified: 2016-04-26 15:18 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-06 15:01:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Flavio Leitner's patch adapted fpr RHEL's incarnation of libvirt 0.6.3 (1.97 KB, patch)
2010-06-24 08:14 UTC, Andreas Rogge
no flags Details | Diff

Description Dan Yasny 2010-04-16 19:16:58 UTC
+++ This bug is created as a clone of Bug #571991 and #582842 +++

The bridge is usually assigned the MAC of the physical NIC it is attached to. 
However it appears that it if there are multiple devices attached to a bridge, the bridge will assume the lowest numbering MAC. 

During normal operation, if the bridge is used for communication to a host, and a virtual tap device is attached to that bridge, with a MAC that is lower in number than the MAC of the physical NIC, the tap's MAC will be assigned to the bridge, disrupting the switch arp tables, effectively blocking networking to a host for a few minutes, until a new arp packet is sent and the new arp table is set up.


Here are the steps I used to recreate this issue in my setup:
1. Change the HWADDR line for eth1 (in  my case) to F0:00:00:00:00:01
2. ip link set eth1 address F0:00:00:00:00:01
3. service network restart
4. verify with ifconfig that eth1 and the bridge on it has a new HWADDR
5. Create a VM with several NICs, connected to the same Logical Network the
eth1 based bridge is used for
6. Start the VM up
7. See that the HWADDR for the bridge on eth1 has changed to the MAC of one of
the TUN devices    

How reproducible:
100%

Actual results:
Netowrk outage for a few minutes, or total outage if the switch has MACs assigned to ports.

Expected results:
bridges should not be reassigned to other MACs during operation, and should not assume any MACs that do not belong to operational physical devices, tagged interfaces or bonds.



Current workaround - reassigning all the tap devices with MACs that start with FE:... 


***************
Here's the original libvirt BZ

Description of problem:
libvirt assigns random MAC address to tap devices/vnet interfaces.

Version-Release number of selected component (if applicable):
kernel-2.6.18-164.el5
libvirt-0.6.3-20.1.el5_4

How reproducible:
100%

Steps to Reproduce:
1.Using Bridged Networking or default virtual networking/NAT forwarding,create
a KVM VM.
2.The vnet interface/tap device created for the VM is assigned a random MAC
address.


Actual results:
libvirt assigns random MAC address to tap devices 

Expected results:
libvirt should assign MAC address in the upper range(starting with FE:xx) to
tap devices 


Additional info:
1.A bridge acquires the lowest MAC address of all the ports connected
to it.So,the bridge may acquire a new MAC address every time a VM's created or
destroyed. 
2.When this change in the MAC address of the bridge happens,the KVM host may
become unreachable for a few minutes when bridged networking is used and the
KVM host's NIC is added to the bridge.So,libvirt should assign MAC address in
the upper range to tap devices to prevent the MAC address of the bridge from
changing every time a VM is created or destroyed.

These commands have been run on a 5.4 KVM host with bridged networking (bridge
br0)with a single Ethernet interface(eth0) added to br0,br0 gets the MAC
address of eth0.

Before creating a VM
-----------------------------
[root@dhcp243-202 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0023aea499cd       no              eth0

[root@dhcp243-202 ~]#ifconfig
br0       Link encap:Ethernet  HWaddr E4:1F:13:2E:99:08  
          inet addr:10.11.243.202  Bcast:10.11.243.255  Mask:255.255.254.0
          inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9939793 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1152537 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3256428730 (3.0 GiB)  TX bytes:91632907 (87.3 MiB)

eth0      Link encap:Ethernet  HWaddr E4:1F:13:2E:99:08  
          inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9787163 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1120849 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3364668232 (3.1 GiB)  TX bytes:94237619 (89.8 MiB)
          Interrupt:185 Memory:dbde0000-dbdf0000 

After creating a VM
------------------------------
[root@dhcp243-202 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0023aea499cd       no              vnet1
                                                        eth0

br0       Link encap:Ethernet  HWaddr CE:C7:92:CF:12:D8 
          inet addr:10.11.243.202  Bcast:10.11.243.255  Mask:255.255.254.0
          inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9946280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1152768 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3257838529 (3.0 GiB)  TX bytes:91669261 (87.4 MiB)

eth0      Link encap:Ethernet  HWaddr E4:1F:13:2E:99:08  
          inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9793654 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1121154 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3366192351 (3.1 GiB)  TX bytes:94286827 (89.9 MiB)
          Interrupt:185 Memory:dbde0000-dbdf0000 

vnet1     Link encap:Ethernet  HWaddr CE:C7:92:CF:12:D8 
          inet6 addr: fe80::f0cd:5aff:fe91:a1fa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:72 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4263 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:11406 (11.1 KiB)  TX bytes:957510 (935.0 KiB)

--- Additional comment from fleitner on 2010-03-29 14:09:43 EDT ---

Created an attachment (id=403334) [details]
proposed patch to fix tap interfaces mac addr

Hi,

I'm proposing this patch to libvirt so it will fix the MAC address to 
always start with FE:xx:... This will prevent the bridge to change 
its address when the interface joins in the bridge.

fbl

--- Additional comment from nachandr on 2010-04-15 16:04:51 EDT ---

Changing 'Description of problem' to:
libvirt uses the MAC address assigned to tap devices/vnet interfaces by the
TAP/TUN driver.

Changing 'Actual results' to:
libvirt uses the MAC address assigned to tap devices/vnet interfaces by the
TAP/TUN driver.

Changing 'Expected results' to:
libvirt should ignore the MAC address assigned to tap devices/vnet interfaces
by the TAP/TUN driver and assign MAC address in the upper range(starting with
FE:xx) to tap devices.

Comment 1 Andreas Rogge 2010-06-23 13:35:40 UTC
And news on this issue or a rough estimate when this will be fixed?

Comment 2 Andreas Rogge 2010-06-24 08:14:15 UTC
Created attachment 426481 [details]
Flavio Leitner's patch adapted fpr RHEL's incarnation of libvirt 0.6.3

I tried to patch libvirt myself - it didn't work because src/bridge.c seems to be  patched quite a lot in RHEL 5.5

This patch now works if added as additional patch to libvirt-0.6.3-33.el5.

I rebuilt the libvirt rpms and tried them on our new bunch of Dell PE R710. The on-board NICs in these boxes have Dell branded MACs with an OUI of b8:ac:6f which always triggers the issue.

I can confirm that this patch actually solves the issue.

Comment 3 Daniel Berrangé 2010-07-06 15:01:50 UTC

*** This bug has been marked as a duplicate of bug 571991 ***

Comment 4 olaf 2010-07-12 19:52:37 UTC
Thank you, Andreas. It saved my life :)

This patch fixes bug #611838


Note You need to log in before you can comment on or make changes to this bug.