+++ 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.
And news on this issue or a rough estimate when this will be fixed?
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.
*** This bug has been marked as a duplicate of bug 571991 ***
Thank you, Andreas. It saved my life :) This patch fixes bug #611838