[j-nsp] MX80 Route table Size

Nitzan Tzelniker nitzan.tzelniker at gmail.com
Tue Sep 24 10:18:37 EDT 2013


Hi,

The problem with the MX80 is not the FIB size but the slow RE
The time it take to receive full routing table is long and to put it into
the FIB is even worst

Nitzan


On Tue, Sep 24, 2013 at 10:21 AM, Krasimir Avramski <krasi at smartcom.bg>wrote:

> 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
> >
> _______________________________________________
> 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