Daniel Walton wrote (on Mon 24-Aug-2015 at 15:19 +0100):
....
> 'set comm-list delete' stops as soon as it hits a community-list
> entry with a deny
...
So, the new code runs each community, individually, against the "ip
community-list".
The effect is, clearly, to implement the Cisco semantics -- including the New
Rule that: an "ip community-list" entry which requires more than one community
value to match to is "invalid", in the context of "comm-list delete".
I agree this is an improvement: but any user of "comm-list delete" would need
to review their configuration before installing the new code, if only "just in
case".
I've attempted to summarise the changes from current behaviour, below. Of
these (2) is the most serious, and I think the new code handles this case
incorrectly. And (3) poses a (small) dilemma.
It is possible to argue that for invalid entries the code is free to do what it
likes. However, I would be tempted to explicitly ignore all invalid entries --
so that they do the same thing in all cases, for both 'standard' and 'expanded'.
So, the changes are:
1) as advertised: 'deny' entries are treated quite differently.
Current behaviour means that you can write a filter to remove
some communities, unconditionally, and then others only if
certain communities are absent.
Anyone depending on this is going to be disappointed by the
change -- when they finally figure out what has happened !
But... arguably, all current 'deny' behaviour is broken wrt
the Fine Manual.
2) ip community-list standard x (permit|deny) 10:1 20:1
The current code will match iff both 10:1 and 20:1 are present,
and 'permit' will remove both.
By the New Rule this entry is invalid -- so IMHO best ignored.
The new code will match either 10:1 *or* 20:1, and 'permit'
will remove either or both.
IMHO: it is wrong to treat this as an *or*, since in
all other contexts it's an *and*.
The current code implements *and*, but:
* I don't know how useful that is.
* it's harder to implement the 'deny' case.
* it's not feasible to implement the 'expanded'
(regex) version of the *and*.
So, there's a big difference between 'standard'
and 'expanded' here.
And, the current 'permit' behaviour is *not* ruled
out by the Fine Manual.
3) ip community-list standard x permit internet
The current code will remove a 0:0 if it is present.
The new code treats this as an 'any', and will proceed to remove
anything and everything.
The current behaviour allows 0:0 to be removed individually, but
is not consistent with general use of the 'internet' "community".
The new behaviour is consistent with the general use of 'internet',
but removes a great deal more than before !
SO: which is better ? A special case to deal with any 0:0, or
the consistent interpretation of 'internet' ?
Noting that:
(a) there is already a way to do "any"...
(b) which may not be terribly useful in any case !
4) ip community-list standard x (permit|deny) internet 10:1 20:1
The current code will match anything, and 'permit' will remove
any of 0:0, 10:1 and 20:1 which are present.
By the New Rule this entry is invalid -- so IMHO best ignored.
The new code treats this as an "any" -- ignoring the 10:1 and
20:1. So 'permit' will remove all communities, and 'deny' will
preserve all.
The current behaviour is (very) peculiar... but the new behaviour
removes a great deal more than before !
Arguably 'internet' only makes sense on its own -- in which case
one could throw an error at configuration time ?
5) ip community-list expanded y (permit|deny) _10:1(.*)_20:1
The current code may match: 'permit' will then do nothing (!)
but 'deny' will terminate processing.
By the New Rule this entry is invalid.
The new code will never match, so the entry is (effectively)
ignored.
Finally, I note that in the case of:
ip community-list expanded y (permit|deny) internet
both the current and new code will match iff 0:0 is present, and 'permit' will
remove it.
Chris
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
