> Fields _bsr_addr and _bsr_priority are suppose to be the state for > the Elected BSR. They matter in the set of so called "active" > BsrZone entries, but are not used in the "configured" BsrZone > entries. > > There was a bug in old code re. how the state from the "configured" > BsrZone was propagated to the "active" BsrZone. > That bug was exposed my previous change. > > I just committed a fix to CVS, so please try it and let me know if > you still have this or some other issue: > > Revision Changes Path > 1.56 +3 -3; commitid: ec3e4902630a41a7; xorp/pim/pim_bsr.cc >
Thank you Pavlin! This basically fix it. Just a minor issue: After getting elected, shouldn't _my_bsr_addr/_my_bsr_priority be copied to _bsr_addr/_bsr_priority ? For me, it shows like this: [EMAIL PROTECTED]> show pim bootstrap Active zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 0.0.0.0 0 10.1.3.11 1 Elected 58 -1 Expiring zones: BSR Pri LocalAddress Pri State Timeout SZTimeout Configured zones: BSR Pri LocalAddress Pri State Timeout SZTimeout 0.0.0.0 0 10.1.3.11 1 Init -1 -1 As the machine is elected as Active BSR, wouldn't the Active address be 10.1.3.11 instead of 0.0.0.0? I saw that i_am_bsr() checks if bsr_addr()==my_bsr_addr(), what would lead to further errors. Another issue: If the node is Elected as BSR and I add another Cand-RP, it triggers bsr_stop() and bsr_start() what causes it to lose Elected state and return to Pending. Although this is not wrong, it would be better to just keep the state (the stop() causes Cand-RP-ADV with zero holdtime, what changes the state also in remote peers). I was wondering about writing an update method that apply the actions in stop() and start() only in the changed zones. What do you think? Thank you, - Samuel _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
