Re: bond interface arp, vlan and trunk / network question

[Jay Vosburgh <fubar@us.ibm.com>]

stefan novak <lms.brubaker@gmail.com> wrote:

>ip route get 172.21.0.254
>172.21.0.254 dev bond0.600  src 172.21.0.1
>    cache  mtu 1500 advmss 1460 hoplimit 64
>
>ifconfig -a :
>bond0     Link encap:Ethernet  HWaddr 00:30:48:94:7D:1A
>          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>          RX packets:62221072 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:1152153 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:4037489679 (3.7 GiB)  TX bytes:124861822 (119.0 MiB)
>
>bond0.200 Link encap:Ethernet  HWaddr 00:30:48:94:7D:1A
>          inet addr:172.22.0.1  Bcast:172.22.0.255  Mask:255.255.255.0
>          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:250 (250.0 b)  TX bytes:252 (252.0 b)
>
>bond0.500 Link encap:Ethernet  HWaddr 00:30:48:94:7D:1A
>          inet addr:172.20.0.1  Bcast:172.20.0.255  Mask:255.255.255.0
>          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>          RX packets:26448 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:33570 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:6278388 (5.9 MiB)  TX bytes:6429404 (6.1 MiB)
>
>bond0.600 Link encap:Ethernet  HWaddr 00:30:48:94:7D:1A
>          inet addr:172.21.0.1  Bcast:172.21.0.255  Mask:255.255.255.0
>          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>          RX packets:1911 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:8665 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:98604 (96.2 KiB)  TX bytes:1208395 (1.1 MiB)
>
>eth0      Link encap:Ethernet  HWaddr 00:30:48:94:7D:1A
>          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
>          RX packets:881723 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:1074651 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:108550619 (103.5 MiB)  TX bytes:115574099 (110.2 MiB)
>          Memory:f8220000-f8240000
>
>eth1      Link encap:Ethernet  HWaddr 00:30:48:94:7D:1A
>          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
>          RX packets:61339352 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:77510 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:3928939240 (3.6 GiB)  TX bytes:9290795 (8.8 MiB)
>          Memory:f8260000-f8280000
>
>lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1
>          RX packets:105468 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:105468 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:7016087 (6.6 MiB)  TX bytes:7016087 (6.6 MiB)

	This looks pretty much as expected.

[...]
>>        There's no "self test" or anything like that, if that's what you
>> mean.  If the ARPs work (make the round trip) the link is up, if they
>> don't, the link is down.  That's subject to some details related to
>> arp_validate, but is basically it.
>
>Ok. my interfaces are now up with arp_validate set to 0/none.
>Everything works as expected, thank you.
>But with arp_validate set to all the interfaces are always down. :(
>I think that i have to use the all option because i have many servers
>in that vlan?

	Well, you'll probably want to run with arp_validate, otherwise
the probe traffic can fool the arp monitor into thinking the path is up
when it isn't.

	But...

	I know what your problem with arp_validate is, though, and it's
something I've been working on as time permits (and forgot to mention
previously).  Basically, the VLAN receive path assigns the VLAN device
to the received packet before doing receive processing on it, so the
"slave" identity is lost before the bonding ARP receive function looks
at it, so it never counts the ARP (for validate purposes).

	I've been chewing on the least bad way to fix this, mostly
trying to figure out if its possible to resolve without adding a hook
into bonding that basically replaces and extends skb_bond_should_drop
(which does work, it's just not very elegant).

	-J

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