Discussion:
[quagga-dev 16711] IP Prefix-lists "ge" value
Siva Kesava
2018-03-04 20:58:05 UTC
Permalink
The documentation specifies that in an IP-Prefix List "The prefix list will
be applied if the prefix length is greater than or equal to the ge prefix
length."

For reference:
https://www.nongnu.org/quagga/docs/docs-multi/IP-Prefix-List.html

But in practice, the following command :

ip prefix-list 101 seq 5 permit 1.0.1.0/24 ge 24 le 24

gives an error:

Invalid prefix range for 1.0.1.0/24, make sure: len < ge-value <= le-value.

I believe that the condition has to be len <= ge-value <= le-value as per
the documentation.

This difference is found in the lib/plist.c file in
"vty_prefix_list_install" function probably in line 754(quagga 1.2.4
version)



‌
<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality&>
Paul Jakma
2018-03-05 22:00:03 UTC
Permalink
Hi Siva,
Post by Siva Kesava
The documentation specifies that in an IP-Prefix List "The prefix list
will be applied if the prefix length is greater than or equal to the
ge prefix length."
https://www.nongnu.org/quagga/docs/docs-multi/IP-Prefix-List.html
ip prefix-list 101 seq 5 permit 1.0.1.0/24 ge 24 le 24
Invalid prefix range for 1.0.1.0/24, make sure: len < ge-value <= le-value.
That doesn't seem an reasonable condition either though. Is:

ip prefix-list 101 seq 5 permit ..../X ge X le X

not just a long-winded (and confusing?) way of saying:

ip prefix-list 101 seq 5 permit ..../X

? (If ge/le are not specified, the prefix-length must be an exact
match).

Given "ip prefix-list ... ..../X ge X le X" would be a redundant way of
just saying "ip prefix-list ... ..../X", there is value in not allowing
other forms and having one form (it keeps some things simple).

That said, do other systems allow the redundant form? Do people expect
that to work? Do people /use/ the "/X ge X le X" form (and why)?
Post by Siva Kesava
I believe that the condition has to be len <= ge-value <= le-value as per
the documentation.
Or the documentation fixed. Though, if people expect ".../X ge X le X"
to work (why use that? is it cause people are not sure of the behaviour
of "prefix/X"?)?
Post by Siva Kesava
This difference is found in the lib/plist.c file in
"vty_prefix_list_install" function probably in line 754(quagga 1.2.4
version)
prefix_list_entry_match would have to be changed too.

Also, we'd have to think whether "prefix/X ge X le X" should be
normalised to just "prefix/X" internally (and so "show running-conf"
would show that), or whether it should be kept distinct. Opinions?

Also, want to supply the full patch?

regards,
--
Paul Jakma | ***@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
I look at life as being cruise director on the Titanic. I may not get
there, but I'm going first class.
-- Art Buchwald
Siva Kesava
2018-03-05 22:09:26 UTC
Permalink
Hi Paul,

The better way as per me is to fix the documentation rather than changing
the code base since prefix-list without ge and le would do an exact match,
unlike access-lists.


Do people /use/ the "/X ge X le X" form (and why)?
I was doing a conversion from general config language to Quagga language
and was just outputting ge and le irrespective of them being equal to
length so I was just curious why that would be an error even though
documentation mentions it.

Cisco config language has "eq" (equal) option also but Quagga does not
require it.

‌Thanks
Siva
Post by Paul Jakma
Hi Siva,
The documentation specifies that in an IP-Prefix List "The prefix list
will be applied if the prefix length is greater than or equal to the ge
prefix length."
https://www.nongnu.org/quagga/docs/docs-multi/IP-Prefix-List.html
ip prefix-list 101 seq 5 permit 1.0.1.0/24 ge 24 le 24
Invalid prefix range for 1.0.1.0/24, make sure: len < ge-value <= le-value.
ip prefix-list 101 seq 5 permit ..../X ge X le X
ip prefix-list 101 seq 5 permit ..../X
? (If ge/le are not specified, the prefix-length must be an exact match).
Given "ip prefix-list ... ..../X ge X le X" would be a redundant way of
just saying "ip prefix-list ... ..../X", there is value in not allowing
other forms and having one form (it keeps some things simple).
That said, do other systems allow the redundant form? Do people expect
that to work? Do people /use/ the "/X ge X le X" form (and why)?
I believe that the condition has to be len <= ge-value <= le-value as per
the documentation.
Or the documentation fixed. Though, if people expect ".../X ge X le X" to
work (why use that? is it cause people are not sure of the behaviour of
"prefix/X"?)?
This difference is found in the lib/plist.c file in
"vty_prefix_list_install" function probably in line 754(quagga 1.2.4
version)
prefix_list_entry_match would have to be changed too.
Also, we'd have to think whether "prefix/X ge X le X" should be normalised
to just "prefix/X" internally (and so "show running-conf" would show that),
or whether it should be kept distinct. Opinions?
Also, want to supply the full patch?
regards,
--
I look at life as being cruise director on the Titanic. I may not get
there, but I'm going first class.
-- Art Buchwald
Paul Jakma
2018-03-05 22:18:36 UTC
Permalink
Post by Siva Kesava
Post by Paul Jakma
Do people /use/ the "/X ge X le X" form (and why)?
I was doing a conversion from general config language to Quagga language
and was just outputting ge and le irrespective of them being equal to
length so I was just curious why that would be an error even though
documentation mentions it.
The reason will be to avoid the duplicate syntax for the same case, and
avoid questions around whether or not to normalise.

We could change it, if it was common practice elsewhere to use ".../X ge
X le X" (I can see an argument that that would reduce ambiguity, by
being explicit about the range, and not relying on the implicit
'exactness' of just "...X").
Post by Siva Kesava
Cisco config language has "eq" (equal) option also but Quagga does not
require it.
'eq' might be useful too.

That that exists makes me think these more verbose forms are used for
the explicitness reason above, and that the implicit exact-match perhaps
is avoided by some (implicit behaviour is harder to remember).
Post by Siva Kesava
‌Thanks
Siva
regards,
--
Paul Jakma | ***@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
"There is hopeful symbolism in the fact that flags do not wave in a vacuum."
--Arthur C. Clarke
Loading...