Denying routes in install filter doesn't work

[DanielG]

When I have something like this:

install ip 2001:0db8::/48 allow
install deny

babled still installs routes received from neigbours outside of the given prefix into the kernel. I'm sending routes to a different table as a workaround but this shouldn't be necessary. Right?

install ip 2001:0db8::/48 allow
install table 666

Incidentally the routes that should be going to table 666 don't seem to show up there which is weird but I don't care about:

# ip -6 route show table 666
Error: ipv6: FIB table does not exist.
Dump terminated

--Daniel

[jech]

I'm a little confused about the use case for this. If the routes are unwanted, they should be filtered away in the in filter. Reannouncing a route without installing it is not correct, it may cause persistent routing loops.

[jech]

Fixed in f9b504b. It's probably not the semantics you would want, but it's safe (doesn't cause routing loops).

[DanielG]

Hmm, I didn't consider the problem with routing loops in this case. Perhaps install filters should just refuse to deny routes then? We could simply emit a warning and document this restriction.

[jech]

I've simply reused the code that deals with kernel failures. If the kernel rejects a route, we print a warning and do not reannounce the route (it would be unsafe to reannounce a route that hasn't been installed); we will then attempt installing the route again after a few seconds, which causes a new warning to be printed, ad nauseam. THis is safe, but not necessarily useful for you.

If you have a good use case for rejecting routes in the install chain, please describe it (preferable on the mailing list), and we'll work out together a safe way to achieve what you need.

[DanielG]

Ah, that's fine then. I don't have a compelling use-case, was just using the wrong filter :)

[DanielG]

Now having said that ofc. I just found a use case that is going to be broken by the behavior you describe >)

I'll write something up for the ML when I have some time.