[Xorp-hackers] PIM-SM4: Cand-RP and Cand-BSR Inconsistency
Samuel Lucas Vaz de Mello
samuellucas at datacom.ind.br
Mon Oct 27 15:00:53 PDT 2008
> 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:
root at erdinger> 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
More information about the Xorp-hackers
mailing list