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

[Pavel Lunin]

Hi all,

> The issue is not that memory is being pre-allocated to the forwarding / flow process.
> This is expected and required to function.
>
> The issue is that when things switched to flow support the memory usage went *way* up, and
> even when you convert to packet mode it is not reduced.
>    
It is also normal since J series became firewalls. They allocate that 
hell of RAM for sessions table in order to be a stateful device. No 
problem with turning off the flow mode for all the box or per-interface, 
but it does not make the fwdd free the memory. Same story with SRX.

I have discussed this behavior with local SE about a year ago (just when 
packet JUNOS for J was depricated). They said developers are aware of 
this issue but it doesn't seem someone sees commercial reasons to spend 
money for changing this. The common story: «where is the market to sell 
this? etc».

 From the technical point of view I can say that an only case when this 
issue really matters, is when you want to run full BGP on J-series with 
1 Gig of RAM. E. g. If you have two feeds with full tables, when it 
comes to FIB population, rpd drops BGP sessions with "low memory 
reason". If you strip prefixes longer than, say, /21, it works well.

But imho running things like full BGP, tons of IFLs with queues, 
thousands of IGP routes, label forwarding states, etc on J series is a 
little bit strange sort of network design :) Upto 1Gbps performance (has 
anyone tested how 300k prefixes in FIB affect forwarding performance of 
J?) and things like this — you really need it? If you believe you really 
need this, why not to stay at old good 9.3 packet-based JUNOS?

BTW, seems like Juniper is not going to upgrade J series anymore. These 
boxes also have 512M flash card, which is too little even to upgrade 
JUNOS. Bulit-in IDP also requires at least 1Gig, etc. So they are just 
too old for these days. 2320/2350 are more expensive and have less 
performance than SRX240. J4350/6350 can be useful in some cases (quite 
specific ones) until Juniper doesn't announce something like SRX300/400/500.

--
Regards,
Pavel