[Bridge] Help on configuring ports for RSTP

Srinivas M.A. srinivas.aji at gmail.com
Tue Apr 21 14:37:50 PDT 2009


Hi,
Sorry for the delayed reply.

It sounds like RSTP is setting the port states to the expected values,
though I can't be sure without knowing the bridge IDs of ES1, ES2 and
the external switch.

What you are using doesn't seem to be a regular Linux bridge, right?
Have you modified the rstpd to receive/send BPDUs and set port states
correctly for this platform?
In particular, you need to check whether STP_OUT_port_set_state() is
doing the right thing for that bridge, i.e. when a port is set to
disabled, it should not forward packets out through that port, and it
should not process received packets on that port: In particular it
should update its forwarding table based on packets received on that
port.

You could see if that is the issue by repeatedly inspecting the MAC
tables on the bridges during your test.

Srinivas

On Fri, Apr 17, 2009 at 10:18 AM, Jon Vincent <jon.bvincent at gmail.com> wrote:
> Hello,
> I'm testing the userspace RSTPD daemon using the source from:
>
> https://lists.linux-foundation.org/pipermail/bridge/2009-February/006178.html
>
> The switch setup under testing is pictured below:
>
>
>  Uplink               Uplink
>    |                    |
>    |u1                  |u2
>    |           T        |
> [Eth.Switch]---------[Eth.Switch]
>   ES1                  ES2
>    |                    |
>    |c1                  |c2
>    |                    |
>   CPU1                 CPU2
>
> The ethernet switch is from Marvell and supports distributed switching
> architecture (DSA). The control interface to the switch is from the
> CPU and the rstpd is run on the CPU. The CPU's ethernet port is also
> connected to the ethernet switch but it does not participate for STP
> and is not bridged.
>
> Each CPU has two pseudo network interfaces (u1 and T) that are bridged
> and RSTP is run on the bridge. When both uplinks u1 and u2 are
> connected to an external switch, rstpd detects the loop and puts one
> of the uplink to discarding mode. Here are the port states and
> configurations that i'm using for the above setup:
>
> Switch        Port      AutoEdge   P2P   AdminEdge
> ES1           u1        Yes        Yes   No
>              T         No         Yes   No
> ES2           u2        Yes        Yes   No
>              T         No         Yes   No
>
> rstpd's computed port states:
>             Switch        Port      State
> Root bridge  ES1           u1        forwarding
>                           T         forwarding
>             ES2           u2        discarding
> Root port                  T         forwarding
>
> I'm trying to ping CPU2 from CPU1 which works. Given the above state
> table, the packets are sent through the link T from CPU1 to CPU2 and i
> do not have packet drops. When trying to ping CPU1 from CPU2, there
> are around 50% packet drops. In this case too, the packets can only be
> sent through T since the link u2 is in discarding mode.
>
> I suspected it could be a configuration issue in the ethernet switch
> and to test that, i stopped the rstpd and the ping works fine in both
> the directions. If the network interface u2 is down'ed (by plugging
> out the cable), the ping happens smoothly without packet drops. The
> only scenario where the packet drop seems to happen is when the
> non-root bridge has one of its port in discarding mode.
>
> It would be really helpful if someone could let me know if i'm wrong
> in any of the configuration to be done for RSTP.
>
> Thanks,
> Jon
>


More information about the Bridge mailing list