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 <s...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp