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
