On 21/08/2015 19:49, 'Chris Hall' wrote: > 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 > ?
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... > 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 ? yes, that is correct. > I imagine that any old regex, say "(^| )(100|200|300):.*? 1234:\d*?666( > |$)", is expected to do exactly what it says (as currently implemented > by Quagga) ? But I note that it would do nothing at all if used with > "set comm-list xxx delete" (as currently implemented by Quagga). Or > does one expect that, say, "100:.* 200:.*" is actually a "wild-card" > version of "100:10 200:10" ? community tags are unordered lists. "100:10 200:10" is the same as "200:10 100:10". "100:.* 200:.*" would only match the former, surely? > 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 was an unusually peculiar choice by cisco to treat ordered and unordered lists of integers as text strings, yes. Nick _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
