[j-nsp] MX80 Route table Size
Krasimir Avramski
krasi at smartcom.bg
Tue Sep 24 03:21:10 EDT 2013
Agree.. other elements like counters, filters, descriptors etc .. but it is
dynamic allocation which isn't the case with ichip - 16M bank for
firewalls , 16M for jtree with fixed regions. Although there is a
workaround(
http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html)
for
ichip I am calculating the worst case scenario with unique inner vpn label
usage with composite nexthops.
Best Regards,
Krasi
On 24 September 2013 09:40, Saku Ytti <saku at ytti.fi> wrote:
> On (2013-09-24 08:49 +0300), Krasimir Avramski wrote:
>
> > Ichip(DPC) has 16-32M RLDRAM and holds 1M routes in FIB, so 256M on trio
> is
> > huge increment - it is in realm of ~5M routes(since they use dynamic
> memory
> > allocation to fill up with routes only) and more than 1M labeled prefix
>
> I don't think this is apples to apples. The 16MB RLDRAM is just for jtree,
> while 256MB in trio has lot more than just ktree, and some elements are
> sprayed across the 4*64MB devices which make up the 256MB RDLRAM.
>
> I'd be quite comfortable with 2M FIB throughout the lifecycle of current
> generation, but I've never heard JNPR quote anything near this for trio
> scale.
>
> I'm not sure I either understand why it matters if route is labeled or
> not, if
> each route has unique label, then it means you're wasting NH space, but if
> you
> are doing next-hop-self and advertising only loopback labels, then I don't
> think labeled route should be more expensive.
> (NH lives in RLDRAM in Trio as well, and I believe it specifically is
> sprayed
> across all four RLDRAM devices).
>
> --
> ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list