[Bridge] Problem in mixing RSTP/STP configuration
Ramasamy Chandramouli
ramasamycmouli at gmail.com
Sat Jul 4 07:00:07 PDT 2009
Hi Srinivas,
Really sorry for this long gap in replying due to unavailability of
the test setup.
I'm using rstpd daemon in the switches RSTP_SW1 and RSTP_SW2. I've
also made the ports p0 and p1 to be non-P2P as well as non-edge ports.
The switch loop still exists and after quite a number of seconds, the
loop gets broken by transition of p0 link of RSTP_SW1 to blocking
state.
The problem seems to occur when the RSTP port p1 of RSTP_SW1 goes to
forwarding mode before p0 ports are put into blocking state. Could
there be a problem in computing port vector priorities when mixing STP
and RSTP, so that, while computing the port roles, the RSTP port p1 is
wrongly assigned the 'root' role from 'alternate' role, before moving
the port p0 to blocking?
I've checked with the IEEE-802.1D-2004 specification for the same.
I've also verified the timings for processing the BPDUs and assignment
of port states in the switch. They seem to be in conformance with the
specification.
Thanks in advance,
Ramasamy C
On Wed, Jun 10, 2009 at 10:19 AM, Srinivas M.A.<srinivas.aji at gmail.com> wrote:
> One thing that could be a problem is that p0 on the two RSTP switches
> are set to auto p2p. This means that the RSTP will assume that it is
> p2p if the link is duplex and that it is a broadcast LAN segment if
> the link is not duplex. This assumption is valid only if all switches
> on the network are STP capable and only hubs create non p2p LAN
> segments. That is not the case in your network since there is a non
> STP switch. Try administratively setting the p0 ports on the RSTP
> switches to have p2p set to no.
>
> On Thu, Jun 4, 2009 at 1:28 AM, Ramasamy
> Chandramouli<ramasamycmouli at gmail.com> wrote:
>> Hello,
>>
>> I'm using rstpd application over two switches and they are connected
>> to another Nortel switch which operates STP rather than RSTP. They are
>> all connected by a 10/100 ethernet switch which does not process
>> BPDUs. Here is a simplified diagram when the system is up and running.
>>
>> +-------------+ R
>> | Root-Bridge o--------+
>> +-------------+ STP |
>> |
>> +-----------o--------------+
>> | STP_SW_NORTEL |
>> +-----------o--------------+
>> |
>> L | STP
>> |
>> +-----o-----+
>> +------+ | | 10/100 ethernet
>> | Host o---------o | switch
>> +------+ | | (no BPDU processing)
>> +--o-----o--+
>> | |
>> STP | | STP
>> +----------+ +----------+
>> p0 | | p0
>> +-----o-----+ +-----o-----+
>> | | p1 p1 | |
>> | RSTP_SW1 o---------------o RSTP_SW2 |
>> | | RSTP | |
>> +-----------+ +-----------+
>>
>> The MACs of the bridges and the root bridge to which they are all
>> synced with are:
>>
>> Root bridge: 00:11:22:xx:xx:xx
>> STP_SW_NORTEL: 00:11:58:xx:xx:xx
>> RSTP_SW1: 02:e0:xx:xx:44:01
>> RSTP_SW2: 02:e0:xx:xx:42:01
>>
>> The STP_SW_NORTEL carries the root bridge identifier in its STP BPDU
>> and the RSTP algorithm on RSTP_SW1 and RSTP_SW2 migrates the p0 port
>> to perform STP transactions. After a brief TopologyChange transaction,
>> the port states were as follows:
>>
>> Switch Port Root-Bridge Designated-Bridge Role/State
>> RSTP_SW1 p0 00:11:22:xx:xx:xx 02:e0:xx:xx:44:01 Root,Fwd
>> p1 00:11:22:xx:xx:xx 02:e0:xx:xx:44:01 Altn,Disc
>>
>> RSTP_SW2 p0 00:11:22:xx:xx:xx 02:e0:xx:xx:42:01 Root,Fwd
>> p1 00:11:22:xx:xx:xx 02:e0:xx:xx:42:01 Desg,Fwd
>>
>> p0 - auto-p2p, non-edge
>> p1 - auto-p2p, auto-edge
>>
>> The cost and port/bridge priorities are not modified and are left to
>> defaults assigned by the rstpd application. Sniffing the BPDUs from
>> the host reveals that after a while only STP_SW_NORTEL switch is
>> sending out the hello packets, and the bridges RSTP_SW1 and RSTP_SW2
>> are in sync with it.
>>
>> I'm facing the following problem:
>>
>> If the link L is removed, the switch RSTP_SW1 and RSTP_SW2 ends up
>> forming a loop. The port RSTP_SW1::p1 comes to forwarding state before
>> blocking the port RSTP_SW1::p0. The following are the sequence of
>> ports states:
>>
>> RSTP_SW1 RSTP_SW2
>> [before L is connected]
>> p0: altn/disc desg/fwd
>> p1: root/fwd desg/fwd
>>
>> [after L is connected]
>> p0: root/fwd root/fwd
>> p1: altn/disc desg/fwd
>>
>> [after L is disconnected]
>> p0: desg/fwd root/fwd
>> p1: root/disc desg/fwd
>>
>> p0: desg/fwd root/fwd
>> p1: root/learn desg/fwd
>>
>> p0: desg/fwd root/fwd
>> p1: root/fwd desg/fwd
>>
>> After disconnecting link L, the RSTP port moves through the
>> learning/forwarding states that puts the bridge to loop.
>>
>> If the mediating ethernet switch is removed and if the switches
>> RSTP_SW1 and RSTP_SW2 are directly connected to STP_SW_NORTEL switch,
>> the switches RSTP_SW1 and RSTP_SW2 loops up, if the root bridge link,
>> R is removed. The sequence seems to be:
>>
>> 1. RSTP_SW2::p0 sends out a TC BPDU with its own bridge ID as
>> root bridge id.
>> 2. RSTP_SW1::p0 sends out a TC BPDU with the root bridge as
>> the lost root bridge's ID.
>> 3. The above when received by RSTP_SW2::p0, thinks that it has
>> received a superior bridge and tries to sync up with the root bridge
>> ID sent by its neighbour: RSTP_SW1.
>>
>> After the above sequence, the port RSTP_SW1::p1 ends up in
>> learning/forwarding sequence which eventually forms a loop before
>> migrating any of the other STP ports to blocking/discarding mode.
>>
>> It would be of great help if some one could provide an insight into
>> what could be going wrong.
>>
>> Regards,
>> Ramasamy
>> _______________________________________________
>> Bridge mailing list
>> Bridge at lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/bridge
>>
>
More information about the Bridge
mailing list