[quagga-dev 7271] Re: Semantic of ip prefix-list stuff

Chris Hall chris.hall at highwayman.com
Sat Sep 5 00:34:23 BST 2009

On Fri, 4 Sep 2009 you wrote
>On Fri, 4 Sep 2009, Chris Hall wrote:
>> Have been looking at prefix-list handling.  I'm puzzled by some semantics:
>> 1) why must ge be > prefix length ?
>>    "ip prefix-list ... le 32" will match anything in
>>    the given /24
>>    "ip prefix-list ... ge 24" would do the same thing, but
>>    is rejected...

>>    That's compatible with the Cisco documentation...  but I see no
>>    other good reason for it ?

>/24 ge 24 seems like the user made a mistake, more than anything else. 
>Why not warn them?

>>    Seems to me that this is a perfectly good way of expressing the
>>    required effect.

>Surely just '/24' is better if you want the exact match?

"ip prefix-list ... ge 24" wouldn't be an exact match.  It 
would be another way of saying "... le 32".  (I happen to 
prefer it, but that's a matter of taste.)

>> If both ge and le were allowed with 'any', then the syntax and 
>>semantics  would be simpler: 'any' is then exactly like '', 
>>except that there  is an implied le 32 (or an implied ge 0 !), which 
>>may be overridden.

>Ok, it seems an idea. I can't see a problem with it. Feel free to 
>supply a patch. :)

OK.  Will do.

>> 4) why le > ge ?

>That would never match anything, if you allowed le to be < ge. But you 
>seem to mean le == ge (??).

Yes.  I meant why not allow le == ge.

>>    "ip prefix-list ... ge 26 le 26" is perhaps a little
>>    exotic, but not much more than:
>>    "ip prefix-list ... ge 26 le 27".
>>    That's compatible with the Cisco documentation...  but I see no
>>    other good reason for it ?

>See earlier - ge X le X just seems like the user made a typo. Accepting 
>it means we can't flag the possible mistake.

Well... it seems to me that ".../24 ge 26 le 26" is only very slightly 
more exotic than ".../24 ge 26 le 27".  But I am struggling to think of 
a good reason for either.

>>    "ip prefix-list ..." obviously has the same effect, but
>>    does that matter ?
>> 5) when applying a prefix-list -- prefix_list_apply() -- quagga
>>    treats a non-existent list (plist == NULL) as DENY, but
>>    any empty prefix_list (plist->count == 0) as PERMIT.
>>    The only instance I can find of a prefix_list existing but being
>>    empty is when an "ip prefix-list description" has been set, but
>>    nothing else.
>>    Anyone know why this would be treated as PERMIT ?

>Huh, that seems weird and wrong to me too.

OK.  I will assume it's a mistake until convinced otherwise.

>> 6) it's a small point, but when a sequence number is not given, the
>>    Cisco documentation says it will advance in steps of 5 -- so if
>>    you start "ip prefix-list ... seq 3 ...", any subsequent unnumbered
>>    entries will become 8, 13, 18 etc.  (I imagine what it actually does
>>    is add 5 to the highest sequence number so far.)
>>    For unnumbered entries quagga uses (max / 5) * 5 + 5... so resyncs
>>    to multiples of 5, which is perhaps neater.  Except that if the max
>>    is (say) 14, the next sequence will be 15 -- no gap is left.
>>    Anyone know why this departs from the Cisco Way ?
>>    Would it be better to ((max + 4) / 5) * 5 + 5 ?

>Patch to round-up so that gap is >= 5 would be accepted.


>> 7) quagga goes to some effort to prevent a prefix_list from containing
>>    two identical entries.  I suppose this is helpful.  (It eliminates
>>    an ambiguity when "no ip-prefix" with no sequence number -- though
>>    that could kill off all matching entries...)
>>    It doesn't attempt to spot other redundant stuff, for example:
>>       ip prefix-list ... deny le 32
>>       ...
>>       ip prefix-list ... permit
>>    Perhaps this is asking too much...  It just seems there's quite a
>>    lot of work going on checking prefix-lists when reading a config
>>    file, to not a lot of purpose.  "no ip-prefix" I expect is rare
>>    as hens' teeth, particularly the unnumbered version -- so it would
>>    be better to make that cope with the fringe case of duplicate
>>    prefix-list entries ?
>>    Or is this the Cisco Way ?

>I don't know to be honest, but if you want to supply a patch to try 
>normalise entries as they're created (for adding or to compare), I'd 
>apply it.

Hmm.  It's doing a lot of work as it is.  If it's thought to be vital to 
ensure no redundant entries are allowed in the prefix_list... I'll think 
on a complete test, rather than the current partial one.  My feeling 
remains, however, that it would be better to allow duplicate entries to 
be added, and in the event of an unnumbered "no ip-prefix" for duplicate 
entries, remove them all -- with a warning.

Chris Hall               highwayman.com            +44 7970 277 383
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 470 bytes
Desc: not available
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20090905/ad97071c/attachment-0001.sig>

More information about the Quagga-dev mailing list