[pve-devel] new bridge code doesn't work with redhat kernel

Stefan Priebe - Profihost AG s.priebe at profihost.ag
Tue Feb 12 09:34:36 CET 2013


Hi Dietmar,

thanks for pointing me to the idea the ethernet driver could be the problem.

I now updated to latest igb driver and it starts to work fine *GR*... i
never imagined that this could be the problem.

Stefan
Am 12.02.2013 09:15, schrieb Stefan Priebe - Profihost AG:
> Hi,
> 
> i got it working by enabling promisc mode on eth0 and eth1 - but could
> this be correct? Is this really needed?
> 
> Stefan
> Am 12.02.2013 08:54, schrieb Dietmar Maurer:
>> What kind of network card do you have? Maybe related to the new Broadcom driver?
>>
>>> -----Original Message-----
>>> From: Stefan Priebe - Profihost AG [mailto:s.priebe at profihost.ag]
>>> Sent: Dienstag, 12. Februar 2013 08:49
>>> To: Alexandre DERUMIER
>>> Cc: pve-devel at pve.proxmox.com; Dietmar Maurer
>>> Subject: Re: [pve-devel] new bridge code doesn't work with redhat kernel
>>>
>>> Hi Alexandre,
>>>
>>> i've the SAME problem but even without a VLAN involved at all if i use bond
>>> mode 802.3ad. Then i strangely see ALL traffic of all interfaces attached to
>>> the bond on the TAP device...
>>>
>>> Stefan
>>>
>>> Am 12.02.2013 08:45, schrieb Alexandre DERUMIER:
>>>>
>>>> I have done some tshark traces,
>>>>
>>>> with dedicated bridge for the vms.
>>>> (I have put my admin vlan on a separate nic).
>>>> I can't get it work.
>>>>
>>>> config is
>>>> ---------
>>>> auto bond0
>>>> iface bond0 inet manual
>>>> slaves eth0 eth1
>>>> bond_miimon 100
>>>> bond_mode active-backup
>>>> pre-up ifup eth0 eth1
>>>> post-down ifdown eth0 eth1
>>>>
>>>> auto vmbr1
>>>> iface vmbr1 inet manual
>>>>         bridge_ports bond0
>>>>         bridge_stp off
>>>>         bridge_fd 0
>>>>
>>>>
>>>> now I start a vm in vlan95 with vmbr1 (ip address: 10.3.95.241)
>>>>
>>>> root at kvmtest1:~# brctl show
>>>> bridge name	bridge id		STP enabled	interfaces
>>>> vmbr1		8000.001aa03c98c5	no
>>>> vmbr1v95	8000.001aa03c98c5	no		tap115i0
>>>> 							vmbr1.95
>>>>
>>>>
>>>> I can't ping the vm from outside world,
>>>>
>>>> I see arp request from the vm on vmbr1v95 and vmbr1. (but not on
>>>> bond0) But no response
>>>>
>>>>
>>>> # tshark -i vmbr1
>>>> Running as user "root" and group "root". This could be dangerous.
>>>> Capturing on vmbr1
>>>>   0.000000 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>   1.000577 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>   1.924068 fe80::8c3e:2cff:fefa:88c8 -> ff02::2      ICMPv6 Router solicitation
>>>>   2.000673 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>   5.005467 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>   5.931900 fe80::8c3e:2cff:fefa:88c8 -> ff02::2      ICMPv6 Router solicitation
>>>>   6.003867 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>   7.003908 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  10.010779 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  11.007851 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  12.007901 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  15.016168 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  16.015875 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  17.015859 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  18.085844 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>>  19.083953 8e:3e:2c:fa:88:c8 -> Broadcast    ARP Who has 10.3.95.1?  Tell
>>> 10.3.95.241
>>>> ^C16 packets captured
>>>>
>>>>
>>>>
>>>> on bond0, I can see arp request from cisco switchs, but no reponse
>>>> from the vm
>>>>
>>>> Running as user "root" and group "root". This could be dangerous.
>>>> Capturing on bond0
>>>>   4.746062 Cisco_bd:ae:40 -> Broadcast    ARP Who has 10.3.95.241?  Tell
>>> 10.3.95.1
>>>>   5.647504 Cisco_bd:ae:40 -> Broadcast    ARP Who has 10.3.95.241?  Tell
>>> 10.3.95.1
>>>>   6.745705 Cisco_bd:ae:40 -> Broadcast    ARP Who has 10.3.95.241?  Tell
>>> 10.3.95.1
>>>>   7.745565 Cisco_bd:ae:40 -> Broadcast    ARP Who has 10.3.95.241?  Tell
>>> 10.3.95.1
>>>>  11.744866 Cisco_bd:ae:40 -> Broadcast    ARP Who has 10.3.95.241?  Tell
>>> 10.3.95.1
>>>>
>>>>
>>>> So, something is wrong between bond0 and vmbr1.
>>>> (Maybe the vlans tags ? I don't know how to trace the vlan tag with
>>>> tshark, any idea ?)
>>>>
>>>> So maybe my firsts tests was working because of arp cache.
>>>>
>>>>
>>>>
>>>>
>>>> ----- Mail original -----
>>>>
>>>> De: "Stefan Priebe" <s.priebe at profihost.ag>
>>>> À: "Alexandre DERUMIER" <aderumier at odiso.com>
>>>> Cc: pve-devel at pve.proxmox.com, "Dietmar Maurer"
>>> <dietmar at proxmox.com>
>>>> Envoyé: Lundi 11 Février 2013 20:44:28
>>>> Objet: Re: [pve-devel] new bridge code doesn't work with redhat kernel
>>>>
>>>> HI,
>>>>
>>>> right now i'm talking about bridge on top of a bond NO VLAN involved.
>>>> My commit / code change does not even touch that...
>>>>
>>>> Could you please check? As far as i know this is working for you - isn't it?
>>>>
>>>> Stefan
>>>>
>>>> Am 11.02.2013 17:40, schrieb Alexandre DERUMIER:
>>>>> Mmmm, this is strange, I have just retested after reboot my test
>>>>> server,
>>>>>
>>>>> it doesn't work anymore too with new bridge code.
>>>>>
>>>>> (maybe an arp problem ?)
>>>>>
>>>>> I'm a bit scaried....
>>>>>
>>>>>
>>>>> ----- Mail original -----
>>>>>
>>>>> De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag>
>>>>> À: "Alexandre DERUMIER" <aderumier at odiso.com>
>>>>> Cc: pve-devel at pve.proxmox.com, "Dietmar Maurer"
>>> <dietmar at proxmox.com>
>>>>> Envoyé: Lundi 11 Février 2013 17:28:34
>>>>> Objet: Re: [pve-devel] new bridge code doesn't work with redhat
>>>>> kernel
>>>>>
>>>>> And how does you bridge look like? To me the tap devices attached to the
>>> bridge don't work at all.
>>>>>
>>>>> Stefan
>>>>>
>>>>> Am 11.02.2013 um 17:16 schrieb Alexandre DERUMIER
>>> <aderumier at odiso.com>:
>>>>>
>>>>>> Hi stefan, this is working for my with theses bond configs
>>>>>>
>>>>>> active-backup
>>>>>> --------------
>>>>>> auto bond0
>>>>>> iface bond0 inet manual
>>>>>> slaves eth0 eth1
>>>>>> bond_miimon 100
>>>>>> bond_mode active-backup
>>>>>> pre-up ifup eth0 eth1
>>>>>> post-down ifdown eth0 eth1
>>>>>>
>>>>>>
>>>>>> or lacp
>>>>>> -------
>>>>>> auto bond1
>>>>>> iface bond1 inet manual
>>>>>> bond-mode 4
>>>>>> bond-miimon 100
>>>>>> bond-lacp_rate fast
>>>>>> bond-xmit-hash-policy layer2+3
>>>>>> slaves eth0 eth1
>>>>>>
>>>>>>
>>>>>> ----- Mail original -----
>>>>>>
>>>>>> De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag>
>>>>>> À: "Dietmar Maurer" <dietmar at proxmox.com>
>>>>>> Cc: "Alexandre DERUMIER" <aderumier at odiso.com>,
>>>>>> pve-devel at pve.proxmox.com
>>>>>> Envoyé: Lundi 11 Février 2013 16:40:13
>>>>>> Objet: Re: [pve-devel] new bridge code doesn't work with redhat
>>>>>> kernel
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> please wait a bit i'll contact Patrick in a few minutes as i wanted
>>>>>> to switch to bonding today and it stops working again.
>>>>>>
>>>>>> Let's see how a real solution would look like. Right now i've the
>>>>>> same problem as alexandre that the VM is not reachable at all when
>>> using bond.
>>>>>>
>>>>>> Alexandre maybe you can tell me how you got your bonding working?
>>>>>>
>>>>>> My interfaces:
>>>>>>
>>>>>> auto bond0
>>>>>> iface bond0 inet manual
>>>>>> slaves eth0 eth1
>>>>>> bond_mode 802.3ad
>>>>>> bond_miimon 100
>>>>>> bond_updelay 200
>>>>>> bond_downdelay 10
>>>>>>
>>>>>> auto vmbr0
>>>>>> iface vmbr0 inet manual
>>>>>> bridge_ports bond0
>>>>>> bridge_stp off
>>>>>> bridge_fd 0
>>>>>>
>>>>>> But this results in no IP communication for the VM - even without
>>>>>> using any vlans.
>>>>>>
>>>>>> Stefan
>>>>>> Am 11.02.2013 09:42, schrieb Dietmar Maurer:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alexandre DERUMIER [mailto:aderumier at odiso.com]
>>>>>>>> Sent: Freitag, 08. Februar 2013 08:12
>>>>>>>> To: Stefan Priebe; Dietmar Maurer
>>>>>>>> Cc: pve-devel at pve.proxmox.com
>>>>>>>> Subject: Re: [pve-devel] new bridge code doesn't work with redhat
>>>>>>>> kernel
>>>>>>>>
>>>>>>>> Hi Stefan, Thanks it's working ! (I have not aware of vlan-raw-device
>>> syntax).
>>>>>>>>
>>>>>>>> Based of this, I have a better setup, putting ip addresse on vlan
>>>>>>>> interface, and not on a bridge.
>>>>>>>> So it's a small change.
>>>>>>>>
>>>>>>>> But I really think this change should not go in stable pve repo
>>>>>>>> before a big release like proxmox 2.3.
>>>>>>>> As It ll require reboot of the host to have clean bridges without
>>>>>>>> mix of tagged interfaces and tagged bridges interfaces.
>>>>>>>
>>>>>>> 2.3 release is the next release planned end of February. There is a
>>>>>>> new kernel, and a new kvm (1.4, including new backup code), so we
>>> need to recommend a reboot anyways.
>>>>>>>
>>>>>>> Here is a list of advantages and disadvantages:
>>>>>>>
>>>>>>> new code:
>>>>>>>
>>>>>>> + works with any number of physical interfaces works with gvrp
>>>>>>> - only tested by a few people
>>>>>>> - not fully compatible with existing vlan setup
>>>>>>>
>>>>>>> old code:
>>>>>>>
>>>>>>> + works well for many users
>>>>>>> + also used by RHEV/libvirt
>>>>>>> - needs exactly one physical interface (should also work with 0
>>>>>>> physical interfaces)
>>>>>>> - gvrp does not work (https://lkml.org/lkml/2013/2/7/107)
>>>>>>> + can use vlan hardware support (better performance?)
>>>>>>>
>>>>>>>
>>>>>>> Seems GVRP is a rarely used feature, because it is very dangerous
>>> security wise.
>>>>>>>
>>>>>>> So what is your opinion:
>>>>>>>
>>>>>>> A.) keep old VLAN code (revert change)
>>>>>>> B.) use new VLAN code
>>>>>>>
>>>>>>> Please can we vote on that? Also include a short explanation why you
>>> prefer something.
>>>>>>>
>>>>>>> - Dietmar
>>>>>>>
>>>>>>>
>>



More information about the pve-devel mailing list