[j-nsp] jtree0 Memory full on MX480?

[Jeff Meyers]

Hi,

thanks for the hint, didn't know about that option. This will certainly 
safe us if we are running in to limits. We don't have too many filters, 
mostly the basic stuff to protect the RE and a few filters on some vlans 
with basic white- and/or blacklisting. So really nothing fance although 
I have no idea mow many "many" filters are on a box like the MX. Is it 
1,000 terms or more like 1,000,000 terms?


Best,
Jeff

Am 22.07.2015 um 13:06 schrieb Ivan Ivanov:
> Hi,
>
> The 'route' option on 'memory-enhanced' will give you some time before
> upgrade to MPC. Actually you should be okay for quite a long time
> considering the size of the table you have at the moment.
>
> https://www.juniper.net/documentation/en_US/junos11.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html
> <https://www.juniper.net/documentation/en_US/junos11.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html>
>
> Note, that this will use the part of the memory reserved for filters
> (Jtree segment 1) for storing route information. You that feature only
> if don't have many filters configured.
>
> Ivan,
>
>
> On Wed, Jul 22, 2015 at 7:52 AM, Mark Tinka <mark.tinka at seacom.mu
> <mailto:mark.tinka at seacom.mu>> wrote:
>
>
>
>     On 22/Jul/15 02:59, Chris Kawchuk wrote:
>     > I know that a ton of fixes on BGP convergence time son MX80 is definitely a reason to be 'moving up'... however as you're on RE-2000s on MX480 may not be applicable.
>     >
>     > I see you're running DPC cards, have you considered shifting those links onto an MPC/Trio Card? (newer chip, more RAM, more horsepower, yadda yadda yadda =)..) DPC was EOL a while ago, and everything has been Trio (and now Trio-NG on the new -NG cards coming out now). As the FIB is pushed to hardware, it may be some silly DPC thing you're running into.
>     >
>     > For things like Fusion or BNG or any other new/advanced/this-is-what-PLM-is-thinking functions, we're already putting in 14.2 on any new device we turn up, and have already started testing 15.1 for the new NG cards we will likely be buying. Rest of our network is now on 12.3R8 or 13.3 in many cases. (lots of BFD bugs have been squashed, some HQoS issues fixed, host-outbound-traffic for BFD keepalives now honour the c-o-s knobs, and are finally out of Queue 3 and into the Queue we want (7), etc... preventing starvation if you happen to have re-used Queue 3 as "not-so-high" priority, etc)... the list goes on.
>     >
>     > It's not a case of "if it aint broke, don't fix it" once you get 4-5 years behind. You'll benefit from the years of "Oh, we finally fixed LLDP ascii decoding" stuff that ends up getting traction; plus JTAC would really really like it if you weren't on 11.4 =)
>
>     We've been on 14.2 for a while now, and settling into 14.2R3.8.
>
>     Happy, to be honest. Only real problem is policing on LAG's, but it's
>     manageable.
>
>     Mark.
>     _______________________________________________
>     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
>
>
>
>
> --
> Best Regards!
>
> Ivan Ivanov