Samuel Lucas Vaz de Mello <[EMAIL PROTECTED]> wrote: > > 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.
Yes, this was a bug which I created by my previous fix. I just committed a fix to CVS: Revision Changes Path 1.57 +3 -1; commitid: 17bbc49065a0f41a7; xorp/pim/pim_bsr.cc 1.24 +2 -1; commitid: 17bbc49065a0f41a7; xorp/pim/pim_bsr.hh Yes, you are right about copying _my_bsr_addr and _my_bsr_priority to _bsr_addr and _bsr_priority. In one of my earlier emails on the subject I said that _bsr_addr and _bsr_priority are not used/needed for "configured" BsrZone entries. While chasing this bug I discovered they are actually used (when propagating the state to an "active" BsrZone entry), so now they are set when the Cand-BSR state is updated. > 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? Accidentally, couple of days ago I was thinking about the same when I noticed the bsr_stop()/bsr_start(). If I remember correctly, I used bsr_stop()/bsr_start() because there was lots of complexity when I tried to do the incremental update. Though, I don't remember whether this applied to the first version of the BSR implementation or to the (almost complete) rewrite I had to do after I discovered major issues with the first version. Another reason for the bsr_stop()/bsr_start() was because I wanted atomic update (e.g., transaction like), otherwise during reconfiguration there will be lots of flux with potentially dangerous results (remember that consistent Cand-RP set across all PIM-SM routers is critical). At that time there was no easy way to apply some transaction-based mechanism to achieve the atomic update, so the bsr_stop()/bsr_start() was the simple work-around (e.g., note that it is in the etc/templates/pimsm*.tp template files). If you can find a simple way to do the update atomically without bsr_stop()/bsr_start(), then give it a try and see how well it works. Otherwise, please submit a Bugzilla entry about the issue. Thanks, Pavlin _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
