On Sun, Oct 11, 2020 at 04:29:32PM +0800, Wang Shanker wrote:
Hi, all
I recently spotted when filters used with recursive static routes can sometimes fail to work. The minimum case for reproducing this issue is as follows:
Suppose in routing table `tab2`, we want the nexthop of 2001:db8::/32 follows 2001:db8::1 in table `tab1`, only when 2001:db8::1 is reachable. Hence, a filter rejecting unreachable routes is used. In `tab1`, a static protocol `s1` is used to emulate the routing changes there. In actual scenario, the nexthop of 2001:db8::1 may be decided by more complex routing protocols.
It seems that the changed route does not going through the filter and failed to be injected into table `tab2`. This also happens when the route is available at start and is withdrawn later.
Hi (Noticed while looking for some missed / forgotten e-mails) This is more or less expected behavior because recalculation of recursive routes is done in routing tables, not in source protocols. The ugly issue is that import filter may access dependent properties (like immediate gw) and use their initial values. If import filters were re-evaluated after change of recursive nexthops, they may reject the route, route would be removed, and (in case of BGP, who does not keep separate copy of routes propagated to the routing table) could not re-appear again after another change as it would no longer be in the system. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."