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

paul at jakma.org paul at jakma.org
Fri Sep 4 19:00:22 BST 2009


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 ... 10.1.1.0/24 le 32" will match anything in
>    the given /24
>
>    "ip prefix-list ... 10.1.1.0/24 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?

> 2) why no ge with 'any' ?
>
>    "ip prefix-list ... any ge 8" would be equivalent to
>    "ip prefix-list ... 0.0.0.0/0 ge 8"
>
>    ... so why not allow it ?

Hmm. Maybe.

> 3) why no le with 'any' ?
>
>    "ip prefix-list ... any le 24" would be equivalent to
>    "ip prefix-list ... 0.0.0.0/0 le 24"
>
>    ... so why not allow it ?

> If both ge and le were allowed with 'any', then the syntax and semantics 
> would be simpler: 'any' is then exactly like '0.0.0.0/0', 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. :)

> 4) why le > ge ?

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

>    "ip prefix-list ... 10.1.1.0/24 ge 26 le 26" is perhaps a little
>    exotic, but not much more than:
>    "ip prefix-list ... 10.1.1.0/24 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.

>    "ip prefix-list ... 10.1.1.0/26" 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.

> 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   10.1.1.0/24 le 32
>       ...
>       ip prefix-list ... permit 10.1.1.0/27
>
>    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.

regards,
-- 
Paul Jakma	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
The two most beautiful words in the English language are "Cheque Enclosed."
 		-- Dorothy Parker



More information about the Quagga-dev mailing list