[j-nsp] jtree0 Memory full on MX480?

[Ivan Ivanov]

Hi,

The size of the firewall configuration could be concern if you use the box
for subscriber management and have tons of dynamic interface with filters
attached. Otherwise you should be safe to use that knob.

At the moment you have 11.5MB in segment 1, when you enable that know it
will go down to 6MB or 7MB. And you will be able to accommodate two full
feeds in the FIB.

11650408 bytes available (11609600 bytes from free pages)

I would recommend to check for any know PR using that feature with 11.4

Ivan,



On Wed, Jul 22, 2015 at 4:31 PM, Jeff Meyers <Jeff.Meyers at gmx.net> wrote:

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


-- 
Best Regards!

Ivan Ivanov