JunOS filter list ordering issue

S.P.Zeidler spz at serpens.de
Mon Feb 1 20:10:51 UTC 2010


Thus wrote Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 (rv at NIC.DTAG.DE):

>   > route-filter exact accept;
>   > route-filter exact accept;
>   > being bad karma because JunOS would see the first line matching on the
>   > range and then fail on the exact, and not continue to the next line that
>   > had the match on both the range and the exact.
> Juniper pointed out that they defined the route-filter lines so
> that a positive match for accept implies "reject all more specifics".
> The workaround that we grudgingly agreed is to split out a list
> of positive matches to separate terms per route-filter line
> (easy in a generator to inflate syntactic sugar between
> the actual prefix information:-)
>   > The way to solve this (afair) was to sort in reverse.
>   > The attached patch does that.
> Is it clear 
> (a) what specific reverse order is generated this way AND

Of course. Numerically larger address before smaller one,
and longer mask before shorter one, so that eg:

so when it hits a match, all more specifics have already been seen.

> (b) whether this really matches the peculiar JunOS semantics?
> Do you have any hints whether this was checked more formally,
> was involved in such check.

Logic should suffice to see that it fulfills the formal requirement. :)
AS1273 ran a while with this sort order for its JunOS prefix filters
while I was still there (I don't know the current state).

>   > Is the issue even relevant any more?
> Yes, from recent discussions with knowledgable JunOS developers I take that
> this idiosyncrasy of JunOS configuration has not changed.

It's a fairly obvious performance improvement mechanism; finish matching
at first IP range match.

spz at serpens.de (S.P.Zeidler)

More information about the irrtoolset mailing list