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

[Heath Jones]

Cheers for the insight Pavel - sounds like you have been on this one for a
while..
I'm just curious about the cash people actually have to spend on
routers/firewalls these days. All the providers (especially small/mid sized
ones) I have dealt with are trying to remain competitive in a really
challenging and changing market, they just cannot afford to worry about
changing their network infrastructure at the rate (or price) the vendor
wants. Juniper seems to me to be treating their products as if they are
almost consumables - like a mobile phone that you discard and replace every
year or 2. Networks cannot follow this commercial trend and still remain
reliable - maybe it's just my pessimistic side, but I think we are already
seeing too many outages, security flaws and other problems resulting
from cut corners on development and testing due to allocation of less
resources.

Theres a lot of top shelf gear that costs a fortune, theres a lot of low end
shit. Perhaps there is room in the middle for a reasonably priced product
that does the job well, without all the bells and whistles, but is actually
reliable.

As far as the forwarding information for flows, its probably a single chunk
of memory containing an array of structs. Each struct would represent an
individual flow and its state etc.
How hard really is it to add a config item to specify the number of flows in
that array? It will involve finding the statically set array length parts &
functions and changing them accordingly to use the value from the config or
default value if unset. Its a couple of hours work maximum. I dont think it
was a design feature at all as SE's claim. No engineer in their right mind
would force that much memory to a task that might not even be used.

Out of curiosity, how many people here are thinking of (or have changed to)
another vendor??

H








On 22 July 2010 10:12, Pavel Lunin <plunin at senetsy.ru> wrote:

> 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
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>