JunOS filter list ordering issue

[S.P.Zeidler]

Hi,

Thus wrote Pekka Savola (pekkas at netcore.fi):

> On Mon, 1 Feb 2010, S.P.Zeidler wrote:
> >Of course. Numerically larger address before smaller one,
> >and longer mask before shorter one, so that eg:
> >
> >10.2.1.0/24
> >10.2.0.0/24
> >10.2.0.0/22
> >
> >so when it hits a match, all more specifics have already been seen.
> 
> Does this work? At least in some initial tests we did, it seemed as
> if JunOS would internally reorganize/optimize these and this would
> not be sufficient. But we tested prefix-length-range instead of
> "simple" route-filters, so the behaviour could be different there:
> 
>                 route-filter 2001:0678::/29 prefix-length-range /29-/48;
>                 route-filter 2001:0c00::/23 prefix-length-range /48-/48;
>                 route-filter 2001:13c7:6000::/36 prefix-length-range /36-/48;
>                 route-filter 2001:13c7:7000::/36 prefix-length-range /36-/48;
>                 route-filter 2001::/16 prefix-length-range /35-/35;
>                 route-filter 2001::/16 prefix-length-range /19-/32;

I've found:
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-configuring-route-lists-for-use-in-routing-policy-match-conditions.html#id-10270525

--- cite ---
Once an incoming route matches a prefix (longest first), the following
occur:

    * The route filter stops evaluating other prefixes, even if the match
	  type fails.
	* The software examines the match type and action associated with
	  that prefix.
--- cite ---

This means that either the behaviour of JunOS changed or my memory is
faulty; the reordering alone, longest to shortest, would only serve
as a help for human readers of the list to find the 'hit', and the
real problem is that mixing different match types for the same prefix
is bad karma (i.e.:
route-filter 192.168.0.0/20 exact accept;
route-filter 192.168.0.0/21 prefix-length-range /22-/22 accept;
is fine, but
route-filter 192.168.0.0/21 exact accept;
route-filter 192.168.0.0/21 prefix-length-range /22-/22 accept;
will blow up on you for 192.168.0.0/22, and the reverse order won't match
192.168.0.0/21. (Likewise, only one of the route-filter 2001::/16
statements will ever get used).

The solution seems to be not to create second entries for the same prefix,
at least not in the same term {} block; would doing:

--- snip ---
policy-options {
	policy-statement prefix-list-100 {
		term prefixes-exact {
			from {
				route-filter a.b.c.d/n exact accept;
				route-filter e.f.g.h/n exact accept;
			}
		}
		term prefix-ranges {
			from {
				route-filter a.b.c.d/n prefix-length-range /m-/l accept;
				route-filter e.f.g.h/n prefix-length-range /k-/l accept;
			}
		}
		term prefix-ranges2 {
			from {
				route-filter a.b.c.d/n prefix-length-range /o-/p accept;
				route-filter e.f.g.h/n prefix-length-range /p-/q accept;
			}
		}
		[ term prefix-rangesN ...]
		term catch-rest {
			then reject;
		}
	}
}
--- snip ---

sound good from your end? (Someone check if that actually works please).

The other option would be to not compress ranges if there is also an
'exact' around for the same prefix. That would not be much of a loss
for /22 in a /21, it would be wince-worthy for /24 in a /16 though.

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)