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

Stefan Priebe - Profihost AG s.priebe at profihost.ag
Tue Feb 12 08:48:33 CET 2013


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