Re: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases.
On Thursday, July 22, 2010 07:00:45 pm Pavel Lunin wrote: The problem with EX in ISP applications is very limited MPLS capabilities. So if you want VPLS or L3VPN in some remote location, EX will not save you although it has way higher forwarding performance. Yes, this, indeed, was a problem. But I'm sure Juniper also saw that if they shipped a half-decent MPLS code base in the 1U EX-series platform, it'd be a commercial disaster for them. For this, I can appreciate. Problem is, the MX80 is too large and too expensive as a true MPLS in the Access box. This, in my opinion, is where I think Juniper dropped the ball; and Cisco's new ME3600X/ME3800X is right on cue to sweep this market. 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 use increase with flow mode add, please file jtac cases.
On Thursday, July 22, 2010 10:48:20 pm Pavel Lunin wrote: Ok. But let's be honest, it's tricky. Specially in L3 metro access where it is easy to get a loop if you don't rely on what customers announce to you (I had experience of spending weeks on phone with major Russian ISP on behalf of the customer, who wanted split AS to work with no loops). I believe there are some other examples of RIBs not used for forwarding, but normally this is very different case than we talked about and you know what you use it for. And you anyway have something which uses full table for forwarding. What you call 'routed metro' is itself a little bit of a question to discuss how it works :) I'm a firm believer of MPLS in the Access. But... But, please, let's not continue this. It' s too far away from the topic. ... yes, this is way off-topic now :-). 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 use increase with flow mode add, please file jtac cases.
On 20 Jul 2010, at 23:14, Christopher E. Brown wrote: 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. It's trash, we've found customers are starting to buy lower end cisco for very-small SP environments again. Cisco 2900 is hoovering up lots of the builds that we used to use J4350/6350 for, precisely because of the added complexity and total resource of that this flow-mode presents. I have no issue with flow features being added, looks great for branch office use. This trade wont come back until there is a rebuild of JUNOS sans enhanced services for J. Pretty please with cherry on top ? 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 use increase with flow mode add, please file jtac cases.
On 21.07.2010 22:34, Christopher E. Brown wrote: That is exactly our use, up to a couple hundred megs of IP services on one, a couple hundred of L3 MPLS on another, and L2-circuit/vpls on a third. Alaska has many small remote locations. For larger areas, M and MX platforms are better, and can be justified. Yeah, I understand. Here in Russia, all the locations are remote :) and we also bump into the requirements of cheap devices running everything including L3VPN/VPLS for a few hundred megs. I would suggest to use SRX240H in packet mode and don't even think about full BGP (they can't) or upgrade J-series with ‘non-native’ DRAM and flash or (and) just stay at 9.3 on J-series. Don't really believe Juniper will change this behavior. -- 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 use increase with flow mode add, please file jtac cases.
On 22.07.2010 14:33, Alexandre Snarskii wrote: we also bump into the requirements of cheap devices running everything including L3VPN/VPLS for a few hundred megs. I would suggest to use SRX240H in packet mode and don't even think about full BGP (they can't) You can try the same trick as with ex-series (yes, it's quite possible to run full-view on ex-4200 series switch and some people do that in production networks). I never tried it at SRX (do not have one yet), so if you'll try it - I'd like to hear your experience. Very advanced sort of design :) EX3200/4200 can only support 32k active prefixes in FIB. Sure you can keep as many prefixes in RIB as Control Plane capable to hold and only few prefixes in FIB but, I am sorry, what for? What is the adventure of keeping that hell of routes in RIB if you rely on something other for real switching? To feel cool issuing show route summary which shows 600k routes instead of 6? :) The problem with EX in ISP applications is very limited MPLS capabilities. So if you want VPLS or L3VPN in some remote location, EX will not save you although it has way higher forwarding performance. -- 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 use increase with flow mode add, please file jtac cases.
Example: you run routed metro (or datacenter) ethernet ring, with less than 12k entries in FIB. One of your customers wants to turn BGP on his link. There are lots of choices on how to do that: [...] But that is one of cases when having full-view in your edge switch RIB and redistributed to customer fits perfectly. Ok. But let's be honest, it's tricky. Specially in L3 metro access where it is easy to get a loop if you don't rely on what customers announce to you (I had experience of spending weeks on phone with major Russian ISP on behalf of the customer, who wanted split AS to work with no loops). I believe there are some other examples of RIBs not used for forwarding, but normally this is very different case than we talked about and you know what you use it for. And you anyway have something which uses full table for forwarding. What you call 'routed metro' is itself a little bit of a question to discuss how it works :) But, please, let's not continue this. It' s too far away from the topic. IIRC, it's quite possible to use closest MX-series router to mix draft-kompella pseudowire from EX-series into VPLS domain (it was discussed in this list not so long time ago). Not sure about L3VPN though. Yeah! You can even have large VC ring of EX4200 and run VLANs instead of PWE3. Or some other magic L2 technology like PBB, STP or layer 1 circuits if you like. But you anyway use switches just as transport between customers and service point (MX). It is quite a different story than putting cheap routers everywhere and run VPLS/L3VPN on them. This is what I am speaking about. If you want a cheap network — put switches everywhere and run some L2 transport till service points (MX), where you put the circuits into instances. If you are brave enough to run L3VPN/VPLS everywhere, use MX everywhere. Ok, J series as an exception for small remote locations. But if you just put switches or even J series everywhere, than be ready to spend nights at work and don't say this is the vendor who makes you non-competitive :) -- Kind 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 use increase with flow mode add, please file jtac cases.
IIRC, it's quite possible to use closest MX-series router to mix draft-kompella pseudowire from EX-series into VPLS domain (it was discussed in this list not so long time ago). Not sure about L3VPN though. BTW. Kompella? Didn't you mean CCC? EX only support single label MPLS. ___ 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 use increase with flow mode add, please file jtac cases.
This flow mode thing has (IMO) to be one of the most annoying and quite useless features. Perhaps it is useful for firewall/enterprise apps, but please, what else? -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Christopher E. Brown Sent: Tue 7/20/2010 11:14 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
Re: [j-nsp] J series users bitten by the massive memory use increase 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
Re: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases.
Chris - Is the current situation: that Juniper have said there is no workaround / configuration change that can be made to stop the allocation of memory for the flow forwarding information? 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
Re: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases.
On 7/21/2010 3:47 PM, Heath Jones wrote: Chris - Is the current situation: that Juniper have said there is no workaround / configuration change that can be made to stop the allocation of memory for the flow forwarding information? The current response is that this memory consumption is by design and therefor not a bug. The fact that this makes a J series purchased with the MAX avail memory less then 6 months ago almost out of memory from day 1 does not seem to be getting through. I keep hammering this point with the SE on the case and am pushing the issue as silly design flaw, fix it through my account team as well. I hope everyone else does the same. ___ 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 use increase 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
Re: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases.
This is why I have 2 gb in 23xx and 4 gb in 4350s android rocks -Original Message- From: Jay Hanke [jha...@myclearwave.net] Received: 7/20/10 4:33 PM To: 'Christopher E. Brown' [chris.br...@acsalaska.net]; juniper-...@punk.nether.net [juniper-...@punk.nether.net] Subject: Re: [j-nsp] J series users bitten by the massive memory use increase 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
