I am facing an issue while testing basic RSTP testing with 2 switches.
I have used the latest rev35 (issue in RSTP testing with 3 switches for loop detection) code base.The issue I am facing here is Designated Port is getting toggling between Blocking and Learning states, never enters to a Forwarding state, when the port is loop blocked.
RSTP Test scenario with 2 switches:
1) Connect two RSTP enabled switches (SW1 and SW2).
2) Connect a loop on two local ports of one switch (non-root Bridge).
3) one of the Looped port on non-root bridge will be Backup port role in Blocking state,
while the other will be in Designated role. But its state is toggling between
Blocking and Learning states and never entering into Forwarding state.
I tried by reverting the fix done for rev35 (issue in RSTP testing with 3 switches for loop detection). With rev34 code base, mstpd is working fine for the above scenario.
Looking forward for your inputs.
Regards,
Rajani
Last edit: satyanarayana 2012-10-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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,
//changed to root times /* timesOfRootPort */ &tree->rootTimes,
cist))
ptp->updtInfo = true;
continue;
}
let us know your feedback on the change.
Regards,
Rajani
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, Rajani!
After some consideration and experimentation I came to conclusion that we definitely should use designatedTimes here instead of timesOfRootPort. After all, updtInfo semantics is:
updtInfo:
A boolean. Set by the Port Role Selection state machine to tell the Port Information state machine that it should copy designatedPriority to portPriority and designatedTimes to portTimes.
So, it is intended to be set when portPriority/portTimes differs from designatedPriority/designatedTimes.
Also, your experiments validated that conclusion.
Please, try attached patch and see, if it breaks something. If all is OK, I'll commit it to the SVN repository.
Sorry for the delayed response, as we are in vacations.
We have tested RSTP issue successfully (no issues observed) with provided patch (timesOfRootPort.patch).
thank you once again.
Regards
Rajani
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, Rajani!
Excuse me for ignoring your initial request, the e-mail notifier for this forum isn't perfect and I hadn't got notification about this thread.
As for your fix, basically it means that we should use ptp->designatedTimes instead of the timesOfRootPort. As you can see from the comment in that area of code, I was in doubt from the start, if I should use ptp->designatedTimes or timesOfRootPort:
/* 802.1q-2005 says, that at some point we need compare portTimes with * "... one for the Root Port ...". Bad IEEE! Why not mention explicit * var names??? (see 13.26.23.g) for instance) * So, now I should guess what will work for the timesOfRootPort. * Below is the result of my guess. I could be wrong, of course: * timesOfRootPort = root_ptp ? &root_ptp->portTimes * : &tree->BridgeTimes; * NOTE: Both Alex Rozin (author of rstplib) and Srinivas Aji (author * of rstpd) compare portTimes with designatedTimes instead of * timesOfRootPort. This differs from my interpretation of the standard * because designatedTimes have incremented Message_Age (or decremented * remainingHops if rcvdInternal). */
and your fix somehow supports the "ptp->designatedTimes" party.
Could you elaborate a bit more, how have you got to the conclusion that designatedTimes (i.e. times with updated Message_Age) should be used instead of the times with original Message_Age?
As you can see it was a hard and doubtful decision for me and it influences several places (actually, 3 places) in the code. So I would greatly appreciate if you can share your thoughts about why we should prefer designatedTimes here.
Thank you for your work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Vitalii,
I am facing an issue while testing basic RSTP testing with 2 switches.
I have used the latest rev35 (issue in RSTP testing with 3 switches for loop detection) code base.The issue I am facing here is Designated Port is getting toggling between Blocking and Learning states, never enters to a Forwarding state, when the port is loop blocked.
RSTP Test scenario with 2 switches:
1) Connect two RSTP enabled switches (SW1 and SW2).
2) Connect a loop on two local ports of one switch (non-root Bridge).
3) one of the Looped port on non-root bridge will be Backup port role in Blocking state,
while the other will be in Designated role. But its state is toggling between
Blocking and Learning states and never entering into Forwarding state.
I tried by reverting the fix done for rev35 (issue in RSTP testing with 3 switches for loop detection). With rev34 code base, mstpd is working fine for the above scenario.
Looking forward for your inputs.
Regards,
Rajani
Last edit: satyanarayana 2012-10-13
Hello Vitalii,
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,
let us know your feedback on the change.
Regards,
Rajani
Hello, Rajani!
After some consideration and experimentation I came to conclusion that we definitely should use designatedTimes here instead of timesOfRootPort. After all, updtInfo semantics is:
updtInfo:
A boolean. Set by the Port Role Selection state machine to tell the Port Information state machine that it should copy designatedPriority to portPriority and designatedTimes to portTimes.
So, it is intended to be set when portPriority/portTimes differs from designatedPriority/designatedTimes.
Also, your experiments validated that conclusion.
Please, try attached patch and see, if it breaks something. If all is OK, I'll commit it to the SVN repository.
Thank you for your work!
Last edit: Vitalii Demianets 2012-10-23
Hello, Rajani!
Have you reviewed the patch? Does it work for you?
Regards,
Vitalii
Hi Vitalii,
Sorry for the delayed response, as we are in vacations.
We have tested RSTP issue successfully (no issues observed) with provided patch (timesOfRootPort.patch).
thank you once again.
Regards
Rajani
Thank you for your debugging and testing efforts!
I've updated SVN repository with that patch, current revision is 36.
Have a nice vacation, have fun!
Hello, Rajani!
Excuse me for ignoring your initial request, the e-mail notifier for this forum isn't perfect and I hadn't got notification about this thread.
As for your fix, basically it means that we should use ptp->designatedTimes instead of the timesOfRootPort. As you can see from the comment in that area of code, I was in doubt from the start, if I should use ptp->designatedTimes or timesOfRootPort:
and your fix somehow supports the "ptp->designatedTimes" party.
Could you elaborate a bit more, how have you got to the conclusion that designatedTimes (i.e. times with updated Message_Age) should be used instead of the times with original Message_Age?
As you can see it was a hard and doubtful decision for me and it influences several places (actually, 3 places) in the code. So I would greatly appreciate if you can share your thoughts about why we should prefer designatedTimes here.
Thank you for your work!