* VLANs, bonding redux: vlan state does not follow ethernet
@ 2010-05-22 6:24 George B.
2010-05-22 6:45 ` George B.
0 siblings, 1 reply; 4+ messages in thread
From: George B. @ 2010-05-22 6:24 UTC (permalink / raw)
To: netdev
Using 2.6.34 I am trying to remove bottlenecks. Instead of bonding
two ethernet interfaces and applying vlans to the bond, I am applying
the vlans to the ethernet and bonding the vlans creating a separate
bond interface for each vlan.
The trouble now is that the bond interface does not see when the
ethernet interface goes down. The vlan reports to the bonding driver
that it is up when the ethernet it is connected to is down. This
results in packet loss through the bond interface as the bond driver
attempts to use that vlan.
eth1 shows having no link:
root@sandbox:/proc/net# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: Not reported
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbag
Wake-on: g
Current message level: 0x00000001 (1)
Link detected: no
bonding driver says eth1.99 reports MII status up:
root@sandbox:/proc/net# cat bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0.99
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:26:9e:1c:d3:3e
Slave Interface: eth1.99
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:26:9e:1c:d3:3f
is there some parameter I can give that tells the vlan driver to
follow the state of the interface it is attached to? Having a vlan
that reports being up all the time even when its underlying interface
is down is less than useful. It would seem intuitive that a vlan's
state would follow that of the interface it is attached to.
root@sandbox:/proc/net# cat vlan/eth0.99
eth0.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
total frames received 32
total bytes received 4735
Broadcast/Multicast Rcvd 0
total frames transmitted 50
total bytes transmitted 3852
total headroom inc 0
total encap on xmit 0
Device: eth0
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings:
root@sandbox:/proc/net# cat vlan/eth1.99
eth1.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
total frames received 0
total bytes received 0
Broadcast/Multicast Rcvd 0
total frames transmitted 0
total bytes transmitted 0
total headroom inc 0
total encap on xmit 0
Device: eth1
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings:
root@sandbox:/proc/net# ping 10.1.99.1
PING 10.1.99.1 (10.1.99.1) 56(84) bytes of data.
64 bytes from 10.1.99.1: icmp_seq=2 ttl=255 time=0.299 ms
64 bytes from 10.1.99.1: icmp_seq=4 ttl=255 time=0.311 ms
64 bytes from 10.1.99.1: icmp_seq=6 ttl=255 time=0.325 ms
64 bytes from 10.1.99.1: icmp_seq=8 ttl=255 time=0.291 ms
64 bytes from 10.1.99.1: icmp_seq=10 ttl=255 time=0.308 ms
George
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: VLANs, bonding redux: vlan state does not follow ethernet
2010-05-22 6:24 VLANs, bonding redux: vlan state does not follow ethernet George B.
@ 2010-05-22 6:45 ` George B.
2010-05-22 17:47 ` George B.
0 siblings, 1 reply; 4+ messages in thread
From: George B. @ 2010-05-22 6:45 UTC (permalink / raw)
To: netdev
On Fri, May 21, 2010 at 11:24 PM, George B. <georgeb@gmail.com> wrote:
> Using 2.6.34 I am trying to remove bottlenecks. Instead of bonding
> two ethernet interfaces and applying vlans to the bond, I am applying
> the vlans to the ethernet and bonding the vlans creating a separate
> bond interface for each vlan.
>
> The trouble now is that the bond interface does not see when the
> ethernet interface goes down. The vlan reports to the bonding driver
> that it is up when the ethernet it is connected to is down. This
> results in packet loss through the bond interface as the bond driver
> attempts to use that vlan.
>
> eth1 shows having no link:
>
> root@sandbox:/proc/net# ethtool eth1
> Settings for eth1:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Link partner advertised link modes: Not reported
> Link partner advertised pause frame use: No
> Link partner advertised auto-negotiation: No
> Speed: Unknown!
> Duplex: Unknown! (255)
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: Unknown
> Supports Wake-on: pumbag
> Wake-on: g
> Current message level: 0x00000001 (1)
> Link detected: no
>
> bonding driver says eth1.99 reports MII status up:
>
> root@sandbox:/proc/net# cat bonding/bond0
> Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
>
> Bonding Mode: load balancing (round-robin)
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
>
> Slave Interface: eth0.99
> MII Status: up
> Link Failure Count: 0
> Permanent HW addr: 00:26:9e:1c:d3:3e
>
> Slave Interface: eth1.99
> MII Status: up
> Link Failure Count: 0
> Permanent HW addr: 00:26:9e:1c:d3:3f
>
> is there some parameter I can give that tells the vlan driver to
> follow the state of the interface it is attached to? Having a vlan
> that reports being up all the time even when its underlying interface
> is down is less than useful. It would seem intuitive that a vlan's
> state would follow that of the interface it is attached to.
>
> root@sandbox:/proc/net# cat vlan/eth0.99
> eth0.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
> total frames received 32
> total bytes received 4735
> Broadcast/Multicast Rcvd 0
>
> total frames transmitted 50
> total bytes transmitted 3852
> total headroom inc 0
> total encap on xmit 0
> Device: eth0
> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
> EGRESS priority mappings:
> root@sandbox:/proc/net# cat vlan/eth1.99
> eth1.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
> total frames received 0
> total bytes received 0
> Broadcast/Multicast Rcvd 0
>
> total frames transmitted 0
> total bytes transmitted 0
> total headroom inc 0
> total encap on xmit 0
> Device: eth1
> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
> EGRESS priority mappings:
>
> root@sandbox:/proc/net# ping 10.1.99.1
> PING 10.1.99.1 (10.1.99.1) 56(84) bytes of data.
> 64 bytes from 10.1.99.1: icmp_seq=2 ttl=255 time=0.299 ms
> 64 bytes from 10.1.99.1: icmp_seq=4 ttl=255 time=0.311 ms
> 64 bytes from 10.1.99.1: icmp_seq=6 ttl=255 time=0.325 ms
> 64 bytes from 10.1.99.1: icmp_seq=8 ttl=255 time=0.291 ms
> 64 bytes from 10.1.99.1: icmp_seq=10 ttl=255 time=0.308 ms
>
> George
>
But interestingly, mii-tool reports the correct result:
root@sandbox:/usr/src/linux-source-2.6.34/Documentation/networking#
mii-tool -v eth1.99
eth1.99: no link
product info: vendor 00:50:43, model 10 rev 0
basic mode: autonegotiation enabled
basic status: no link
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: VLANs, bonding redux: vlan state does not follow ethernet
2010-05-22 6:45 ` George B.
@ 2010-05-22 17:47 ` George B.
2010-05-22 20:01 ` George B.
0 siblings, 1 reply; 4+ messages in thread
From: George B. @ 2010-05-22 17:47 UTC (permalink / raw)
To: netdev
On Fri, May 21, 2010 at 11:45 PM, George B. <georgeb@gmail.com> wrote:
> On Fri, May 21, 2010 at 11:24 PM, George B. <georgeb@gmail.com> wrote:
>> Using 2.6.34 I am trying to remove bottlenecks. Instead of bonding
>> two ethernet interfaces and applying vlans to the bond, I am applying
>> the vlans to the ethernet and bonding the vlans creating a separate
>> bond interface for each vlan.
>>
>> The trouble now is that the bond interface does not see when the
>> ethernet interface goes down. The vlan reports to the bonding driver
>> that it is up when the ethernet it is connected to is down. This
>> results in packet loss through the bond interface as the bond driver
>> attempts to use that vlan.
>>
>> eth1 shows having no link:
>>
>> root@sandbox:/proc/net# ethtool eth1
>> Settings for eth1:
>> Supported ports: [ TP ]
>> Supported link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> 1000baseT/Full
>> Supports auto-negotiation: Yes
>> Advertised link modes: 10baseT/Half 10baseT/Full
>> 100baseT/Half 100baseT/Full
>> 1000baseT/Full
>> Advertised pause frame use: No
>> Advertised auto-negotiation: Yes
>> Link partner advertised link modes: Not reported
>> Link partner advertised pause frame use: No
>> Link partner advertised auto-negotiation: No
>> Speed: Unknown!
>> Duplex: Unknown! (255)
>> Port: Twisted Pair
>> PHYAD: 1
>> Transceiver: internal
>> Auto-negotiation: on
>> MDI-X: Unknown
>> Supports Wake-on: pumbag
>> Wake-on: g
>> Current message level: 0x00000001 (1)
>> Link detected: no
>>
>> bonding driver says eth1.99 reports MII status up:
>>
>> root@sandbox:/proc/net# cat bonding/bond0
>> Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
>>
>> Bonding Mode: load balancing (round-robin)
>> MII Status: up
>> MII Polling Interval (ms): 0
>> Up Delay (ms): 0
>> Down Delay (ms): 0
>>
>> Slave Interface: eth0.99
>> MII Status: up
>> Link Failure Count: 0
>> Permanent HW addr: 00:26:9e:1c:d3:3e
>>
>> Slave Interface: eth1.99
>> MII Status: up
>> Link Failure Count: 0
>> Permanent HW addr: 00:26:9e:1c:d3:3f
>>
>> is there some parameter I can give that tells the vlan driver to
>> follow the state of the interface it is attached to? Having a vlan
>> that reports being up all the time even when its underlying interface
>> is down is less than useful. It would seem intuitive that a vlan's
>> state would follow that of the interface it is attached to.
>>
>> root@sandbox:/proc/net# cat vlan/eth0.99
>> eth0.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
>> total frames received 32
>> total bytes received 4735
>> Broadcast/Multicast Rcvd 0
>>
>> total frames transmitted 50
>> total bytes transmitted 3852
>> total headroom inc 0
>> total encap on xmit 0
>> Device: eth0
>> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
>> EGRESS priority mappings:
>> root@sandbox:/proc/net# cat vlan/eth1.99
>> eth1.99 VID: 99 REORDER_HDR: 1 dev->priv_flags: 21
>> total frames received 0
>> total bytes received 0
>> Broadcast/Multicast Rcvd 0
>>
>> total frames transmitted 0
>> total bytes transmitted 0
>> total headroom inc 0
>> total encap on xmit 0
>> Device: eth1
>> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
>> EGRESS priority mappings:
>>
>> root@sandbox:/proc/net# ping 10.1.99.1
>> PING 10.1.99.1 (10.1.99.1) 56(84) bytes of data.
>> 64 bytes from 10.1.99.1: icmp_seq=2 ttl=255 time=0.299 ms
>> 64 bytes from 10.1.99.1: icmp_seq=4 ttl=255 time=0.311 ms
>> 64 bytes from 10.1.99.1: icmp_seq=6 ttl=255 time=0.325 ms
>> 64 bytes from 10.1.99.1: icmp_seq=8 ttl=255 time=0.291 ms
>> 64 bytes from 10.1.99.1: icmp_seq=10 ttl=255 time=0.308 ms
>>
>> George
>>
>
> But interestingly, mii-tool reports the correct result:
>
> root@sandbox:/usr/src/linux-source-2.6.34/Documentation/networking#
> mii-tool -v eth1.99
>
> eth1.99: no link
> product info: vendor 00:50:43, model 10 rev 0
> basic mode: autonegotiation enabled
> basic status: no link
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
>
I can't use arp monitor because when I do that it just flips back and
forth each second between slaves each monitor period:
May 22 10:45:28 sandbox kernel: [69276.450013] bonding: bond0: making
interface eth0.99 the new active one.
May 22 10:45:29 sandbox kernel: [69277.450010] bonding: bond0: link
status definitely up for interface eth1.99.
May 22 10:45:30 sandbox kernel: [69278.450009] bonding: bond0: link
status definitely down for interface eth0.99, disabl
ing it
May 22 10:45:30 sandbox kernel: [69278.450012] bonding: bond0: making
interface eth1.99 the new active one.
May 22 10:45:31 sandbox kernel: [69279.450009] bonding: bond0: link
status definitely up for interface eth0.99.
May 22 10:45:32 sandbox kernel: [69280.450009] bonding: bond0: link
status definitely down for interface eth1.99, disabl
ing it
May 22 10:45:32 sandbox kernel: [69280.450012] bonding: bond0: making
interface eth0.99 the new active one.
May 22 10:45:33 sandbox kernel: [69281.450012] bonding: bond0: link
status definitely up for interface eth1.99.
May 22 10:45:34 sandbox kernel: [69282.450009] bonding: bond0: link
status definitely down for interface eth0.99, disabl
ing it
May 22 10:45:34 sandbox kernel: [69282.450012] bonding: bond0: making
interface eth1.99 the new active one.
May 22 10:45:35 sandbox kernel: [69283.450012] bonding: bond0: link
status definitely up for interface eth0.99.
May 22 10:45:36 sandbox kernel: [69284.450009] bonding: bond0: link
status definitely down for interface eth1.99, disabl
ing it
May 22 10:45:36 sandbox kernel: [69284.450012] bonding: bond0: making
interface eth0.99 the new active one.
May 22 10:45:37 sandbox kernel: [69285.450012] bonding: bond0: link
status definitely up for interface eth1.99.
May 22 10:45:38 sandbox kernel: [69286.450008] bonding: bond0: link
status definitely down for interface eth0.99, disabl
ing it
May 22 10:45:38 sandbox kernel: [69286.450011] bonding: bond0: making
interface eth1.99 the new active one.
May 22 10:45:39 sandbox kernel: [69287.450010] bonding: bond0: link
status definitely up for interface eth0.99.
May 22 10:45:40 sandbox kernel: [69288.450008] bonding: bond0: link
status definitely down for interface eth1.99, disabl
ing it
This is with both physical links up. The arp monitor just causes the
links to constantly fail back and forth each arp_monitor interval.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: VLANs, bonding redux: vlan state does not follow ethernet
2010-05-22 17:47 ` George B.
@ 2010-05-22 20:01 ` George B.
0 siblings, 0 replies; 4+ messages in thread
From: George B. @ 2010-05-22 20:01 UTC (permalink / raw)
To: netdev
On Sat, May 22, 2010 at 10:47 AM, George B. <georgeb@gmail.com> wrote:
> This is with both physical links up. The arp monitor just causes the
> links to constantly fail back and forth each arp_monitor interval.
>
I can get it to work with miimon and use_carrier=1 with the vlan
interface (works to the raw ethernet without the use_carrier).
It would be nice, though, for arp_monitor to actually work as by
monitoring an IP on the core switch it would allow me to detect a
failed uplink from the access switch.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-05-22 20:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-22 6:24 VLANs, bonding redux: vlan state does not follow ethernet George B.
2010-05-22 6:45 ` George B.
2010-05-22 17:47 ` George B.
2010-05-22 20:01 ` George B.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).