Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 screwed up in the small router/CPE market. Have to agree - we were considering the J-series as a potential route reflector since JUNOS (AFAICT) is the only piece of networking code, today, that supports the MCAST-VPN BGP NLRI. But given that non-ES JUNOS on this platform would leave you without key features today, and that current code is all ES- based, requiring flow mode in some parts, it means we can't choose this box any longer (good thing we actually didn't buy any yet). That role would have to go to the M7i's. But since those only run 1.5GB on the RE (effectively less as JUNOS, itself, continues to grow), we can't let the router carry all AFI's. That would be the job of another vendor's platform, while JUNOS only handles MCAST-VPN. Sad. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 :) 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. If you believe you really need this, why not to stay at old good 9.3 packet-based JUNOS? Because it won't have some of the features only available in later code, which - wait for it - is ES-only. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 runs a pretty advanced piece of BGP + IS-IS code. As for CPE, Cisco's ISR have made more sense than Juniper's J-series, as other folk have already mentioned. Juniper's lack of a decent box that can play route reflector is what has kept it out of our network for this role. Yes, the M120 is probably the smallest box you can get with 4GB of RAM, but seriously? Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 was not really marketing J series as an ISP oriented router (I remember the recommended scaling number for packet 9.3 was about 300k routes in RIB). But lots of customers did it and Juniper could have cared of them, really. 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 going to buy cisco! Do you hear? I am going to buy cisco!' I think, almost everyone here picks the best (in his opinion) products of different vendors, isn't it normal? Let's be honest, people in cisco-nsp have not less reasons to turn the list into a holy-war platform, but they manage to not. Yeah, this is much more interesting sort of discussion than talks about networking, but why not just move to discussing girls or, I don't know, whisky? This is even more interesting and we could use even more familiar style. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 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 going to buy cisco! Do you hear? I am going to buy cisco!' I think, almost everyone here picks the best (in his opinion) products of different vendors, isn't it normal? Let's be honest, people in cisco-nsp have not less reasons to turn the list into a holy-war platform, but they manage to not. As I've said before, he reason it's so disappointing to see what has become of JUNOS is that it used to be so much better by comparison. I have nothing against Juniper, I love Juniper, and I'm very VERY sad that I've somehow found myself running IOS lite. I'm still buying Juniper products, and I'm still hopeful that things will get better, but the very real and objective facts are that a) Juniper left J-series in a broken and in many cases unusable state before they abandoned development, and b) they screwed a lot of customers in the process. Eventually they will run out of goodwill and start losing business because of it, and that kind of thing can be very hard to undo. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I am afraid they have already lost business because of the J-series. I will certainly not buy any more. -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Richard A Steenbergen Sent: Fri 7/23/2010 9:05 AM To: Pavel Lunin 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 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 going to buy cisco! Do you hear? I am going to buy cisco!' I think, almost everyone here picks the best (in his opinion) products of different vendors, isn't it normal? Let's be honest, people in cisco-nsp have not less reasons to turn the list into a holy-war platform, but they manage to not. As I've said before, he reason it's so disappointing to see what has become of JUNOS is that it used to be so much better by comparison. I have nothing against Juniper, I love Juniper, and I'm very VERY sad that I've somehow found myself running IOS lite. I'm still buying Juniper products, and I'm still hopeful that things will get better, but the very real and objective facts are that a) Juniper left J-series in a broken and in many cases unusable state before they abandoned development, and b) they screwed a lot of customers in the process. Eventually they will run out of goodwill and start losing business because of it, and that kind of thing can be very hard to undo. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 export? How many routes it is capable to hold as a RR with no full table in FIB? Both flow and packet JUNOS. I'm not saying this the ideal solution (7200 seems to be more interesting), but if someone tested this, would be nice to hear. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 going to buy cisco! Do you hear? I am going to buy cisco!' I think, almost everyone here picks the best (in his opinion) products of different vendors, isn't it normal? Let's be honest, people in cisco-nsp have not less reasons to turn the list into a holy-war platform, but they manage to not. Perhaps the thread has gone a bit that way, but I think its genuine built up frustration. I don't think this is just tea-room bitching. Many people on here have a financial stake in their smaller businesses, so it really does effect them personally. I think that is probably why its a bit more heated here. Yeah, this is much more interesting sort of discussion than talks about networking, but why not just move to discussing girls or, I don't know, whisky? This is even more interesting and we could use even more familiar style. I met a stripper once called Jupiter... she liked whisky. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 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 going to buy cisco! Do you hear? I am going to buy cisco!' I think, almost everyone here picks the best (in his opinion) products of different vendors, isn't it normal? Let's be honest, people in cisco-nsp have not less reasons to turn the list into a holy-war platform, but they manage to not. Perhaps the thread has gone a bit that way, but I think its genuine built up frustration. I don't think this is just tea-room bitching. Many people on here have a financial stake in their smaller businesses, so it really does effect them personally. I think that is probably why its a bit more heated here. Yeah, this is much more interesting sort of discussion than talks about networking, but why not just move to discussing girls or, I don't know, whisky? This is even more interesting and we could use even more familiar style. I met a stripper once called Jupiter... she liked whisky. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Humair ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 shortest paths or back door routes I feel the thread is straying into rock ground ;-) Phill On Fri, Jul 23, 2010 at 12:34 PM, Heath Jones hj1...@gmail.com wrote: I assume you met the stripper in a... supermarket in the Whisky drinks section ...;-) Definately, its the best place to pick up women - a girl's gotta eat! She might even have a stripper friend called Cisco with whom she doesn't get along with ;-) You must be thinking of disco cisc-ho, her pimp.. :) Anyway... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Phill Jolliffe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 DRAM maximum. That didn't bode well with us :-). - When 2GB came out, the size of JUNOS was a little scary, compared to IOS. - Then JUNOS for the J-series moved to JUNOS-ES, and this was the final nail in the coffin for us. (7200 seems to be more interesting), but if someone tested this, would be nice to hear. 7201 is a much better solution for this role, IMHO. Form factor is great. CPU power is great. Feature set is great. It only does 2GB today, but I'm talking to Cisco about whether they can provide a 4GB or greater option (whether I'm successful is actually another issue). However, Cisco's RP2 for the ASR1004/6 can do 16GB today. But for now, it's sort of like buying an M120 for route reflection - too powerful. But what can you do? It's either that or Quagga/Zebra. Even if Juniper came out with a large control plane (DRAM- wise), there's no box small enough to plug it into at the moment. Yes, the M7i is tiny, but I'm rather apprehensive about any new RE's being developed for this platform. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 end of life before too long (when JUNOS 9.3 is EOL). The smallest actual router is back to being the M7i. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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:
http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-admin-guide/secure-routing-context-chapter.html#secure-routing-context-chapter
but the device still couldn't
forward our tiny amount of traffic we deal with.
IDK. We support several J in production, configured like this:
plu...@router show configuration security forwarding-options
family {
inet6 {
mode packet-based;
}
mpls {
mode packet-based;
}
iso {
mode packet-based;
}
}
Here is what they do.
plu...@router show route summary
Autonomous system number: xxx
Router ID: xxx
inet.0: 324700 destinations, 390767 routes (153306 active, 0 holddown,
171394 hidden)
Direct: 4 routes, 4 active
Local: 3 routes, 3 active
OSPF: 4 routes, 4 active
BGP: 390753 routes, 153292 active
Aggregate: 3 routes, 3 active
--- JUNOS 9.5R1.8 built 2009-04-13 19:11:52 UTC
plu...@router show chassis routing-engine
Routing Engine status:
Temperature 30 degrees C / 86 degrees F
CPU temperature 30 degrees C / 86 degrees F
DRAM 1024 MB
Memory utilization 95 percent
CPU utilization:
User 0 percent
Real-time threads 16 percent
Kernel 2 percent
Idle 82 percent
Model RE-J2320-2000
Serial ID xxx
Start time 2010-05-04 15:08:29 MSD
Uptime 80 days, 30 minutes, 28 seconds
Last reboot reason 0x1:power cycle/failure
Load averages: 1 minute 5 minute 15 minute
0.07 0.06 0.07
Forwards upto 200 Megs. Very similar story with other boxes running
10.0R2. Not a single fwdd crash for half a year (knock on wood). Though
9.6 don't remember which release had annoyed us and the customer quite
few times until we moved to 10.0R2.
We also have a few J in a lab. Never heard packet context didn't work as
expected.
IFAIR since 9.5R2 or 9.6R2 they reduced fwdd memory appetite for a few
tens of megabytes:
plu...@router show chassis routing-engine
Routing Engine status:
Temperature 50 degrees C / 122 degrees F
CPU temperature 54 degrees C / 129 degrees F
*Total memory 1024 MB Max 840 MB used ( 82 percent)*
Control plane memory 594 MB Max 505 MB used ( 85 percent)
Data plane memory430 MB Max 340 MB used ( 79 percent)
CPU utilization:
User 3 percent
Real-time threads 20 percent
Kernel 9 percent
Idle 68 percent
Model RE-J2320-2000
Serial ID yyy
Start time 2010-06-28 15:10:49 MSD
Uptime 25 days, 50 minutes, 3 seconds
Last reboot reason 0x1:power cycle/failure
Load averages: 1 minute 5 minute 15 minute
0.21 0.23 0.16
So the recent releases are a bit more efficient from this point of view.
I also recommend to turn off unwanted processes, which also consume some
memory.
plu...@router show configuration system processes
idp-policy disable;
jsrp-service disable;
The output of show security flow sessions I posted yesterday was also
taken from one of this boxes. It shows 0 sessions and I see no issues
with management traffic at all. Stateless FW filters work just as expected.
I am not saying all this is the most ideal solution available at the
market, but don't see much instability except customer's site power
problems.
--
Pavel
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 traffic to use flow-based forwarding‹exclude this traffic when specifying match conditions for the firewall filter term containing the packet-mode action modifier. Any host-bound TCP traffic configured to bypass flow is dropped. http://www.juniper.net/techpubs/software/junos-security/junos-secur ity10.0/junos-security-admin-guide/config-stateless-packet-option-section.html There seems to be some confusion here. Bypassing the flow module (ie using filter-based packet mode) is not the same as disabling the flow module. When you set the router in packet-based mode for v4, mpls, v6 or iso the whole security section becomes null and void. So, the above is not true when the router is in packet mode only. I believe Pavel provided strong evidence of this too. Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 when a product that they bought for a certain purpose gets pulled out from under them with no workaround or compensation, that seems to be the bottom line point that Juniper is missing. They certainly could have learned from the Cisco 6500 vs. 7600 BU fiasco. Oh, that is a mess, and an awesome case study :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
* 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 TCP sessions involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 the documentation, there is no way around that. It means that all existing TCP sessions involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. 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 screwed up in the small router/CPE market. One can hope that they won't perform similar stunts on the M/MX/T series. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 *to* the router, e.g. bgp sessions. Ergo the memory-pit transcends reboots. Best wishes Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 plu...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 version (or when there's a serious problem and they don't fix it), what then? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 they don't really need. Or try to make a device to do something it is not supposed to do. Then want this sort of architecture to be competitive. My favorite example is running full BGP everywhere. Another popular approach is to use J-series or EX switch as an Ethernet aggregation router or even as a BRAS. Well, everyone can do anything he wants, but I am not sure every approach must be competitive :) Well, sorry for this piece of holy-war. I don't mean I love vendors more than customers :) -- Regards, Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
* 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 TCP sessions involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. MPLS is not supported in flow mode today. To enable MPLS in packet mode, do the following: set security forwarding-options family mpls mode packet-based As I'm sure many of you know (but apparently not everyone), flow mode was created because Juniper felt it was the best architectural approach to implementing security functionality (eg stateful FW, IDP, etc). Any J-Series router running 9.4+ code can run as a packet-based router, which also disables any of these stateful features, by doing the above command. You also have the ability to run or chain flow-mode and packet-mode routing instances. I realize that it's probably irritating to some people that all post-9.3 releases have flow mode enabled by default but it is fairly simple to change the router to packet-based only. Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 understand why the SRX product line was created in the first place. 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. In addition, in order to do high-end processing of (stateful) flows you need dedicated and specific hw to achieve desired performance. That hw doesn't exist on MX and T series. It only exists on high-end SRX (ie SPUs). Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 router unless you have out of band access (as the router comes up with some default stateful configuration) 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. Regards Amos On Jul 22, 2010, at 9:37 PM, Chris Whyte wrote: * 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 TCP sessions involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. MPLS is not supported in flow mode today. To enable MPLS in packet mode, do the following: set security forwarding-options family mpls mode packet-based As I'm sure many of you know (but apparently not everyone), flow mode was created because Juniper felt it was the best architectural approach to implementing security functionality (eg stateful FW, IDP, etc). Any J-Series router running 9.4+ code can run as a packet-based router, which also disables any of these stateful features, by doing the above command. You also have the ability to run or chain flow-mode and packet-mode routing instances. I realize that it's probably irritating to some people that all post-9.3 releases have flow mode enabled by default but it is fairly simple to change the router to packet-based only. Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 understand why the SRX product line was created in the first place. I have no problems with the SRX product line - it has been sold as a security device from day one. I *had* some hopes for the J series to compete with Cisco in the general small router/CPE market. And certainly the J series was sold as such, at least in the beginning. The fact that the original JunOS (without flow mode etc) is now a dead end on the J series means that for us the whole J series is a dead end - and our small router/CPE business currently mostly goes to Cisco. We have 3 J2320 routers in our lab, which are nice to use for JunOS training and similar. No new J series purchases are expected... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 with the high end SRXs but a lot of experience with the lower end SRX devices (210-650) and I can honestly say that I consider them to be the worst piece of networking/security hardware I ever worked with. The software quality for these devices is catastrophic, including many stability related bugs which crashed devices time after time. The logging of the devices is so inconvenient and also affect performance significantly, to a level where logging advised by JTAC killed a device. I heard this not only from colleagues but also from advanced JTAC engineers. It came to a point where my company stopped selling SRX devices and talking to the local distributer I understand that the overall Juniper security sales (in our small country) declined significantly. It's important to mention that I'm a big Juniper fan (especially for the Junos line of products), and I'm not looking to flame the product for nothing. Regards Amos On Jul 22, 2010, at 9:49 PM, Chris Whyte wrote: 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 understand why the SRX product line was created in the first place. 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. In addition, in order to do high-end processing of (stateful) flows you need dedicated and specific hw to achieve desired performance. That hw doesn't exist on MX and T series. It only exists on high-end SRX (ie SPUs). Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 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 router unless you have out of band access (as the router comes up with some default stateful configuration) 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. Regards Amos On Jul 22, 2010, at 9:37 PM, Chris Whyte wrote: * 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 TCP sessions involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. MPLS is not supported in flow mode today. To enable MPLS in packet mode, do the following: set security forwarding-options family mpls mode packet-based As I'm sure many of you know (but apparently not everyone), flow mode was created because Juniper felt it was the best architectural approach to implementing security functionality (eg stateful FW, IDP, etc). Any J-Series router running 9.4+ code can run as a packet-based router, which also disables any of these stateful features, by doing the above command. You also have the ability to run or chain flow-mode and packet-mode routing instances. I realize that it's probably irritating to some people that all post-9.3 releases have flow mode enabled by default but it is fairly simple to change the router to packet-based only. Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 and see plu...@router show security flow session summary Session summary: Unicast-sessions: 0 Multicast-sessions: 0 Failed-sessions: 0 Sessions-in-use: 0 Maximum-sessions: 262144 plu...@router show security flow session 0 sessions displayed Despite I'm SSH on it and it holds several BGP sessions. When J/SRX is in normal (flow) mode it shows the sessions to itself. Morover this would be cool if we could use per security zone stateful settings for host-inbound-traffic instead of classic packet-based unidirectional filters (stuff everyone hates to do) in order to protect control plane in packet mode. Although it seems to me that it is not possible. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 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 keep 1-1-1 story with no sub-branches) a lot of people had already been running J series for plain routing purposes. In many cases they ran ISP oriented features, sometimes NAT + MPLS, etc. We can discuss and argue till forever, was the idea of choosing this way good or no, but they just had been doing so. And since 9.4 a lot of them suffer from this memory leak issue. This is a very common claim and dissatisfaction source. I talk to customers who want a cheap device capable to run full BGP to forward few hundred megs approximately twice a month. Both enterprise and ISP. We are able to convince most of them that they should not do what they want to do (mainly they want a very bad sort of network architecture), but anyway there is a demand for this. Some of old customers, who have implemented J series as plain routers, still come for new boxes today and get really surprised that there are huge changes in what they are used to deal with. Only thing, that we can tell them, is that 9.3 is an EEOL release, which has EOE in 2011 and EOL in 2012. So those who just want packet-based J series can stay there for some time. -- Regars, Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I absolutely agree with the posts on the J-series boxes. I need lots of small(ish) boxes that will do a reasonable throughput of MPLS (PWEs, L3VPN etc) and I was really liking the J-series, but I need some QinQ stuff that they dont support, so I thought about the SRX would be ideal, but these recent JUNOS releases have been less than stable and after spending days trying to make stuff work that suddenly got fixed with a 10.1 release just reminds me a little too much of Cisco. Now, I would never use Cisco in anything but a switch any more, but this whole flow mode thing and recent JUNOS releases have made me get other vendors into my labs and I would rather use Juniper. I have J-series boxes that have to run code bloated by this crazy flow thing, SRXs that, well, dont seem to be all they could be (I was going to use SRX100s for a load of CPE till I watched one boot up) 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, please file jtac cases. I understand. I was specifically addressing the high-level comment/concern that Juniper might do the same (ie implement flow mode) on M/MX/T series. SRX serves this purpose. That's all. My concern is that not everyone seems to understand the high-level decisions behind architecture, product and feature direction. I personally find it difficult that anyone can understand specific details without understanding these fundamental decisions first. Hence I was just trying to chime in with that type of information. By injecting some of this commentary it is also likely that the decision makers at certain BUs at Juniper will see some of your concerns first hand. My intention is a positive one. I promise you. :-) Another way to look at it: It's akin to understanding the why Juniper chose the one OS architectural approach vs Cisco choosing the N x OS architectural approach. Why choose a vendor until you fully understand the benefits of their architectural decisions? Thanks, Chris On 7/22/10 12:36 PM, Amos Rosenboim a...@oasis-tech.net wrote: 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 with the high end SRXs but a lot of experience with the lower end SRX devices (210-650) and I can honestly say that I consider them to be the worst piece of networking/security hardware I ever worked with. The software quality for these devices is catastrophic, including many stability related bugs which crashed devices time after time. The logging of the devices is so inconvenient and also affect performance significantly, to a level where logging advised by JTAC killed a device. I heard this not only from colleagues but also from advanced JTAC engineers. It came to a point where my company stopped selling SRX devices and talking to the local distributer I understand that the overall Juniper security sales (in our small country) declined significantly. It's important to mention that I'm a big Juniper fan (especially for the Junos line of products), and I'm not looking to flame the product for nothing. Regards Amos On Jul 22, 2010, at 9:49 PM, Chris Whyte wrote: 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 understand why the SRX product line was created in the first place. 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. In addition, in order to do high-end processing of (stateful) flows you need dedicated and specific hw to achieve desired performance. That hw doesn't exist on MX and T series. It only exists on high-end SRX (ie SPUs). Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 Whyte cwh...@juniper.net wrote: I understand. I was specifically addressing the high-level comment/concern that Juniper might do the same (ie implement flow mode) on M/MX/T series. SRX serves this purpose. That's all. My concern is that not everyone seems to understand the high-level decisions behind architecture, product and feature direction. I personally find it difficult that anyone can understand specific details without understanding these fundamental decisions first. Hence I was just trying to chime in with that type of information. By injecting some of this commentary it is also likely that the decision makers at certain BUs at Juniper will see some of your concerns first hand. My intention is a positive one. I promise you. :-) Another way to look at it: It's akin to understanding the why Juniper chose the one OS architectural approach vs Cisco choosing the N x OS architectural approach. Why choose a vendor until you fully understand the benefits of their architectural decisions? Thanks, Chris On 7/22/10 12:36 PM, Amos Rosenboim a...@oasis-tech.net wrote: 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 with the high end SRXs but a lot of experience with the lower end SRX devices (210-650) and I can honestly say that I consider them to be the worst piece of networking/security hardware I ever worked with. The software quality for these devices is catastrophic, including many stability related bugs which crashed devices time after time. The logging of the devices is so inconvenient and also affect performance significantly, to a level where logging advised by JTAC killed a device. I heard this not only from colleagues but also from advanced JTAC engineers. It came to a point where my company stopped selling SRX devices and talking to the local distributer I understand that the overall Juniper security sales (in our small country) declined significantly. It's important to mention that I'm a big Juniper fan (especially for the Junos line of products), and I'm not looking to flame the product for nothing. Regards Amos On Jul 22, 2010, at 9:49 PM, Chris Whyte wrote: 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 understand why the SRX product line was created in the first place. 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. In addition, in order to do high-end processing of (stateful) flows you need dedicated and specific hw to achieve desired performance. That hw doesn't exist on MX and T series. It only exists on high-end SRX (ie SPUs). Thanks, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 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 keep 1-1-1 story with no sub-branches) a lot of people had already been running J series for plain routing purposes. In many cases they ran ISP oriented features, sometimes NAT + MPLS, etc. 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 when a product that they bought for a certain purpose gets pulled out from under them with no workaround or compensation, that seems to be the bottom line point that Juniper is missing. Adding a mechanism to reduce the memory consumption when you turn off flow mode seems to be the least they could do to make it right, and not that difficult. Of course it would have been nice if they had at least left the last working code of the old version in a reasonable state too. 9.3 on J-series is a complete mess, and the last semi-stable version (8.5) doesn't have support for 32-bit ASNs. Obviously engineering resources and support for every old product has to come to an end eventually, but IMHO Juniper really screwed the pooch by leaving the last working code in an unusable state before abandoning it. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 as you turn MPLS on the flow mode was diabled and you were back to good old packet mode? -- Leigh -Original Message- From: juniper-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 the same email when I saw your post come through. I got a set of 2350's out of the box running 60% memory utilization, I added a l3 vpn (with 3 routes) and the nice green bar in the web interface changed colors on me. Thanks, Jay -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Christopher E. Brown Sent: Tuesday, July 20, 2010 5:15 PM To: juniper-...@punk.nether.net Subject: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases. I know alot of us here have been bitten by this, and the fact that disabling flow mode and reverting to packet does not free up any of the ~ 460MB or so being eaten by fwdd/flowd is insane. I am currently having the This is a design feature, the pre-alloc is planned argument with a SE. I have no issue with flow features being added, looks great for branch office use. What is killing be is that flow is not wanted, needed or usable in a small-infra use with multipath and MPLS services, but even disabled flowd is eating half the box memory. 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used to be able to handle a few thousand igp routed plus a full table with easy and lots of headroom, now it is at 92% I am pushing this w/ account team and support case, please do the same. If enough people complain about the insane resource consumption they might actually fix it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I am considering the SRX series and perhaps for J series for a quite large MPLS deployment and this flow stuff is a pet peeve of mine. From what I can see, all it means is that a box that used to do rather well is now limited by the number of flows it can handle and the ludicrous memory requirements of something that is not used. I'll be mentioning this in our requirements report for any equipment we order for this project. -- Leigh Porter -Original Message- From: Shane Short [mailto:sh...@short.id.au] Sent: 21 July 2010 08:32 To: Leigh Porter Cc: Jay Hanke; 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. 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 as you turn MPLS on the flow mode was diabled and you were back to good old packet mode? -- Leigh -Original Message- From: juniper-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 the same email when I saw your post come through. I got a set of 2350's out of the box running 60% memory utilization, I added a l3 vpn (with 3 routes) and the nice green bar in the web interface changed colors on me. Thanks, Jay -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Christopher E. Brown Sent: Tuesday, July 20, 2010 5:15 PM To: juniper-...@punk.nether.net Subject: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases. I know alot of us here have been bitten by this, and the fact that disabling flow mode and reverting to packet does not free up any of the ~ 460MB or so being eaten by fwdd/flowd is insane. I am currently having the This is a design feature, the pre-alloc is planned argument with a SE. I have no issue with flow features being added, looks great for branch office use. What is killing be is that flow is not wanted, needed or usable in a small-infra use with multipath and MPLS services, but even disabled flowd is eating half the box memory. 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used to be able to handle a few thousand igp routed plus a full table with easy and lots of headroom, now it is at 92% I am pushing this w/ account team and support case, please do the same. If enough people complain about the insane resource consumption they might actually fix it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
Just install Linux on the box ;-) -Original 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:05 To: Christopher E. Brown 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. 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 by this, and the fact that disabling flow mode and reverting to packet does not free up any of the ~ 460MB or so being eaten by fwdd/flowd is insane. I am currently having the This is a design feature, the pre-alloc is planned argument with a SE. I have no issue with flow features being added, looks great for branch office use. What is killing be is that flow is not wanted, needed or usable in a small-infra use with multipath and MPLS services, but even disabled flowd is eating half the box memory. 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used to be able to handle a few thousand igp routed plus a full table with easy and lots of headroom, now it is at 92% I am pushing this w/ account team and support case, please do the same. If enough people complain about the insane resource consumption they might actually fix it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 leigh.por...@ukbroadband.com wrote: Just install Linux on the box ;-) -Original 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:05 To: C... Just a quick thought... what about renaming the flowd binary..? No I haven't tested it :) On 20 J... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 with!) the small and medium sized customers, and builds quality products that aren't only tested once they hit the production network - I'm in! On 21 July 2010 11:35, Chris Evans chrisccnpsp...@gmail.com wrote: 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 leigh.por...@ukbroadband.com wrote: Just install Linux on the box ;-) -Original 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:05 To: C... Just a quick thought... what about renaming the flowd binary..? No I haven't tested it :) On 20 J... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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://juniper.cluepon.net/index.php/Enabling_packet_based_forwarding or does anyone have any other suggestions? Nick -Original 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, please file jtac cases. 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 with!) the small and medium sized customers, and builds quality products that aren't only tested once they hit the production network - I'm in! On 21 July 2010 11:35, Chris Evans chrisccnpsp...@gmail.com wrote: 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 leigh.por...@ukbroadband.com wrote: Just install Linux on the box ;-) -Original 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:05 To: C... Just a quick thought... what about renaming the flowd binary..? No I haven't tested it :) On 20 J... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
After implementing the procedure did you see a drop in memory utilization? If so, how much? jay -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@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 for some bgp and ospf. Is the best guide to following to move from flow to packet-based this http://juniper.cluepon.net/index.php/Enabling_packet_based_forwarding or does anyone have any other suggestions? Nick -Original 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, please file jtac cases. 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 with!) the small and medium sized customers, and builds quality products that aren't only tested once they hit the production network - I'm in! On 21 July 2010 11:35, Chris Evans chrisccnpsp...@gmail.com wrote: 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 leigh.por...@ukbroadband.com wrote: Just install Linux on the box ;-) -Original 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:05 To: C... Just a quick thought... what about renaming the flowd binary..? No I haven't tested it :) On 20 J... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I haven't implemented. I was asking if the below link is the best way to do it as I would prefer to go back to packet-based. Nick -Original Message- From: Jay Hanke [mailto:jha...@myclearwave.net] Sent: 21 July 2010 15:10 To: Nick Ryce; 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. After implementing the procedure did you see a drop in memory utilization? If so, how much? jay -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@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 for some bgp and ospf. Is the best guide to following to move from flow to packet-based this http://juniper.cluepon.net/index.php/Enabling_packet_based_forwarding or does anyone have any other suggestions? Nick -Original 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, please file jtac cases. 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 with!) the small and medium sized customers, and builds quality products that aren't only tested once they hit the production network - I'm in! On 21 July 2010 11:35, Chris Evans chrisccnpsp...@gmail.com wrote: 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 leigh.por...@ukbroadband.com wrote: Just install Linux on the box ;-) -Original 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:05 To: C... Just a quick thought... what about renaming the flowd binary..? No I haven't tested it :) On 20 J... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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.br...@acsalaska.net desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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. On 21 July 2010 19:35, Christopher E. Brown chris.br...@acsalaska.netwrote: 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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 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.br...@acsalaska.net desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 packet mode, but all of the memory pre-allocs to support flow mode remain in play. The J-series software has always pre-allocated memory to the forwarding daemon. This was always the case, even in 7.x and 8.x software that only supported packet-mode. The fact that memory is still pre-allocated when you disable flow mode is not surprising. Simply looking at the memory usage with show commands doesn't tell the complete story. The real question is can the router handle a larger routing and forwarding table once flow mode is disabled. If the answer is no, then I would agree that your request is a legitimate feature enhancement. --Stacy 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. If adding flow support causes the forwarding daemon to grow a couple hundred megs than going back to packet should free most of that memory. A 1GB J that used to run with at least a few hundred megs available now has 40 megs free... -- Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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, 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 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! I have disabled and then re-started the process on a live router w/ packet mode config, no change in use. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
Has anybody had memory problems after upgrading to a flow based Junos release? (i.e. the router was perfectly speced before, load the new code and you suddenly need to uprade everything?) Perhaps this is just another bug to add to the Junos 10 list ;-) -- Leigh -Original Message- 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, 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 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! I have disabled and then re-started the process on a live router w/ packet mode config, no change in use. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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, Thomas On 21 Jul 2010, at 23:23, 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 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 hj1...@gmail.commailto:hj1...@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.br...@acsalaska.netmailto:chris.br...@acsalaska.netwrote: 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.br...@acsalaska.netmailto:chris.br...@acsalaska.net desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
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 before and after disabling the flowd? No, if it did I would not consider it an issue. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
