[j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.

[Heath Jones]

Chris - Sorry I didnt realise the process had changed names and we are
actually talking about the forwarding process itself. In that case, the only
other thing I can think of right now is:
When the forwarding process starts, it allocates the 400Mb+ for these
tables. The question is if the forwarding process is making a decision based
on the configuration *before* the point of memory allocation as to if the
allocation is required.

This is what you need to know from Juniper engineers / dev team. It probably
wasn't written that way, and if not it makes searching for configuration
statements to achieve the goal pointless!!
(It's highly unlikely that they coded deallocation functions for those
structs. Much simpler to just restart a process..)

Please let me know how you go with this - its an interesting problem!





On 21 July 2010 21:54, Heath Jones <hj1980 at gmail.com> wrote:

> What is the process name? I thought on the J series it was the fwdd process
> or something similar that controlled forwarding.
>
>
> On 21 July 2010 21:52, Christopher E. Brown <chris.brown at acsalaska.net>wrote:
>
>> On 7/21/2010 12:48 PM, Heath Jones wrote:
>> > I think you should actually give the renaming of the binary a go. If you
>> > rename flowd (or name of process using memory), it wont be found and
>> > loaded on next boot. Obviously this is a hack and not what you want to
>> > be relying on in a production network, but if it solves the issue then
>> > good. That and hassle Juniper about a longer term solution.
>> >
>> > The other solution is to remove the statement that causes the daemon to
>> > load on boot, but I cant remember where that is and what loads it (init
>> > / rc?).
>> >
>> > Killing the process first will let you check if there are any other side
>> > effects.
>>
>>
>> The process is required for forwarding.  It can be disabled in the config,
>> but then all
>> routing stops.
>>
>>
>>
>> --
>> ------------------------------------------------------------------------
>> Christopher E. Brown   <chris.brown at acsalaska.net>   desk (907) 550-8393
>>                                                     cell (907) 632-8492
>> IP Engineer - ACS
>> ------------------------------------------------------------------------
>>
>
>