On Oct 2, 2023, at 01:18, Nick Hilliard <nick@foobar.org> wrote:
William Herrin wrote on 02/10/2023 08:56:
All it means is that you have to keep an eye on your FIB size as well, since it's no longer the same as your RIB size.
the point Jacob is making is is that when using FIB compression, the FIB size depends on both RIB size and RIB complexity. I.e. what was previously a deterministic 1:1 ratio between RIB and FIB - which is straightforward to handle from an operational point of view - becomes non-deterministic. The difficulty with this is that if you end up with a FIB overflow, your router will no longer route.
It was never 1:1 if you have more than one path for any route. The FIB only contains the chosen path(s) to any destination even without fib compression.
That said, there are cases where FIB compression makes a lot of sense, e.g. leaf sites, etc. Conversely, it's not a generally appropriate technology for a dense dfz core device. It's a tool in the toolbox, one of many.
Even at a dense DFZ core device, there are a large number of single-origin consecutive /24s in the table which can be fib compressed with no loss. For a long time, someone was teaching up and coming operators in Asia that they should always announce everything as disaggregated /24s to guard against route hijacking. This unfortunate practice persists still, making FIB compression quite practical even at core nodes. Owen
Nick