[j-nsp] MX80 Route table Size

Amos Rosenboim amos at oasis-tech.net
Tue Sep 24 10:33:31 EDT 2013


To add on Nitzan's comment(we work together):
When everything is stable all is good.
But bounce a full table BGP session, and than bounce an IGP adjacency and you are in a lot of trouble.
This seems to be a combination of the (in)famous Junos software issue described extensively by RAS and a processor that is so slow that makes the software issue appear in much smaller environment than what is described by RAS.
Having said all this, run it with few thousands routes and it's a beast.
I think this box really changed the game for many small ISPs.

Cheers

Amos

Sent from my iPhone

On 24 Sep 2013, at 17:21, "Nitzan Tzelniker" <nitzan.tzelniker at gmail.com<mailto:nitzan.tzelniker at gmail.com>> wrote:

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<mailto: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<mailto: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<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp


More information about the juniper-nsp mailing list