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:[email protected]] >>> Sent: Dienstag, 12. Februar 2013 08:49 >>> To: Alexandre DERUMIER >>> Cc: [email protected]; 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@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" <[email protected]> >>>> À: "Alexandre DERUMIER" <[email protected]> >>>> Cc: [email protected], "Dietmar Maurer" >>> <[email protected]> >>>> 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" <[email protected]> >>>>> À: "Alexandre DERUMIER" <[email protected]> >>>>> Cc: [email protected], "Dietmar Maurer" >>> <[email protected]> >>>>> 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 >>> <[email protected]>: >>>>> >>>>>> 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" <[email protected]> >>>>>> À: "Dietmar Maurer" <[email protected]> >>>>>> Cc: "Alexandre DERUMIER" <[email protected]>, >>>>>> [email protected] >>>>>> 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:[email protected]] >>>>>>>> Sent: Freitag, 08. Februar 2013 08:12 >>>>>>>> To: Stefan Priebe; Dietmar Maurer >>>>>>>> Cc: [email protected] >>>>>>>> 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 >>>>>>> >>>>>>> >> _______________________________________________ pve-devel mailing list [email protected] http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
