recursive static routes

recursive static routes

[Saku Ytti]

I believe Linux does not support recursive static routes, is this correct?

If so, do we not see the use-case or is it just lacking quality
implementation which would be accepted if such is presented?

Just to elaborate on one use case. Consider your Linux host has two
BGP upstreams, you advertise your loopback/32 prefix and you receive
something. Let's say you at least receive 192.0.2.0/24 from both BGP
sessions.
Now you probably would like to do something like

'ip route add 0.0.0.0/0 via 192.0.2.0 src lo'

But this won't work, as we do not recurse 192.0.2.0 to where ever it
may point at any given time.

Why would you do this, instead of receive 0.0.0.0/0 from upstream? For
one, you can set the 'src' parameter. And another, typical upstream
generates 0.0.0.0/0 locally, so even if upstream device is isolated
from network, it will continue to advertise 0.0.0.0/0 and blackhole
your traffic. If you choose your prefix towards which you
default-route, you can choose something which is more representative
of functioning Internet from your POV.



This is typical feature supported by IOS, IOS-XE, IOS-XR, JunOS, SROS,
VRP and so forth. Some of them support it by standard without any
additional toggle, another, like JunOS requires that you define
specifically which static routes are recursed, in JunOS the keyword
used is 'resolve'. But commonly the functionality is known as
'recurse', so if iproute2 were to need verb for this, 'recurse' would
be preferred over 'resolve'.


-- 
  ++ytti

Re: recursive static routes

[David Ahern]

On 3/19/18 1:42 AM, Saku Ytti wrote:
> I believe Linux does not support recursive static routes, is this correct?

The Linux stack does not flatten routes when inserting into the FIB.
Recursion is expected to be done a routing daemon such as bgp which will
be able to handle updates as the network changes.

I have thought about adding such a feature to the stack, basically have
the gateway recomputed on link changes. It would most certainly not be
as robust as having the updates come from a routing daemon.

Any solution would need to handle encapsulations (e.g., MPLS) which is
one area it gets complicated fast.

Re: recursive static routes

[Saku Ytti]

Hey David,

> The Linux stack does not flatten routes when inserting into the FIB.
> Recursion is expected to be done a routing daemon such as bgp which will
> be able to handle updates as the network changes.

Are you saying that routing protocol would observe the next-hop
change, then update the Linux kernel route to reflect that?

Wouldn't that add another layer of state and the implied delays of
maintaining and updating the state.

Is it not practical to do lookup per-packet to recurse until egress
rewrite information is found? So literally no state in memory anywhere
saying 0/0 next-hop is 192.0.2.42/22:22:22:22:22:22, it would always
have to walk the FIB to find it.

--
  ++ytti

Re: recursive static routes

[David Ahern]

On 3/19/18 12:58 PM, Saku Ytti wrote:
> Hey David,
> 
>> The Linux stack does not flatten routes when inserting into the FIB.
>> Recursion is expected to be done a routing daemon such as bgp which will
>> be able to handle updates as the network changes.
> 
> Are you saying that routing protocol would observe the next-hop
> change, then update the Linux kernel route to reflect that?

yes

> 
> Wouldn't that add another layer of state and the implied delays of
> maintaining and updating the state.
> 
> Is it not practical to do lookup per-packet to recurse until egress
> rewrite information is found? So literally no state in memory anywhere
> saying 0/0 next-hop is 192.0.2.42/22:22:22:22:22:22, it would always
> have to walk the FIB to find it.
> 

you want per-packet overhead instead of deferring the overhead event
based updates? network events tend to be much less frequent than
sending/forwarding packets.

Re: recursive static routes

[Saku Ytti]

Hey,

> you want per-packet overhead instead of deferring the overhead event
> based updates? network events tend to be much less frequent than
> sending/forwarding packets

Depending on performance cost and complexity cost of options.

-- 
  ++ytti