[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: agr(4) + bridge(4): problems!
On 09/27/12 13:40, Thor Lancelot Simon wrote:
On Thu, Sep 27, 2012 at 12:59:30PM +0100, Hugo Silva wrote:
On the host system, ifconfig.agr0 looks like:
inet xxx.xxx.xxx.xxx netmask 255.255.255.0
You don't say which interface you added to the bridge. I assume it's
agr0, not wm1 nor wm4.
What you may be seeing is an inherent asymmetry of agr in our kernel.
Unless some other interface is stacked on top of the agr, there's really
no reason for packets to be fed to the agr's input routine rather than
passed directly from the underlying hardware's input routine to the
network-layer protocol input routine (usually but not always ip_input).
So -- unless things have changed since last I looked -- that's exactly
what is done. Packets go _out_ the agr, but they come _in_ the wm
interfaces. If you attach tcpdump to the agr you may miss all inbound
traffic, and the bridge likely does too.
Even in the case of vlan-on-agr, since most network hardware supports
vlan decapsulation directly it is probably the case that the agr input
routine is bypassed. Unless my head's gone completely wrong this
morning and I'm thinking of a different kernel.
Ah, I had some hope for VLANs as the configuration with the new switches
will include them.
I have blind-carboned in a former coworker who may remember the awful
details of this better than I do.
But I suspect you're going to have to whack the agr code so that it
tells the underlying interfaces to feed input packets to the bridge, if
one is configured, as well as putting them in promiscuous mode so the
bridge can work at all, or the bridge will never see the packets on
input and this will just never work. It's a matter of arranging for
the ioctls to flow up and down the stack properly and for the right
thing to happen at the right layer in each case, which for agr input
will be at the physical network interface, not at the agr.
I surely can spend some hours around this, but my C skills are not that
Yamt@ (author of agr(4)) is cc'd, but at any rate could you explain a
bit more about this? How would I "tell the underlying interfaces to feed
input packets to the bridge if one is configured", and which files are
likely to need editing ?
The duplicate address business is because you need to up the interface,
then delete its accursed autoconfigured IPv6 address, before you add it
to the agr
Oh no, I mean in the domU - it detects a duplicate in the network, but
in reality it's detecting itself - something weird's happening and it's
related to agr(4), presumably also to the fact that the domU MAC appears
twice on brconfig bridge0 output (I've since converted the machine to
just use wm1 as I'm running tests on the VMs, so I can't be sure, but
from memory I think each duplicate appeared on each agrport interface)
as presently the VMs are running under bridge0 (wm1) and that issue
Main Index |
Thread Index |