[pve-devel] new bridge code doesn't work with redhat kernel
Stefan Priebe - Profihost AG
s.priebe at profihost.ag
Tue Feb 12 09:15:07 CET 2013
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