inet
inet copied to clipboard
Improvements to STP/RSTP
Examples are here:
https://github.com/ManiAm/inet/tree/INETex/examples_INETex/STP
I try to run fingerprint tests for STP/RSTP simulations: (on topic/ManiAm-stp branch in inet repo)
These simulations generates errors:
-
/examples/ieee8021d/ -f omnetpp.ini -c STP-LargeNet -r 0 (runtime error with exitcode=1: <!> Error: Logic error: frame BPDU from higher layer has local MAC address as dest (AA-AA-AA-00-00-02) -- in module (inet::EtherMac) LargeNet.switch2.eth[3].mac (id=139), at t=79.000001348s, event #57894)
-
/examples/ieee8021d/ -f omnetpp.ini -c STP-LinkReconnect -r 0 (runtime error with exitcode=1: <!> Error: Logic error: frame BPDU from higher layer has local MAC address as dest (AA-AA-AA-00-00-03) -- in module (inet::EtherMac) LargeNet.switch3.eth[2].mac (id=178), at t=79.000001348s, event #59736)
All other STP/RSTP simulation reports FAILED fingerprint values
Ok, I am going to take a look at it.
Still haven't found any free time to look into this.
I think the failed fingerprint is expected. In the original INET code, each switch is using the MAC address of its first Ethernet interface as its Switch MAC. I do not know what is the logic/rationale behind this, but in almost all implementations, each switch has a base MAC port that is unique. When you power up a switch, you will see its base MAC address getting printed on the console. In my PL, I have added the base MAC port concept and each switch is using it for communication. Hence the change in fingerprint.
fingerprints calculated from these values of events: t - time of event p - full path of event handler module l - length of handled cPacket x - extra values added with FINGERPRINT_ADD_EXTRA_DATA() or FINGERPRINT_ADD_EXTRA_DATA2() in c++ code
Just talked to Zoltan, what he meant was that actual frame content doesn't affect the fingerprint, so the fact that bridgeAddress is now computed differently shouldn't make a fingerprint test fail (unless the values actually affect the communication or the outcome of the algorithm somehow). So maybe there is some other issue. We'll continue next week by testing which commit changes the fingerprints.
Thanks for the clarification Andras. Then I need to sit and check where the problem is! After yesterday's changes to STP/RSTP, probably I need to invest even more time :)