[quagga-dev 7266] Semantic of ip prefix-list stuff

Chris Hall chris.hall at highwayman.com
Fri Sep 4 16:24:46 BST 2009


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 ?

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

  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 ?

  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.

  4) why 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 ?

     "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 ?

  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 ?

  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 ?
-- 
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/20090904/d6fd3a88/attachment-0001.sig>


More information about the Quagga-dev mailing list