Re: agr(4) + bridge(4): problems!

[Hugo Silva <hugo%barafranca.com@localhost>]

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:
> >
> > create
> > link1
> > agrport wm1
> > agrport wm4
> > up
> > 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.

Yes, agr0.

> 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 
good.

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 
isn't present.