maximum ipv4 bgp prefix length of /24 ?

Fri Sep 29 20:43:09 UTC 2023

On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti <saku at ytti.fi> wrote:
> On Fri, 29 Sept 2023 at 08:24, William Herrin <bill at herrin.us> wrote:
> > Maybe. That's where my comment about CPU cache starvation comes into
> > play. I haven't delved into the Juniper line cards recently so I could
> > easily be wrong, but if the number of routes being actively used
> > pushes past the CPU data cache, the cache miss rate will go way up and
> > it'll start thrashing main memory. The net result is that the
> > achievable PPS drops by at least an order of magnitude.
>
> When you say, you've not delved into the Juniper line cards recently,
> to which specific Juniper linecard your comment applies to?

Howdy,

My understanding of Juniper's approach to the problem is that instead
of employing TCAMs for next-hop lookup, they use general purpose CPUs
operating on a radix tree, exactly as you would for an all-software
router. This makes each lookup much slower than a TCAM can achieve.
However, that doesn't matter much: the lookup delays are much shorter
than the transmission delays so it's not noticeable to the user. To
achieve an -aggregate- lookup speed comparable to a TCAM, they
implement a bunch of these lookup engines as dedicated parallel
subprocessors rather than using the router's primary compute engine.

A TCAM lookup is approximately O(1) while a radix tree lookup is
approximately O(log n). (Neither description is strictly correct but
it's close enough to understand the running time.) Log n is pretty
small so it doesn't take much parallelism for the practical run time
to catch up to the TCAM.

Feel free to correct me if I'm mistaken or fill in any important
details I've glossed over.

Regards,
Bill Herrin

--
William Herrin
bill at herrin.us
https://bill.herrin.us/