On Thursday, July 22, 2010 04:44:39 pm sth...@nethelp.no
wrote:
This and many other reasons means that we're not even
considering Juniper for the CPE role. We have some J
series routers in the lab, and they are staying at the
last non flow based version of JunOS.
IMO Juniper has royally
On Thursday, July 22, 2010 05:12:08 pm Pavel Lunin wrote:
But imho running things like full BGP,
Yes.
tons of IFLs with
queues,
Skip that.
thousands of IGP routes,
Yes.
label forwarding
states,
Skip that.
etc
Maybe
on J series is a little bit strange sort of
network design :)
On Thursday, July 22, 2010 06:50:00 pm Heath Jones wrote:
Out of curiosity, how many people here are thinking of
(or have changed to) another vendor??
Because of this, we exclusively use Cisco's 7201 as a route
reflector. It's cheap, has a much smaller OS footprint in
RAM after boot, and
Richard,
I agree with the idea that Juniper made a one-way decision and the customers
who used packet J series were cheated. At least they feel they are cheated.
And when Juniper announced packet JUNOS deprecation, it was obvious the
customers will feel cheated, despite the fact Juniper actually
On Fri, Jul 23, 2010 at 11:03:18AM +0400, Pavel Lunin wrote:
But excuse me. The way we discuss it here reminds me those teenager-style
web-forums where they have been talking 'windows-must-die' for last 15
years. Everyone just thinks it's his duty to claim 'junos is so buggy, so
buggy! I am
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add, please file jtac cases.
On Fri, Jul 23, 2010 at 11:03:18AM +0400, Pavel Lunin wrote:
But excuse me. The way we discuss it here reminds me those teenager-style
web-forums where they have been
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?
Route reflector.
Didn't you tested J4350/4350 or SRX650 with 2 Gigs of RAM and filters
which block full table from RIB-FIB
On 23 July 2010 08:03, Pavel Lunin plu...@senetsy.ru wrote:
But excuse me. The way we discuss it here reminds me those teenager-style
web-forums where they have been talking 'windows-must-die' for last 15
years. Everyone just thinks it's his duty to claim 'junos is so buggy, so
buggy! I am
Hey Heath
I assume you met the stripper in a... supermarket in the Whisky drinks
section ...;-)
She might even have a stripper friend called Cisco with whom she doesn't get
along with ;-)
On 23 July 2010 10:41, Heath Jones hj1...@gmail.com wrote:
On 23 July 2010 08:03, Pavel Lunin
I live my life by some simple rules:
1) never work for a employer that keeps his pets in the office. Bad
experience with a pygmy goat and a summer job
2) When a conversation mixes networking and sexual innuendo you know
it has gone awry..
Although there has been no mention of constrained
On Friday, July 23, 2010 05:34:15 pm Pavel Lunin wrote:
Didn't you tested J4350/4350 or SRX650 with 2 Gigs of RAM
and filters which block full table from RIB-FIB export?
No, we never did test them for this role because:
- When we wanted to, the J-series only supported 1GB
of
Once upon a time, Pavel Lunin plu...@senetsy.ru said:
I agree with the idea that Juniper made a one-way decision and the customers
who used packet J series were cheated. At least they feel they are cheated.
As far as I'm concerned, the J-series ROUTERS are already past end of
sale and will be
Florian,
We tried to enable MPLS (which is not really advertised as a way to
disable flow-based processing, BTW),
You are not right. It is well documented:
Although there has been no mention of constrained shortest paths or
back door routes I feel the thread is straying into rock ground ;-)
Exactly! Much more interesting than if you just vowed to be unfaithful
to Juniper with Cisco :)
___
juniper-nsp
3. The issues raised below (I didn't realize this myself ) about sessions
destined to the router still being processed as flow mode,
down TCP sessions under certain circumstances.
Does anyone have a proof link for this?
This is based on:
Make sure to configure host-bound TCP
On Friday, July 23, 2010 06:43:11 am Richard A Steenbergen
wrote:
In theory there isn't necessarily anything wrong with
this idea... But in practice JUNOS-ES is still very
buggy and can't be turned into a complete replacement
for the original JUNOS on the J-series. People don't
like it
* Leigh Porter:
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to the documentation, there is no way around that.
It means that all existing
Oh... Would anybody mind telling me why this was a good idea?
--
Leigh
* Leigh Porter:
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to the documentation, there is no way around that.
It means that all existing TCP sessions
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
On 21 Jul 2010, at 23:28, Nilesh Khambal wrote:
I am not a J-Series person and don't know much about flowd operation but
does the memory utilization come down when you reboot the router after
disabling the flow mode?
You can't disable it completely, it needs to remain on for packets destined
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
Once upon a time, Pavel Lunin plu...@senetsy.ru said:
It is also normal since J series became firewalls.
Yeah, but I bought J-series routers, not firewalls.
If you believe you really
need this, why not to stay at old good 9.3 packet-based JUNOS?
And when Juniper stops supporting that
Hi Heath,
I share your emotions, bloody capitalists are a burden to working-class
(joke). But the problem is that there are not so many exceptions. If you
know some, please let me know :)
Another problem is that customers are also not ideal. Many of them very
often want to run something
* Leigh Porter:
I thought that as soon as you turn MPLS on the flow mode was diabled
and you were back to good old packet mode?
No, packets targeted at the device itself are still processed in flow
mode. According to the documentation, there is no way around that.
It means that all
IMO Juniper has royally screwed up in the small router/CPE market.
One can hope that they won't perform similar stunts on the M/MX/T
series.
There's absolutely no reason why this would be considered. The fact that you
would make that statement leads me to believe that people might not
Chris,
Thanks for your feedback.
However I think it does not address the following points:
1. Memory consumption increased by flow mode even if the router
reverts to packet mode the pre allocation is not released.
2. Upgrade from packet mode version to flow mode version locks you out
of the
IMO Juniper has royally screwed up in the small router/CPE market.
One can hope that they won't perform similar stunts on the M/MX/T
series.
There's absolutely no reason why this would be considered. The fact that you
would make that statement leads me to believe that people might not
Chris,
The discussion is about J series routers, not SRXs.
The J series are marketed as routers not security devices and turning
them to security devices all of a sudden is a decision I still don't
understand.
If you want to open a discussion about SRX we can do that.
I have no experience
Fair enough.
I personally don't have answers to those questions but I'll do what I can to
make sure they get answered in the next day or two.
Thanks, Chris
On 7/22/10 12:19 PM, Amos Rosenboim a...@oasis-tech.net wrote:
Chris,
Thanks for your feedback.
However I think it does not address
3. The issues raised below (I didn't realize this myself ) about sessions
destined to the router still being processed as flow mode, which can tear
down TCP sessions under certain circumstances.
Does anyone have a proof link for this? I've just checked a J series running
10.0R2 packet-mode
Hi Chris,
The entire SRX product line (branch and high-end) covers the performance
spectrum across M and MX series but were created specifically as
purpose-built security devices and therefore should be implemented as such.
Let me clarify the claim a little bit. The problem is that by the
)
What happened?
--
Leigh
-Original Message-
From: juniper-nsp-boun...@puck.nether.net on behalf of Chris Whyte
Sent: Thu 7/22/2010 8:59 PM
To: Amos Rosenboim
Cc: juniper-...@punk.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add
Chris I think you've hit the nail on the head here.. In my experience
communication from Juniper is, exactly that. Simplex mode only.
Any opening up of channels and getting the message from customers
and 'partners' back into Juniper is greatly appreciated!
Cheers
On 22 July 2010 20:59, Chris
On Fri, Jul 23, 2010 at 12:27:21AM +0400, Pavel Lunin wrote:
Let me clarify the claim a little bit. The problem is that by the
moment when Juniper decieded to close old good packet branch for J and
rename JUNOS ES to just JUNOS for J series (we all know this was
actually done mainly to
-nsp-boun...@puck.nether.net on behalf of Jay Hanke
Sent: Tue 7/20/2010 11:26 PM
To: 'Christopher E. Brown'; juniper-...@punk.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add, please file jtac cases.
Ditto, I was writing basically
. Brown; juniper-...@punk.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory
useincrease with flow mode add, please file jtac cases.
I don't suppose this trick works on the SRX as well? *grin*
-Shane
On 21/07/2010, at 2:54 PM, Leigh Porter wrote:
I thought that as soon
by the massive memory
useincrease with flow mode add, please file jtac cases.
Just a quick thought... what about renaming the flowd binary..?
No I haven't tested it :)
On 20 July 2010 23:14, Christopher E. Brown
chris.br...@acsalaska.netwrote:
I know alot of us here have been bitten
Just a thought. If this bothers you guys so much, start looking at other
vendors. The only way to get juniper motivated to fix things is to hurt
them financially as they don't seem to care what their existing customers
want imho.
On Jul 21, 2010 6:25 AM, Leigh Porter
Chris I have to agree with you there. Its even worse on the 'partner' side
of things.. You customers get informed more than we do (let alone listened
to)!!
To be fair though, a lot of vendors are like this nowadays.
If anyone is interested in forming a vendor that cares about (and
communicates
Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Heath Jones
Sent: 21 July 2010 11:51
To: Chris Evans
Cc: juniper-...@punk.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add
@puck.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add, please file jtac cases.
On the back of this I have a j6350 running 10.0R3.10 and am using for some
bgp and ospf.
Is the best guide to following to move from flow to packet-based this
http
...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Wednesday, July 21, 2010 7:51 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add, please file jtac cases.
On the back of this I have a j6350 running 10.0R3.10 and am using
On 7/20/10 10:54 PM, Leigh Porter wrote:
I thought that as soon as you turn MPLS on the flow mode was diabled and
you were back to good old packet mode?
--
Leigh
Is puts things in packet mode, but all of the memory pre-allocs to
support flow mode remain in play.
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,
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
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.br...@acsalaska.netwrote:
On 7/21/2010 12:48 PM, Heath Jones wrote:
I think you should actually give the renaming of
On 7/21/2010 12:34 PM, Smith W. Stacy wrote:
On Jul 21, 2010, at 12:35 PM, Christopher E. Brown wrote:
On 7/20/10 10:54 PM, Leigh Porter wrote:
I thought that as soon as you turn MPLS on the flow mode was diabled and
you were
back to good old packet mode?
-- Leigh
Is puts things in
On 7/21/2010 6:09 AM, Jay Hanke wrote:
After implementing the procedure did you see a drop in memory utilization?
If so, how much?
jay
No reduction *AT ALL*, that is the issue.
Turning off flow mode does not free the pre-alloced memory used to support flow
functions.
On 7/21/2010 1:23 PM, Heath Jones wrote:
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
-
From: juniper-nsp-boun...@puck.nether.net on behalf of Christopher E. Brown
Sent: Wed 7/21/2010 10:59 PM
To: Heath Jones
Cc: juniper-...@punk.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease
with flow mode add, please file jtac cases.
On 7/21/2010 1:23 PM
a tad off-topic .. but who's idea was it to send at
juniper-...@punk.nether.nethttp://k.nether.net in stead of puCk. Didn't know
that was even valid?
was playing havoc with mail-rules over here, didn't catch it at first.
I hereby changed it back to puck.nether.nethttp://puck.nether.net
br,
On 7/21/2010 2:28 PM, Nilesh Khambal wrote:
I am not a J-Series person and don't know much about flowd operation but
does the memory utilization come down when you reboot the router after
disabling the flow mode?
How does the flowd memory stats looks like in show system processes
extensive
53 matches
Mail list logo
