JunOS filter list ordering issue
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 10.11.0.0/16 exact accept;
> > route-filter 10.11.0.0/17 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