JunOS filter list ordering issue
Ruediger Volk, Deutsche Telekom T-Com - TE141-P1
rv at NIC.DTAG.DE
Sun Jan 31 22:25:48 UTC 2010
> I'm getting increasingly rusty about this, but as far as I remember
> there was an issue with JunOS filter lists due to eg:
> 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
(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.
> 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.
Since I hit the problem a couple of years ago and the vendor pointed
me to the relevant documentation page I'm not expecting that they CAN
CHANGE semantics there; introducing a configuration option that is
"cleaner" of course cannot be impossible - and if there is a reasonable
way to sort filters customers sure would appreciate that in the vendor's
> spz at serpens.de (S.P.Zeidler)
We'd have to check how easy and clean it is to separate the JunOS
prefix filter generator from our version to patch into 5.0.0.
(I'd expect easy and clean - but I did manage rather than code this...)
More information about the irrtoolset