Allow abstraction of ECMP and Routes Installable

[donaldsharp]

Currently we have 2 ways of specifying ECMP

1. Via compilation of FRR
2. Via runtime specification

Let's add a 3rd ability to query the kernel( or relevant api ) for any underlying hardware abstraction

Then after we have this input. Choose the min of the 3 to use at run time

Also add the same thing for # of routes. Some hardware has a limitation on the # of routes that can be installed. Allow the code to smartly understand that.

[pguibert6WIND]

Hello,

unless i misunderstood, I do not agree with proposed solution.
I understand that if enable-multipath=64 is set by compilation, and bgpd command maximum-path 32 is chosen, and if the kernel support for multipath is 1, then that means that BGP global RIB does not support ECMP routes.

If this is the correct understanding, then I disagree. Unless the 3rd ability impacts only zebra. Meaning that BGP will still be able to handle ECMP routes in its global RIB.
Reason is that sometimes the Frr may be used as purely controlplane feature, not related to dataplane ( since openvswitch will be configured separately to configure the kernel stuff instead through a SDNc).

[riw777]

I think this might be in support of various chip set's ability to modify the next hop rather than just replace the entire route (?) -- what you'd need to know in this case is what the max number of next hops (ie the size of the ecmp group) is that the hardware chipset can support, so zebra doesn't overrun that number, and blow up the modification of the ecmp group at the hardware level.

How would zebra get this information, though? Is there an existing api in that direction (from sai, open nsl, or just flat out from the chip api)?

I could be all wrong in reading the bug by Donald, though -- so ignore me if I'm blathering nonsense. :-)

[donaldsharp]

So we have several issues here:

Hardware ECMP support
Kernel ECMP support
Zebra ECMP support

Currently there is no methodology to have any of these 3 layers know about what is supported under them.

Additionally one can use the zebra FPM manager to tell the hardware about the route, and bypass kernel installation altogether

What I am proposing here is the creation of a API where zebra can ask for the underlying ECMP supported and dissallow the exact situation you are concerned about above at the level of zebra.

I was going to write this code so that it was abstract enough that zebra just asks for total ECMP and whomever is programming for a particular piece of hardware can have zebra do the right thing. I could then write handlers for my hardware types and have them return the right thing.

Long term I would suggest that the Linux kernel needs to get an API where it could report on the underlying hardwares ECMP and then we could just write that bit of code to get it via a handler.