On Fri, 21 Aug 2015, Chris Hall wrote:
On the subject of "set comm-list xxx delete", The Fine Manual (page 61)
says:
"For communities value deletion, only permit community-list
is used. deny community-list is ignored."
AFAICS this is true "up to a point". What actually happens is that when
a "deny" entry in the community-list matches the communities, processing
of the community-list ceases. If the "deny" entry does not match, it is
(indeed) ignored.
I am not qualified to suggest whether this is a documentation or a code
SNAFU... but I guess it does what it does and everybody is used to that
?
It'd be good to document this, both the current behaviour and then any
improvements, wouldn't it? (I.e. in the documentation).
I guess in terms of what we have supported, we have never defiend
behaviour when a deny is included, so we ahve some latitude to do whatever
is sensible here, including honouring the documentation.
ip community-list 120 deny 100:50
ip community-list 120 permit 100:.*
may be expected to delete all 100:.* except for 100:50, which looks
useful and reasonably obvious ! But I guess it's too late to change
Quagga to do that now ?
I think we're in undefined land on the deny really. Perhaps it should be
ignored, as the docs say. But, whatever works for people - I see Daniel
has a patch to make this work in accordance with other implementations?
BTW, running "100:.*" through the regular expression engine has the
happy, or possibly unhappy, effect of matching (inter alia) 100:10 and
32100:10. I guess that's what everybody expects/wants ?
Expected given how regexes work, though perhaps will be unexpected in this
context. I think that should be documented, for sure. An option to
automatically anchor it might be useful for some?
Returning to the Fine Manual, it also says that with this configured:
ip community-list standard DEL permit 100:1 100:2
route-map RMAP permit 10
set comm-list DEL delete
"value 100:1 and 100:2 is removed"... which doesn't quite capture the
subtlety that 100:1 and 100:2 are both removed, iff *both* are present.
A patch to make the documentation finer would be good :).
In this context, Cisco get twitchy about multiple community values in an
"ip community-list" when used with "set comm-list xxx delete", which I
have some sympathy with, simplicity-of-semantics-wise. Though it's not
clear what happens if you do use an inappropriate "ip community-list",
<sigh>.
PS: IMHO, I feel that using a regex for these things is rather like
using a machine-pistol to enforce discipline in a kindergarten: it'll
probably work, but you may not be completely happy with the result.
It lets you implement policies where the community number space is split
into different things. Kind of working around a lack of typing. BGP Wide
Communities might help fix this and allow thigns to be a bit more
structured, maybe.
Another possible gotcha is that in the context of a delete, the regexp is
applied community by community; while for a general match the regexp is
applied to the string form of the entire list of communities. (Possible to
think it does community by community in both cases).
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Check me if I'm wrong, Sandy, but if I kill all the golfers...
they're gonna lock me up and throw away the key!
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
