Linux Ethernet Bridging - Apr 2007 - [Bridge] Bridge code enhancement (link state detection) and bug fix. (patches included).

On Thu, 17 Jun 2004 20:57:23 +0200
Mark Ruijter <bridge@siennax.com> wrote:
> 
> 1. Link state monitoring added.
> We discovered the following problem with the existing bridge code.
> The code doesn't monitor the link state of the interfaces. When using
> two cisco switches with two Linux bridging firewalls the following
> problem exists. When the Cisco switch that has the blocking (stp) Linux
> bridge attached dies, the Linux bridge no longer receives stp packets
> and changes it's state from blocking to forwarding. As soon as the
Cisco
> switch comes back alive a loop is created in the network for a short but
> long enough period of time. :-(
> 
Rather than add another state, it should just go to DISABLED state.

> To fix this I added link state monitoring to the code. This is only
> active when stp is turned on. When a link fails the bridge port goes to
> blocked and then to the new 'nolink' status. The bridge-utils patch
> makes it possible to see the status with brctl showstp.
> 
> I did encounter a second problem when writing the link monitoring code.
> When you add a vlan interface like eth0.10 then it's not possible to
> obtain link state information from this interface.

That is a VLAN problem, fix it there.  Sorry.

> The fix I wrote is that brctl now allows you to specify the interface
> that contains the link state.
> 
> Example : brctl addif NUM1 eth0.10 eth0
I prefer to eschew needless complexity.

That doesn't mean I won't consider adding it, but let me look at the
problem
a little more before accepting your solution as is.

1. Link state monitoring added.
We discovered the following problem with the existing bridge code.
The code doesn't monitor the link state of the interfaces. When using
two cisco switches with two Linux bridging firewalls the following
problem exists. When the Cisco switch that has the blocking (stp) Linux
bridge attached dies, the Linux bridge no longer receives stp packets
and changes it's state from blocking to forwarding. As soon as the Cisco
switch comes back alive a loop is created in the network for a short but
long enough period of time. :-(

To fix this I added link state monitoring to the code. This is only
active when stp is turned on. When a link fails the bridge port goes to
blocked and then to the new 'nolink' status. The bridge-utils patch
makes it possible to see the status with brctl showstp.

I did encounter a second problem when writing the link monitoring code.
When you add a vlan interface like eth0.10 then it's not possible to
obtain link state information from this interface.

The fix I wrote is that brctl now allows you to specify the interface
that contains the link state.

Example : brctl addif NUM1 eth0.10 eth0

The old syntax: "brctl addif NUM1 eth0.10" still works but the link
will
always appear to be up.

"brctl addif NUM1 eth0" works with link detection since this is a
valid
'link state providing' device.

If anyone is wants to know how to use the linux bridges with Cisco 
switches running rstp feel free to ask. It involves a few tricks to get 
it running.....

I also discovered a small bug in de bridge code shipped in 2.6.6.

2. Bug fix...
Creating a bridge like this is no longer possible:

vconfig add eth0 10
vconfig add eth0 20
ifconfig eth0.10 0.0.0.0 up
ifconfig eth0.20 0.0.0.0 up
brctl addbr NUM1
brctl addif NUM1 eth0.10
brctl addif NUM1 eth0.20

The last command produces the following error:
br_add_interface: File exists

Older bridge code did accept this although it would log a warning.

I hope the code can make it to mainstream. Please let me know how you
feel about it.

Mark Ruijter.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: bridge-utils-1.0.4.patch
Type: text/x-patch
Size: 5754 bytes
Desc: not available
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20040617/21e1aea9/bridge-utils-1.0.4-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-2.6.6-bridge_linkstate.patch
Type: text/x-patch
Size: 8549 bytes
Desc: not available
Url :
http://lists.linux-foundation.org/pipermail/bridge/attachments/20040617/21e1aea9/linux-2.6.6-bridge_linkstate-0002.bin

On Thu, 17 Jun 2004 20:57:23 +0200
Mark Ruijter <bridge@siennax.com> wrote:
> 
> 1. Link state monitoring added.
> We discovered the following problem with the existing bridge code.
> The code doesn't monitor the link state of the interfaces. When using
> two cisco switches with two Linux bridging firewalls the following
> problem exists. When the Cisco switch that has the blocking (stp) Linux
> bridge attached dies, the Linux bridge no longer receives stp packets
> and changes it's state from blocking to forwarding. As soon as the
Cisco
> switch comes back alive a loop is created in the network for a short but
> long enough period of time. :-(
> 
> To fix this I added link state monitoring to the code. This is only
> active when stp is turned on. When a link fails the bridge port goes to
> blocked and then to the new 'nolink' status. The bridge-utils patch
> makes it possible to see the status with brctl showstp.
> 
Could you split out the link state monitoring, and look at bonding to see
how they are doing it?

I have a fix for vlan code that passes MII and ethtool requests from the virtual
to physical device, so the bridge code wouldn't need to the hack about root
device.