[j-nsp] MX80 Route table Size

[Paul Stewart]

Not to hi-jack this thread but does anyone know *real-world* numbers yet
on the MX104 RE?  I know it has more memory and is supposed to be "faster"
but have no idea yet how much faster it really is?

We don't have any in our network yet but anxious to deploy one end of
year...

Thanks for any input...

Paul



On 2013-09-24 10:40 AM, "Krasimir Avramski" <krasi at smartcom.bg> wrote:

>We are aware ppc on mx80 is slower than intel REs... but the original
>question was for scalability not for performance/convergence.
>Take a look at newer MX104 for more RE performance.
>
>Krasi
>
>
>On 24 September 2013 17:18, Nitzan Tzelniker
><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>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/configuratio
>>>n/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
>>>
>>
>>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp