* Re: [Bugme-new] [Bug 25062] New: Bonding packet deduplication doesn't work properly anymore [not found] <bug-25062-10286@https.bugzilla.kernel.org/> @ 2011-01-04 21:39 ` Andrew Morton 2011-01-07 2:47 ` Jay Vosburgh 0 siblings, 1 reply; 2+ messages in thread From: Andrew Morton @ 2011-01-04 21:39 UTC (permalink / raw) To: netdev Cc: bugzilla-daemon, bugme-new, bugme-daemon, Jay Vosburgh, kevin.lapagna (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Fri, 17 Dec 2010 11:45:18 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=25062 > > Summary: Bonding packet deduplication doesn't work properly > anymore > Product: Networking > Version: 2.5 > Kernel Version: > 2.6.33 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: Other > AssignedTo: acme@ghostprotocols.net > ReportedBy: kevin.lapagna@bigtag.ch > Regression: No > > > Here's the setup: > > switch: ordinary cisco switch > eth0: NIC with kernel module tg3 > eth1: NIC with kernel module e1000e > bond0: bond with slaves eth0,eth1 in mode 1 (or 5) > bond0.100: vlan device created with vconfig > bridge100: bridge created with brctl > tap1: tap device created with tunctl > vguest: qemu-kvm vguest whit emulated e1000 NIC > > > |________________|-- eth0 \ |________________| > | switch | -- bond0 -- bond0.100 -- bridge100 -- tap1 -- | vguest | > |________|-- eth1 / |________| > > When the vguest emits an ethernet broadcast (DHCP-request), it's forwarded all > the way up to the switch, through eth0. The switch forwards the broadcast - > also to eth1. The packet travels then all the way back to bridge100. So the > last status known for bridge100, regarding the mac address of the vgeust is, > that it is behind bond0.110 (instead of tap1). If a DHCP-server responds to the > request, the packet travels to bridge100, which has now a faulty > MAC-address-table and the packet will be rejected and never reaches tap1 and > therefor not the vguest. > > I witnessed this wrong behavior in kernel 2.6.37-rc5 (debian package), 2.6.36.2 > and 2.6.35.9 (self compiled - vanilla). The setup has worked with kernels <= > 2.6.33.7. I've never tried 2.6.34. > > I assume the setup above is a common way for the separation of virtual guests > on a network level. So this could become a major issue for a lot of people when > upgrading their kernels. > ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Bugme-new] [Bug 25062] New: Bonding packet deduplication doesn't work properly anymore 2011-01-04 21:39 ` [Bugme-new] [Bug 25062] New: Bonding packet deduplication doesn't work properly anymore Andrew Morton @ 2011-01-07 2:47 ` Jay Vosburgh 0 siblings, 0 replies; 2+ messages in thread From: Jay Vosburgh @ 2011-01-07 2:47 UTC (permalink / raw) To: Andrew Morton Cc: netdev, bugzilla-daemon, bugme-new, bugme-daemon, kevin.lapagna Andrew Morton <akpm@linux-foundation.org> wrote: >On Fri, 17 Dec 2010 11:45:18 GMT >bugzilla-daemon@bugzilla.kernel.org wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=25062 >> >> Summary: Bonding packet deduplication doesn't work properly >> anymore >> Product: Networking >> Version: 2.5 >> Kernel Version: > 2.6.33 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: high >> Priority: P1 >> Component: Other >> AssignedTo: acme@ghostprotocols.net >> ReportedBy: kevin.lapagna@bigtag.ch >> Regression: No >> >> >> Here's the setup: >> >> switch: ordinary cisco switch >> eth0: NIC with kernel module tg3 >> eth1: NIC with kernel module e1000e >> bond0: bond with slaves eth0,eth1 in mode 1 (or 5) >> bond0.100: vlan device created with vconfig >> bridge100: bridge created with brctl >> tap1: tap device created with tunctl >> vguest: qemu-kvm vguest whit emulated e1000 NIC >> >> >> |________________|-- eth0 \ |________________| >> | switch | -- bond0 -- bond0.100 -- bridge100 -- tap1 -- | vguest | >> |________|-- eth1 / |________| >> >> When the vguest emits an ethernet broadcast (DHCP-request), it's forwarded all >> the way up to the switch, through eth0. The switch forwards the broadcast - >> also to eth1. The packet travels then all the way back to bridge100. So the >> last status known for bridge100, regarding the mac address of the vgeust is, >> that it is behind bond0.110 (instead of tap1). If a DHCP-server responds to the >> request, the packet travels to bridge100, which has now a faulty >> MAC-address-table and the packet will be rejected and never reaches tap1 and >> therefor not the vguest. >> >> I witnessed this wrong behavior in kernel 2.6.37-rc5 (debian package), 2.6.36.2 >> and 2.6.35.9 (self compiled - vanilla). The setup has worked with kernels <= >> 2.6.33.7. I've never tried 2.6.34. >> >> I assume the setup above is a common way for the separation of virtual guests >> on a network level. So this could become a major issue for a lot of people when >> upgrading their kernels. Just a note that I have reproduced what I believe is the same problem (I didn't use tap, and assigned an IP to the bridge). I used arping to generate ethernet broadcasts. I see the problem on 2.6.36.2, but not on today's net-next-2.6. I'll see if I can dig up the root cause tomorrow. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-01-07 2:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <bug-25062-10286@https.bugzilla.kernel.org/>
2011-01-04 21:39 ` [Bugme-new] [Bug 25062] New: Bonding packet deduplication doesn't work properly anymore Andrew Morton
2011-01-07 2:47 ` Jay Vosburgh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.