Help with bugfix for bond active-backup mode + vlans

Help with bugfix for bond active-backup mode + vlans

[Christophe Devriese]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

First, in order to have correct behavior, it needs to be possible for the 
bonding driver to block packet reception on certain interfaces (in order, for 
example, to prevent the linux bridge from circular learning*). 

This needs to work both in the normal input path ( _receive_skb, netif_rx, ... 
in net/core/dev.c) and in the vlan input path (which changes the ->dev 
reference on the packets it's forwarding, which seriously complicates things, 
the vlan input path is located in include/linux/if_vlan __vlan_hwaccel_rx)

Would it be acceptable to have an interface flag IFF_SILENT that can be set on 
an interface, which prevents it from receiving packets in both forwarding 
paths ?

If not, how do I fix this issue ?

Cheers,

oelewapperke

* circular learning : see attachment 1 & 2
after the packet has travelled on the external switches, the mac address entry 
in the linux bridge for the domU's eth0 will point to the link where it last 
saw a packet with that source address, which is bond0. This prevents packet 
reception totally for the domU. (the bond0 is running in active_backup mode)

[-- Attachment #2: layout.png --]
[-- Type: image/png, Size: 18364 bytes --]

[-- Attachment #3: problempacket.png --]
[-- Type: image/png, Size: 27804 bytes --]

Re: Help with bugfix for bond active-backup mode + vlans

[Jay Vosburgh]

Christophe Devriese <Christophe.Devriese@eurid.eu> wrote:

[...]
>Would it be acceptable to have an interface flag IFF_SILENT that can be set on 
>an interface, which prevents it from receiving packets in both forwarding 
>paths ?

	Starting with kernel version 2.6.17, there is code in skb_bond()
to suppress traffic on inactive slaves, but it looks like that will
bypassed by hardware accelerated VLAN packets (which, if I'm reading the
code correctly, have their skb->dev directly assigned to the VLAN
interface, so they go into netif_receive_skb with skb->dev not set to
the slave device, which will bypass the stuff in skb_bond).

	An IFF_SILENT type of flag would work fine (if checked in both
input paths) for the active-backup mode, but the 802.3ad and balance-alb
modes need differing types of traffic dropping, e.g., the balance-alb
mode just needs to suppress broadcast and multicasts.

	One possible solution for this would be to have bonding remove
the vlan registration for inactive slaves, which would cause the errant
packets to pass through skb_bond() normally and presumably be dropped.
That would work for the active-backup case, but would cause balance-alb
mode to lose VLAN acceleration on all interfaces except for one.

	Another possibility would be to have __vlan_hwaccel_rx check the
VLAN_DEV_INFO(skb->dev)->real_dev, and if that's a bonding device, apply
the same logic found in skb_bond().  Or, if there's some way to ask the
question "is dev a VLAN device?", then that same test could be put into
skb_bond() and all of the packet suppression fru fru could stay there.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: Help with bugfix for bond active-backup mode + vlans

[Ben Greear]

Jay Vosburgh wrote:

> 	Another possibility would be to have __vlan_hwaccel_rx check the
> VLAN_DEV_INFO(skb->dev)->real_dev, and if that's a bonding device, apply
> the same logic found in skb_bond().  Or, if there's some way to ask the
> question "is dev a VLAN device?", then that same test could be put into
> skb_bond() and all of the packet suppression fru fru could stay there.

There is a flag in if.h to denote VLAN devices:

/* Private (from user) interface flags (netdevice->priv_flags). */
#define IFF_802_1Q_VLAN 0x1             /* 802.1Q VLAN device.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Help with bugfix for bond active-backup mode + vlans

[Jay Vosburgh]

Ben Greear <greearb@candelatech.com> wrote:

>Jay Vosburgh wrote:
>
>> 	Another possibility would be to have __vlan_hwaccel_rx check the
>> VLAN_DEV_INFO(skb->dev)->real_dev, and if that's a bonding device, apply
>> the same logic found in skb_bond().  Or, if there's some way to ask the
>> question "is dev a VLAN device?", then that same test could be put into
>> skb_bond() and all of the packet suppression fru fru could stay there.
>
>There is a flag in if.h to denote VLAN devices:

	Thanks, I missed that.

	Sadly, elegance remains elusive, since the by the time skb_bond
is called, the slave device the packet arrived on isn't available
(vlan->real_dev points to 'bond0' by this point), and that information
is needed to decide whether to drop the packet or not.

	The least grotty solution that comes to mind is to have
__vlan_hwaccel_rx call some skb_bond_suppress_dups() function directly,
and change skb_bond() to also call that function.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: Help with bugfix for bond active-backup mode + vlans

[Ben Greear]

Jay Vosburgh wrote:
> Ben Greear <greearb@candelatech.com> wrote:
> 
> 
>>Jay Vosburgh wrote:
>>
>>
>>>	Another possibility would be to have __vlan_hwaccel_rx check the
>>>VLAN_DEV_INFO(skb->dev)->real_dev, and if that's a bonding device, apply
>>>the same logic found in skb_bond().  Or, if there's some way to ask the
>>>question "is dev a VLAN device?", then that same test could be put into
>>>skb_bond() and all of the packet suppression fru fru could stay there.
>>
>>There is a flag in if.h to denote VLAN devices:
> 
> 
> 	Thanks, I missed that.
> 
> 	Sadly, elegance remains elusive, since the by the time skb_bond
> is called, the slave device the packet arrived on isn't available
> (vlan->real_dev points to 'bond0' by this point), and that information
> is needed to decide whether to drop the packet or not.
> 
> 	The least grotty solution that comes to mind is to have
> __vlan_hwaccel_rx call some skb_bond_suppress_dups() function directly,
> and change skb_bond() to also call that function.

Can you use skb->input_dev?

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Help with bugfix for bond active-backup mode + vlans

[Jay Vosburgh]

Ben Greear <greearb@candelatech.com> wrote:

>Jay Vosburgh wrote:
>> 	Sadly, elegance remains elusive, since the by the time skb_bond
>> is called, the slave device the packet arrived on isn't available
>> (vlan->real_dev points to 'bond0' by this point), and that information
>> is needed to decide whether to drop the packet or not.
>> 	The least grotty solution that comes to mind is to have
>> __vlan_hwaccel_rx call some skb_bond_suppress_dups() function directly,
>> and change skb_bond() to also call that function.
>
>Can you use skb->input_dev?

	Not as it is currently implemented.  It is set by
netif_receive_skb, not by the vlan accelerator, so input_dev ends up
being the vlan device, not the underlying actual ethernet device.  It
looks like input_dev will be inconsistently assigned with vlans over
bonding: if the slave device is vlan accelerated, input_dev will be the
vlan device; if the slave isn't accelerated, input_dev will be the
slave.

	As far as I can tell, the input_dev is only used by the
NET_CLS_IND (input device classification) stuff, which has warnings
saying it might be going away.  I'm not seeing anything else right
offhand that uses it.

	Anyway, the skb_bond logic really needs the enslaved interface,
which isn't necessarily the input_dev (even if input_dev was always the
device that actually had the wire plugged into it).  If the slave is
itself some kind of virtual device (a vlan, for example), then input_dev
wouldn't be the right thing.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com