issue in RSTP testing with 3 switches for loop detection

[satyanarayana]

Thank you for sharing the MSTPD code base. We are using it for RSTP,
We are facing an issue in RSTP testing with 3 switches, where a blocked port is not recovering back to forwarding state, even if the loop gets disconnected.

RSTP Test Scenario with 3 switches:

1) connect a loop free topology of 3 switches (SW1 --> SW2 --> SW3), with default settings.
2) Sw1 and SW3 are connected in a loop (SW1 --> SW2 --> SW3 --> SW1),
topology changed by RSTP making one port on SW2 getting blocked.
3) Then remove the loop connected between SW1 and SW3 (SW1 --> SW2 --> SW3).But blocked port on SW2
now toggles between learning and listening state permanently and never enters to forwarding state.

We are looking forward for your inputs.

Regards,
-Rajani

[Vitalii Demianets]

Hello, Rajani!

I'm surprised that you mentioned "listening" state. There is no such thing in mstpd as "listening" state.
So, I guess, you have in-kernel stp enabled alongside with mstpd.
Please, do the following (substitute br0 with the actual name of your bridge):

cat /sys/class/net/br0/bridge/stp_state

and check the output. It must be 2 (2 = kernel knows about user-space STP daemon). If it is 1 (1 = kernel implements its own in-kernel STP algorithm) - then here is your problem.
Some background: kernel bridge can have three stp_states:

• 0 = no stp
• 1 = in-kernel stp
• 2 = user-space stp

mstpd works only when kernel bridge is in stp_state=2. To put kernel in that state bridge-stp helper script must return success when called from kernel. Usually it is called from kernel when STP is enabled by user (e.g. by issuing "brctl stp br0 on" command). When user requests kernel bridge to enable stp, kernel checks (with the help of bridge-stp script) if there is user-space STP daemon and if bridge-stp returns success - kernel goes to stp_state=2, else it goes to stp_state=1.

[satyanarayana]

Hello Vitalii,

Thank you for the response,your are correct, mstpd don't have listen, i re verified and analyzed the issue as below,

1) Toggles between learning and Blocking state permanently and never enters to forwarding state.
2) One more observation is :
In SW2 switch if we unplug and plug then problem is not seen (enter to forwarding state).

We are looking forward for your inputs.

Regards,
rajani

[Vitalii Demianets]

Hello, Rajani!

Ok, let's start debugging ;)

This discussion board is not very well suited for that kind of activity, so, please, write direct e-mail to me: dv1tas (AT) users (DOT) sf (DOT) net
Please, start mstpd in verbose mode (-v4) and include the relevant logs in e-mail, the part where it toggles between two states.
Also it would be great if you uncomment these two lines in the mstp.h file:

/* #define PISM_ENABLE_LOG */

and

/* #define PRTSM_ENABLE_LOG */

and re-build mstpd before running - then we'll get more interesting debugging info in the log.
Looking forward to your e-mail response.

P.S. What do you mean by "unplug and plug":
a) Turn power off and then off, or
b) Unplug ethernet cable and then plug it in again?

[satyanarayana]

Hello Vitalii,

Thank you for the inputs,
we are able to resolve the issue, please find the below changes that we have done in mstp.c , in "static void updtRolesTree(tree_t *tree)" function,

 /* i) Set role for the mine info */
    if(ioMine == ptp->infoIs)
    {
            ptp->selectedRole = roleDesignated;
            if(!samePriorityAndTimers(&ptp->portPriority,
                                      &ptp->designatedPriority,
                                      &ptp->portTimes,
                                      timesOfRootPort,
       //changed from false to true  /*cist*/ true))
                ptp->updtInfo = true;
            continue;
        }

let us know your feedback on the change.

Regards,
Satyanarayana

[Vitalii Demianets]

Hello!
(by the way, which way is correct to say - "Hello, Rajani" or "Hello, Satyanarayana" - I'm puzzled a bit :)

Thank you very much for your debugging, I appreciate it a lot! Surely there is a mistake in that particular piece of code. The last parameter in the samePriorityAndTimers() function call must be "cist" (in your case "true" works because you have no other trees except CIST, so in your case "cist" always is "true").

Please, make the following change in the code, build it and check if there are any problems with it:

        /* i) Set role for the mine info */
        if(ioMine == ptp->infoIs)
        {
            ptp->selectedRole = roleDesignated;
            if(!samePriorityAndTimers(&ptp->portPriority,
                                      &ptp->designatedPriority,
                                      &ptp->portTimes,
                                      timesOfRootPort,
                                      cist))
                ptp->updtInfo = true;
            continue;
        }

If there are no problems, I'll submit it into the SVN repository.

Many thanks again for spotting the bug! It's priceless )

[satyanarayana]

Hello Vitalii,

Thank you for the review,
we have tested with the above fix successfully.

:-) ,Rajani and me are working in the same team, so you can refer any name.

Regards
Satyanarayana

[Vitalii Demianets]

Okey, I've submitted it to the SVN. So, now the latest revision is 35:
https://sourceforge.net/p/mstpd/code/35/

Thank you, Satyanarayana & Rajani!