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
