Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG <nanog () nanog org>]

> On Sep 29, 2023, at 14:48, William Herrin <bill () herrin us> wrote:
>
> On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher <beecher () beecher cc> wrote:
> > > 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.
> >
> > Absolutely are not doing that with "general purpose CPUs".
> >
> > The LU block on early gen Trios was a dedicated ASIC (LU by itself, then consolidated slightly) , then later gen 
> > Trio put everything on a single chip, but again dedicated ASIC.
>
> Hi Tom,
>
> For clarity, general purpose CPU refers to an architecture not an
> implementation. It's capable of running arbitrary computer software
> and has the typical functions like loading and saving registers, an
> adder, bit shifts, etc. The CPU in a Raspberry Pi is also part of a
> dedicated ASIC that does wifi, packet switching and a bunch of other
> stuff. It's still a CPU. Compare to a TCAM which is purpose built to
> match input bit patterns and is capable of nothing else.
>
> I suppose the PPEs in the Trio are more like GPUs than CPUs - more
> limited instruction sets but higher parallelism. However, they still
> follow the cache pattern where the frequently used parts of the FIB
> tree are in a fast SRAM cache and the remainder is in slower DRAM
> where it can be loaded into SRAM at the occasional need. The FIB size
> limit before cache thrashing sets in and cuts the PPS is softer than
> the limit with a TCAM but it's still there.

You continue to assume that there is a fast SRAM cache. I’m not sure
that is true. I think that all of the FIB RAM on the line cards is fast SRAM
and no cache.

Owen