> > I'm playing around with pimsm4 and found a strange behavior that seems to > > be a bug. > > > > To reproduce it, first add a cand-rp for any group-prefix and commit. Then, > > add a cand-bsr for the same group-prefix. When trying to commit I got the > > following error: > > > > 102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 > > for zone 224.0.0.0/4(non-scoped): already have scope zone > > 224.0.0.0/4(non-scoped) > > > > ================================================= > > [EMAIL PROTECTED] set protocols pimsm4 bootstrap cand-rp group-prefix > > 224.0.0.0/4 cand-rp-by-vif-name eth0 > > [edit] > > [EMAIL PROTECTED] commit > > OK > > [edit] > > [EMAIL PROTECTED] set protocols pimsm4 bootstrap cand-bsr scope-zone > > 224.0.0.0/4 cand-bsr-by-vif-name eth0 > > [edit] > > [EMAIL PROTECTED] commit > > Commit Failed > > 102 Command failed Cannot add configure BSR with vif eth0 address 10.1.3.11 > > for zone 224.0.0.0/4(non-scoped): already have scope zone > > 224.0.0.0/4(non-scoped)[edit] > > [EMAIL PROTECTED] > > ==================================================
================ > I need to double-check with the PIM BSR spec, but I think that > 224.0.0.0/4 has special meaning (it is the "global" zone) and cannot > be configured as a scoped zone. > Hence, the behavior is correct, though the error could be more user > friendly. ================ Please ignore my statement above, because it is complete nonsense (I was in a hurry and overlooked a number of things). Yes, I think what you see is a bug. > > In the code I found that PimNode::add_config_cand_rp adds a BSR zone when > > adding the RP and add_config_cand_bsr fails when finds this added zone. > > Also, this zone is not visible in the configuration tree (otherwise > > xorpsh/rtrmgr would have handled this as a modification in a existing > > cand-bsr, which works fine). > > > > I'm wondering what would be the best way to handle this. > > There are a few options: We can replace the automatically created zone with > > the user provided one, we can report the zone to rtrmgr/xorpsh or we can > > reuse the created zone and merge the changes, if possible. The second one is not really an option, because we never propagate state back to the rtrmgr/xorpsh. I think the correct behavior is the third one: reuse the created zone and merge the changes (if possible). The first one (replace the automatically created zone with the user provided one) might result in losing the Cand-RP state, which we definitely want to avoid. > > What do you recommend? > > > > > > BTW, after writing a patch how do I submit it? Just mail it to this list? Please open a Bugzilla entry about the issue and add te patch to that entry. Thanks, Pavlin _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
