Daniel Walton wrote (on Sat 22-Aug-2015 at 04:43 +0100): > On Fri, Aug 21, 2015 at 6:22 PM, Nick Hilliard wrote: ... >> sounds like undefined behaviour to me. It would probably >> be better for community-lists to handle deny statements in >> the cisco style instead of instead of stopping processing, >> but if you use something that's undefined...
Given that "deny" doesn't do what it is defined to do (and doesn't do what Cisco semantics would lead you to expect), I suppose it would be unwise to go ahead any use "deny" entries, and it would be your own damn fault if the feature were suddenly fixed ! But you know, and I know, there is a tendency to depend on what the thing actually does rather than what the Fine Manual suggests it should do :-( > I have a patch that fixes 'set comm-list xxx delete' so that it > handles deny statements but I do not think we have pushed it to > our github repo yet. I'll sync up with Donald on this on Monday > and get it posted. I agree that deviation from the (generally expected) Cisco semantics requires some Good Reason. However, the current interpretation of "deny" is arguably useful -- stop deleting things if this community is present (or these communities are all present) -- so simply "fixing" this could make an existing configuration "misbehave". I think "ip community-list xxx deny internet" is clear enough... meaning "do not delete anything more", or "stop deleting", but... ...what should one do with "ip community-list xxx permit internet" ? I think this is the same as "any", so should delete everything -- but that's not what the current code does :-( In this case, the Fine Manual doesn't tell us what to expect. For "comm-list delete", the meaning of "ip community-list xxx permit/deny 100:10 200:10" seems slightly slippery. For "permit" it is taken to mean delete both communities iff both are present. For "deny", does this mean keep both iff both are present ? Or keep either if either is present ? I suppose the second can always be written as two separate "deny" entries, so perhaps this is not an issue. Cisco avoid this issue by specifying that more than one community is not valid for "comm-list delete" ! The implementation of "deny" with regex must be fun. But in any case, I guess the trick is to maintain a list of communities which exist and are not to be deleted, and either restore those at the end, or examine the "not delete" list at each attempt to delete a given community. I cannot think of a good way to make a non-trivial regex work with "comm-list delete" :-( To make (for example) "100:.* 200:.*" work, one could try it against all possible subsets of the communities. Sadly, there are ~ 2^n of those :-( Chris _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
