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 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] MX Capabilities - flexible-ethernet-services
Hate to reply to my own post, but the solution below worked just fine.
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Eric Van Tol
Sent: Wednesday, July 21, 2010 11:34 AM
To: juniper-nsp
Subject: [j-nsp] MX Capabilities - flexible-ethernet-services
Hi all,
I'm currently in the process of migrating the configuration of a 6509 to
an MX and I've got a question or two. I have a customer in one of our
metro rings to which we provide a Q-in-Q tunnel. The A-side is a Q-in-Q
port on a switch that is directly connected to a 6509 'switchport mode
trunk' port. The Z-side is a direct fast ethernet Q-in-Q port to our
6509. Very simple. My question comes in the form of whether it's
possible to do this on the MX using a port-based VLAN. Will the following
configuration work?
ge-0/0/5 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
description Customer A Q-in-Q VLAN;
encapsulation vlan-bridge;
family bridge {
interface-mode trunk;
vlan-id-list 130;
}
}
unit 32 {
description Sw1-R11:Gi0/16;
vlan-id 32;
family inet {
address 192.168.20.11/30;
}
}
}
bridge-domains {
cid-A {
description P2P Q-in-Q for Customer A;
domain-type bridge;
vlan-id 130;
}
}
The customer will be plugged directly into a downstream EX3200 via a Q-in-
Q port. Is this valid? Are there any options within the bridge-domain
VLAN config that need to be set properly? Am I overly complicating
matters? Could I ask anymore questions in a single paragraph?
My overall intent is to not have to create the VLAN 32 in my bridge
domain. There is really no technical reason why it can't be done - it's
just more about consistency in how all ports are configured.
Thanks,
evt
___
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.
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 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 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 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 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 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] forwarding-class without scheduler
On Thursday, July 22, 2010 11:25:35 am Benny Sumitro wrote: Are you doing it on J series or M series? J series platform will discard any unclassified queue (at least, that is what i experienced when i still have j series with junos 8.x installed) while M series will still forward those traffic but without any guarantee of traffic (no transmit rate). These are on M-series running JUNOS 9.5R4.3. Will be running the same on MX480 running JUNOS 10.2R1.8. I don't expect any issues :-). 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.
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
[j-nsp] Is putting an IP on an l2circuit possible?
I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? ___ 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] Is putting an IP on an l2circuit possible?
Assuming its martini l2ckt you are talking about, you could establish l2ckt with lt- interfaces. Peer 2 units of lt- with each other. Put one unit in inet.0 with IP address configured and use other unit with ethernet ccc or vlan-ccc encap to establish the l2ckt. You can then ping the remote IP from inet.0 once l2ckt is up. With this you do not need any physical CE links. I haven't tested this on J. But I know it works fine on M/T. Thanks, Nilesh On 7/22/10 10:49 AM, Jason Lixfeld ja...@lixfeld.ca wrote: I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? ___ 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] Is putting an IP on an l2circuit possible?
On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote: I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? You can't configure IP on it directly, but I've done this same kind of thing with a logical tunnel interface instead of a physical loopback. Either way you need to steal a port or have a tunnel pic, so it doesn't help you much. :) -- 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] Is putting an IP on an l2circuit possible?
On 2010-07-22, at 3:03 PM, Jared Mauch wrote: you can't do the mpls ping to validate? (ping mpls l2vpn ...) Wouldn't I need an attachment circuit in order for the l2vpn to come up, or are you saying that a successful ping mpls l2vpn is independent of the state of the attachment circuit? you could also hook two ports on the same J box together and put the IP on one and EoMPLS on the other... I hadn't considered that, but good to know for next time when I have a box with a few spare ports. (Cisco: Router#ping mpls pseudowire 10.0.0.1 115 Sending 5, 100-byte MPLS Echos to 10.0.0.1, timeout is 2 seconds, send interval is 0 msec: Codes: '!' - success, 'Q' - request not sent, '.' - timeout, 'L' - labeled output interface, 'B' - unlabeled output interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 'P' - no rx intf label prot, 'p' - premature termination of LSP, 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. ! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/363/460 ms ) - Jared On Jul 22, 2010, at 1:49 PM, Jason Lixfeld wrote: I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? ___ 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] Is putting an IP on an l2circuit possible?
On 2010-07-22, at 3:13 PM, Richard A Steenbergen wrote: On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote: I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? You can't configure IP on it directly, but I've done this same kind of thing with a logical tunnel interface instead of a physical loopback. Either way you need to steal a port or have a tunnel pic, so it doesn't help you much. :) I should probably clarify that C and J refer to Cisco and Juniper, not J series Juniper boxen :) The J[uniper] in question is actually an M120. ___ 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] Is putting an IP on an l2circuit possible?
Hi Jason - On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote: I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? I've done this on an MX by using logical routers and lt interfaces to connect them. You can specify an lt interface (with vlan-ccc encap.) under the l2circuit configuration and assign another lt interface to a logical router acting as the CE on the same box with vlan encapsulation and an IP address. Assign VLAN IDs and match up the peer-units for the lt interfaces, and you're good to go. That being said, this only works on the MX because it supports logical routers and has the tunnel services PIC built-in. You might be able to do the same thing on a J with an additional virtual router instead of a full-blown logical router, but I haven't tried it. - Mark -- Mark Kamichoff p...@prolixium.com http://www.prolixium.com/ signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Is putting an IP on an l2circuit possible?
In that case, as Richard mentioned, you will need a service-pic to create lt- (logical tunnel) interface. If you just have one Gig port on J, you could force it in local loopback mode via CLI. That you bring up the port in up up state and should be able to bring up the l2ckt as well. Then you can probably use ping mpls l2circuit to ping. Thanks, Nilesh. On 7/22/10 12:18 PM, Jason Lixfeld ja...@lixfeld.ca wrote: On 2010-07-22, at 3:13 PM, Richard A Steenbergen wrote: On Thu, Jul 22, 2010 at 01:49:55PM -0400, Jason Lixfeld wrote: I'm trying to test some C to J EoMPLS interoperability, but the only J box that I have doesn't have any free interfaces on it, so I have nowhere to connect a test CE and use the CE to ping the far end. Is there any way to stick a subnet on to an l2circuit directly instead of having to use a physical interface and a physical CE? You can't configure IP on it directly, but I've done this same kind of thing with a logical tunnel interface instead of a physical loopback. Either way you need to steal a port or have a tunnel pic, so it doesn't help you much. :) I should probably clarify that C and J refer to Cisco and Juniper, not J series Juniper boxen :) The J[uniper] in question is actually an M120. ___ 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] M20 JunOS Recommendation
We have several old m20's with RE2's terminating STM16 wavelengths, all stable running JUNOS 9.3R2.8. This requires some hardware hacks - if you want to get your hands dirty you can upgrade the 96MB CF card on the RE2 to 1GB and the DRAM on SSB from 64MB to 128MB. I believe the procedures are well published, but if you have trouble finding them please hit me up off list and I'll be happy to provide you with a step by step. Kevin On Wed, Jul 21, 2010 at 2:31 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Wed, Jul 21, 2010 at 08:12:26AM -0700, Andy Vance wrote: We currently have all of our M20's on 8.5S4 and have had no issues whatsoever, we upgraded from 7.5-daily. 8.5S4 is an extended release and if you're not chasing features, I'd look into utilizing it. If you're using the original RE 8.5 may be the last code you can fit onto the flash anyways. :) -- 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 -- Cheers, Kevin :: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle :: :: PGP Key ID | fingerprint :: :: 0x803F24BE | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE Elegance is not a dispensable luxury but a factor that decides between success and failure. -Edsgar Dijkstra ___ 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
