Hello All, I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself. Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke? Thanks! -- Steve King Network/Linux Engineer - AdSafe Media Cisco Certified Network Professional CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
On 04/10/2012 12:31 AM, Steven King wrote:
Hello All,
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
Thanks!
http://www.ebay.com/sch/Networking-Communications-/11176/i.html?_from=R40&_nkw=juniper <http://www.ebay.com/sch/Networking-Communications-/11176/i.html?_from=R40&_nkw=juniper>
On 10/04/12 14:31, Steven King wrote:
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
A slightly more useful way of answering this then just pointing to eBay is to give some candidates. Routing/switching *config*, firewalling - Branch SRX / J The lower end SRX, and J series devices are nice as they take nearly all the config (except MX-type bridging, and some EX bits), including MPLS. Switching - EX [34]200 The 4200 & 3200 are essentially the flagship, and if you can only buy one switch for a lab make it one of those Routing - M5/10/7i/10i/20 A bunch of the smaller and older M series kit is now fairly cheaply available. These are still quite nice boxes, and support SONET and ATM unlike the platforms above should you need them. MX Routing - MX 80 (new) The MX80 (or as locked 5/10/40 variants) is by far the cheapest way to test the MX-specific ethernet services, as long as you don't want BRAS functionality. Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world). If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for < $500 used).
On Apr 10, 2012, at 5:58 AM, Julien Goodwin wrote:
On 10/04/12 14:31, Steven King wrote:
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
A slightly more useful way of answering this then just pointing to eBay is to give some candidates.
Routing/switching *config*, firewalling - Branch SRX / J
The lower end SRX, and J series devices are nice as they take nearly all the config (except MX-type bridging, and some EX bits), including MPLS.
But not so nice in that they run Services JunOS instead of real JunOS meaning that they behave like Netscreens with a JunOS style configuration file instead of behaving like Junipers. If you're wanting to model Services JunOS, then, yes, the SRX-100 is a good candidate and dirt cheap. If you want real JunOS, avoid SRX or J series at all costs.
Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world).
Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products.
If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for < $500 used).
With the caveat about Services JunOS above. Owen
I find it humorous that you think J/SRX junos isn't real junos. So what makes it not real junos? The fact it has a flowd process? Lets technically talk about this for a moment. Realistically one of the only differences between "flow based junos" and the legacy "packet based junos" is the flowd process. Which can be easily bypassed by issuing a couple of configuration commands. So what exactly makes this platform/code so horrible and not "real" junos? If anything to me it's a better platform to deploy and learn on. It's more flexible as it comes with more advanced flow based features but they are optional. There are certain limitations as mentioned previously around the switching and class of service however these same feature limitations were also in the "real" junos low end devices. If there are other differences that I am unaware of then by all means feel free to educate me. I am well aware that branch devices don't have the capabilities of the MX/M series in regards to ATM and other such specific platforms, but you called this "not real junos". So lets keep any responses limited to that aspect. -Tim Eberhard On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong <owen@delong.com> wrote:
If you want real JunOS, avoid SRX or J series at all costs.
Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world).
Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products.
If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for < $500 used).
With the caveat about Services JunOS above.
Owen
On Apr 10, 2012, at 7:24 AM, Tim Eberhard wrote:
I find it humorous that you think J/SRX junos isn't real junos.
So what makes it not real junos? The fact it has a flowd process? Lets technically talk about this for a moment.
The fact that you can't put it into flow mode.
Realistically one of the only differences between "flow based junos" and the legacy "packet based junos" is the flowd process. Which can be easily bypassed by issuing a couple of configuration commands. So what exactly makes this platform/code so horrible and not "real" junos?
Actually, not. Try again. It can be partially bypassed. There are real and serious differences in how forwarding works in flow-based JunOS and how it behaves under many circumstances.
If anything to me it's a better platform to deploy and learn on. It's more flexible as it comes with more advanced flow based features but they are optional. There are certain limitations as mentioned previously around the switching and class of service however these same feature limitations were also in the "real" junos low end devices.
They aren't entirely optional and that is the problem. You can't actually completely bypass them and they do sometimes get in the way.
If there are other differences that I am unaware of then by all means feel free to educate me. I am well aware that branch devices don't have the capabilities of the MX/M series in regards to ATM and other such specific platforms, but you called this "not real junos". So lets keep any responses limited to that aspect.
I believe that the flow-based routing goes quite a bit deeper than just having a flowd. It causes a number of problems with tunnel recursion among other things. Sure, if you want a firewall, flow-based JunOS is a pretty nice set of firewall features. However, if you just want to forward packets, it can really suck to have to work around it's flow-based "features". Owen
-Tim Eberhard
On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong <owen@delong.com> wrote:
If you want real JunOS, avoid SRX or J series at all costs.
Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world).
Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products.
If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for < $500 used).
With the caveat about Services JunOS above.
Owen
On Apr 10, 2012, at 7:58 AM, Owen DeLong wrote:
On Apr 10, 2012, at 7:24 AM, Tim Eberhard wrote:
I find it humorous that you think J/SRX junos isn't real junos.
So what makes it not real junos? The fact it has a flowd process? Lets technically talk about this for a moment.
The fact that you can't put it into flow mode.
s/flow/packet/ (oops, wasn't awake yet)
Realistically one of the only differences between "flow based junos" and the legacy "packet based junos" is the flowd process. Which can be easily bypassed by issuing a couple of configuration commands. So what exactly makes this platform/code so horrible and not "real" junos?
Actually, not. Try again. It can be partially bypassed. There are real and serious differences in how forwarding works in flow-based JunOS and how it behaves under many circumstances.
If anything to me it's a better platform to deploy and learn on. It's more flexible as it comes with more advanced flow based features but they are optional. There are certain limitations as mentioned previously around the switching and class of service however these same feature limitations were also in the "real" junos low end devices.
They aren't entirely optional and that is the problem. You can't actually completely bypass them and they do sometimes get in the way.
If there are other differences that I am unaware of then by all means feel free to educate me. I am well aware that branch devices don't have the capabilities of the MX/M series in regards to ATM and other such specific platforms, but you called this "not real junos". So lets keep any responses limited to that aspect.
I believe that the flow-based routing goes quite a bit deeper than just having a flowd. It causes a number of problems with tunnel recursion among other things.
Sure, if you want a firewall, flow-based JunOS is a pretty nice set of firewall features. However, if you just want to forward packets, it can really suck to have to work around it's flow-based "features".
Owen
-Tim Eberhard
On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong <owen@delong.com> wrote:
If you want real JunOS, avoid SRX or J series at all costs.
Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world).
Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products.
If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for < $500 used).
With the caveat about Services JunOS above.
Owen
On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote:
The fact that you can't put it into flow mode. s/flow/packet/ (oops, wasn't awake yet)
Actually, this is possible: prox@asgard> show configuration security forwarding-options { family { inet6 { mode packet-based; } mpls { mode packet-based; } } } The above is from an SRX210B, but the same configuration will work on any J-series or /branch/ SRX-series platform. Don't let the "mpls" keyword throw you off. This actually causes the box to run the inet /and/ mpls address families in packet mode. - Mark -- Mark Kamichoff prox@prolixium.com http://www.prolixium.com/
On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote:
On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote:
The fact that you can't put it into flow mode. s/flow/packet/ (oops, wasn't awake yet)
Actually, this is possible:
prox@asgard> show configuration security forwarding-options { family { inet6 { mode packet-based; } mpls { mode packet-based; } } }
The above is from an SRX210B, but the same configuration will work on any J-series or /branch/ SRX-series platform.
Right, sort of. To the extent that it works. It doesn't actually do everything you think it should, and, it's somewhat dependent on the version of JunOS as to how well it does or doesn't work.
Don't let the "mpls" keyword throw you off. This actually causes the box to run the inet /and/ mpls address families in packet mode.
I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for over a year and it escalated quite high up their escalation chain before they finally admitted "Yeah, Services JunOS is different and it behaves differently and if you need to do what you're trying to do, you should buy an M or MX series." It's quite unfortunate. I'd really like for the SRX series to not be so crippled for my purposes. Owen
On 11 Apr 2012, at 02:34, "Owen DeLong" <owen@delong.com> wrote:.
Don't let the "mpls" keyword throw you off. This actually causes the box to run the inet /and/ mpls address families in packet mode.
I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for over a year and it escalated quite high up their escalation chain before they finally admitted "Yeah, Services JunOS is different and it behaves differently and if you need to do what you're trying to do, you should buy an M or MX series."
It's quite unfortunate. I'd really like for the SRX series to not be so crippled for my purposes.
Do you have an example of this crippledness? -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, April 10, 2012 9:31 PM To: Mark Kamichoff Cc: jgoodwin@studio442.com.au; nanog@nanog.org Subject: Re: Cheap Juniper Gear for Lab
It's quite unfortunate. I'd really like for the SRX series to not be so crippled for my purposes.
Owen
While it may not forward packets exactly like an M-series or MX, for the OP's purpose of simply learning JUNOS in a home lab, it will work just fine. I learned quite a bit using Olives (which don't exist), with the understanding that there were a lot of limitations. To the OP, I would also suggest checking out Juniper's website, specifically the 'Education' section. There are a ton of excellent learning tools on there - Learning Bytes, Web-Based Training, Day One books, etc.: http://www.juniper.net/us/en/training/jnbooks/ https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5853 https://learningportal.juniper.net/juniper/user_courses.aspx -evt
Yeah, I have to apply the term "awful" and "annoying" to the packet mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC on the phone trying to get the thing to just pass packets. Best part was, I didn't know how to do it and nor did they! I escalated, worked with many engineers. My key statement was "I just want my router to route. Make it do what it is supposed to do. No session tracking! This is not a firewall." So, now it doesn't require valid sessions to pass packets but it does still appear to *track* sessions in some tables and I am, of course, very curious when some attack vector will fill up some table. Anyway, not the best devices for an edge router that is for sure. Which is too bad... for very small DC edge applications, the J6350 was a pretty cool router in earlier versions of JunOS that didn't decide to re-engineer your network and transit for you. Anyway I digress. But this had, in the past, been a frustrating enough issue for me that I had to share. --Carl On Tue, Apr 10, 2012 at 6:30 PM, Owen DeLong <owen@delong.com> wrote:
On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote:
On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote:
The fact that you can't put it into flow mode. s/flow/packet/ (oops, wasn't awake yet)
Actually, this is possible:
prox@asgard> show configuration security forwarding-options { family { inet6 { mode packet-based; } mpls { mode packet-based; } } }
The above is from an SRX210B, but the same configuration will work on any J-series or /branch/ SRX-series platform.
Right, sort of. To the extent that it works. It doesn't actually do everything you think it should, and, it's somewhat dependent on the version of JunOS as to how well it does or doesn't work.
Don't let the "mpls" keyword throw you off. This actually causes the box to run the inet /and/ mpls address families in packet mode.
I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for over a year and it escalated quite high up their escalation chain before they finally admitted "Yeah, Services JunOS is different and it behaves differently and if you need to do what you're trying to do, you should buy an M or MX series."
It's quite unfortunate. I'd really like for the SRX series to not be so crippled for my purposes.
Owen
-- Carl Rosevear Manager of Operations Skytap, Inc. direct (206) 588-8899
Anyway, not the best devices for an edge router that is for sure. Which is too bad... for very small DC edge applications, the J6350 was a pretty cool router in earlier versions of JunOS that didn't decide to re-engineer your network and transit for you.
We have 3 J2320s in the lab, all running 9.3R3.8. That's the last *real* JunOS (no session/flow tracking) for these boxes. They'll stay in the lab, and they'll never be upgraded to anything newer. Which is too bad, I had great hopes for the J series. But at least they're nice boxes to teach the JunOS CLI and things like that... Steinar Haug, Nethelp consulting, sthaug@nethelp.no
We have 3 J2320s in the lab, all running 9.3R3.8. That's the last *real* JunOS (no session/flow tracking) for these boxes.
+1 on that. We have a number of 2300s in our lab for the same purpose running 8.x code. We also use Junosphere extensively, but nothing beats real hardware. j2300s are cheap. Jay
-----Original Message----- From: Jay Hanke [mailto:jay.hanke@mankatonetworks.com] Sent: Wednesday, April 11, 2012 1:03 PM To: sthaug@nethelp.no Cc: nanog@nanog.org .Subject: Re: Cheap Juniper Gear for Lab
We have 3 J2320s in the lab, all running 9.3R3.8. That's the last *real* JunOS (no session/flow tracking) for these boxes.
+1 on that. We have a number of 2300s in our lab for the same purpose running 8.x code.
We also use Junosphere extensively, but nothing beats real hardware. j2300s are cheap.
Jay
So, I have a question, then. For the purposes of learning JUNOS, is 8.3 code sufficient? Would you be missing a lot of features that are in newer code? I would assume IPv6 features are different between 8.3 and the latest code, is that right? Tom ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801)674-9273 tom.ammon@utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -------------------------------L-O-------------------------------------------
sthaug@nethelp.no writes:
Anyway, not the best devices for an edge router that is for sure. Which is too bad... for very small DC edge applications, the J6350 was a pretty cool router in earlier versions of JunOS that didn't decide to re-engineer your network and transit for you.
We have 3 J2320s in the lab, all running 9.3R3.8. That's the last *real* JunOS (no session/flow tracking) for these boxes.
They'll stay in the lab, and they'll never be upgraded to anything newer. Which is too bad, I had great hopes for the J series.
Got a pair of J2350s in the previous job to run as part of a command and control network. Had the same "I just want this stuff to route!" experience that others have mentioned and griped about. We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs. That came in 10.1 or something. As a member of the ARIN Advisory Council, I felt compelled to eat the same dog food that I was selling, and we found ourselves at an impasse. We ended up putting the C&C network in VRFs on a couple of MX80s that were already there. With a few contemptuous comments on the side we sent the 2350s back to the VAR. I think my successors ended up undoing the VRFs and putting Cisco 2951s in their place. I've heard it hypothesized that this change was related to the costs of maintaining two different packet forwarding paths (remember that the J series used, in 9.3 and before, an emulation of the ASIC in the hardware based routers) and that, having decided to cancel one, they decided to cancel the "less featureful" one. This is a reasonable decision to make even if we don't like it as techies. None of the difficulties we had, however, would have gotten in the way of the OP's apparent goal of getting comfortable typing things like "show chassis environment", "request system software add", "show config | display set", and "show version and haiku". Unlike Owen I'm not going to say "useless due to security { ... }", I'm going to say "useful with caveats, and you might want to think twice about what you're trying to do before moving it out of the lab". -r
On 4/12/2012 2:47 AM, Robert E. Seastrom wrote:
We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs. That came in 10.1 or something.
Hi, we are running Model: j2350 JUNOS Software Release [9.3R4.4] and had: neighbor 41.188.165.50 { description AfNOG_Whitesands; peer-as 327686; } with success. (and several on this list used it ~10months ago) so, a 32-bit AS as neighbor works, not sure if you meant router's own AS to be 32-bit. Regards, Frank
On 12/04/12 09:47, Robert E. Seastrom wrote:
We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs. That came in 10.1 or something. As a member of the ARIN Advisory Council, I felt compelled to eat the same dog food that I was selling, and we found ourselves at an impasse.
Er, I think you're probably meaning 8.3 and 9.1. (32-bit ASN's were introduced in 9.1, and I don't remember seeing anything in the release notes for 10.x about them)
On 11 Apr 2012, at 18:36, "Carl Rosevear" <crosevear@skytap.com> wrote:
Yeah, I have to apply the term "awful" and "annoying" to the packet mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC on the phone trying to get the thing to just pass packets. Best part was, I didn't know how to do it and nor did they! I escalated, worked with many engineers. My key statement was "I just want my router to route. Make it do what it is supposed to do. No session tracking! This is not a firewall." So, now it doesn't require valid sessions to pass packets but it does still appear to *track* sessions in some tables and I am, of course, very curious when some attack vector will fill up some table.
I have had some rather odd issues with the SRX boxes but JTAC were pretty good at turning around fixes for me for my specific issues. Since then I have had quite a lot of SRX boxes across the range running various MPLS services including MPLS over GRE with fragmentation/reassembly which has been working very well. Since 11.1R3 I've had no issues at all with them. So yeah the new flow mode stuff had its issues, but as a *small* MPLS box it is very functional. Of course in MPLS mode, you turn the flow stuff off.. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
FWIW, when I took my JNCIE, I used all J-series running flow code (disabled) for my study pod and never had any issues. I have 9 physical routers plus a bunch of VRs on them. I agree there can be issues depending on what you are trying to do, but I am not sure why this is such a big deal if this is just a lab setup. I wouldn't test something on a J-series and expect to deploy it on M/MX/T in production or something, but that wasn't what the OP was asking to do. For a home lab I can't think of any reason not to use some J-series boxes. -Jeff On Apr 11, 2012, at 1:29 PM, Leigh Porter wrote:
On 11 Apr 2012, at 18:36, "Carl Rosevear" <crosevear@skytap.com> wrote:
Yeah, I have to apply the term "awful" and "annoying" to the packet mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC on the phone trying to get the thing to just pass packets. Best part was, I didn't know how to do it and nor did they! I escalated, worked with many engineers. My key statement was "I just want my router to route. Make it do what it is supposed to do. No session tracking! This is not a firewall." So, now it doesn't require valid sessions to pass packets but it does still appear to *track* sessions in some tables and I am, of course, very curious when some attack vector will fill up some table.
I have had some rather odd issues with the SRX boxes but JTAC were pretty good at turning around fixes for me for my specific issues.
Since then I have had quite a lot of SRX boxes across the range running various MPLS services including MPLS over GRE with fragmentation/reassembly which has been working very well. Since 11.1R3 I've had no issues at all with them.
So yeah the new flow mode stuff had its issues, but as a *small* MPLS box it is very functional. Of course in MPLS mode, you turn the flow stuff off..
-- Leigh Porter
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
I was bitten by a similar issue when I deployed a couple of J2350s at our edge. On 4/11/12 2:33 PM, Carl Rosevear wrote:
Yeah, I have to apply the term "awful" and "annoying" to the packet mode implementation on SRX/J-series. Anyway, I spent *hours* with JTAC on the phone trying to get the thing to just pass packets. Best part was, I didn't know how to do it and nor did they! I escalated, worked with many engineers. My key statement was "I just want my router to route. Make it do what it is supposed to do. No session tracking! This is not a firewall." So, now it doesn't require valid sessions to pass packets but it does still appear to *track* sessions in some tables and I am, of course, very curious when some attack vector will fill up some table.
Anyway, not the best devices for an edge router that is for sure. Which is too bad... for very small DC edge applications, the J6350 was a pretty cool router in earlier versions of JunOS that didn't decide to re-engineer your network and transit for you.
Anyway I digress. But this had, in the past, been a frustrating enough issue for me that I had to share.
--Carl
On Tue, Apr 10, 2012 at 6:30 PM, Owen DeLong <owen@delong.com> wrote:
On Apr 10, 2012, at 6:02 PM, Mark Kamichoff wrote:
On Tue, Apr 10, 2012 at 11:57:31AM -0700, Owen DeLong wrote:
The fact that you can't put it into flow mode. s/flow/packet/ (oops, wasn't awake yet) Actually, this is possible:
prox@asgard> show configuration security forwarding-options { family { inet6 { mode packet-based; } mpls { mode packet-based; } } }
The above is from an SRX210B, but the same configuration will work on any J-series or /branch/ SRX-series platform.
Right, sort of. To the extent that it works. It doesn't actually do everything you think it should, and, it's somewhat dependent on the version of JunOS as to how well it does or doesn't work.
Don't let the "mpls" keyword throw you off. This actually causes the box to run the inet /and/ mpls address families in packet mode.
I'm not unfamiliar or uninitiated in this regard. I had tickets with Juniper for over a year and it escalated quite high up their escalation chain before they finally admitted "Yeah, Services JunOS is different and it behaves differently and if you need to do what you're trying to do, you should buy an M or MX series."
It's quite unfortunate. I'd really like for the SRX series to not be so crippled for my purposes.
Owen
On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard <xmin0s@gmail.com> wrote:
I find it humorous that you think J/SRX junos isn't real junos.
If it runs JunOS, then yeah, it's real JunOS. It might not have the feature you're looking for, but that's something different. The Juniper ERX edge routers are what isn't "real" JunOS. It's as if they were trying to make a clone of the IOS CLI: http://www.juniper.net/techpubs/en_US/junose10.2/information-products/topic-... -- -JH
On Apr 10, 2012, at 4:05 PM, Jimmy Hess wrote:
On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard <xmin0s@gmail.com> wrote:
I find it humorous that you think J/SRX junos isn't real junos.
If it runs JunOS, then yeah, it's real JunOS. It might not have the feature you're looking for, but that's something different.
No, it's not. Flow mode is NOT packet mode and it doesn't really ever run packet mode in the current version. This has fundamental and significant impacts on the way packets are handled when being forwarded through the box which come with side-effects that cannot be overcome by mere configuration changes.
The Juniper ERX edge routers are what isn't "real" JunOS. It's as if they were trying to make a clone of the IOS CLI:
Those are not JunOS at all. They don't really try to pretend to be. The SRX and J-Series Services routers, OTOH, are most definitely pretending to be JunOS while not behaving like JunOS at certain fundamental levels. Owen
Owen, While I know you are a smart engineer and obviously have been working with this gear for a long time you're really not adding anything or backing up your argument besides saying yet again the packet forwarding is different. While this maybe true..It's my understanding that enabling packet mode does turn it into a normal packet based junos. Admittedly I have limited experience with turning these branch devices into pure packet mode so instead of repeating the same thing over and over why not provide links and other documentation showing the difference? On Tue, Apr 10, 2012 at 8:23 PM, Owen DeLong <owen@delong.com> wrote:
On Apr 10, 2012, at 4:05 PM, Jimmy Hess wrote:
On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard <xmin0s@gmail.com> wrote:
I find it humorous that you think J/SRX junos isn't real junos.
If it runs JunOS, then yeah, it's real JunOS. It might not have the feature you're looking for, but that's something different.
No, it's not. Flow mode is NOT packet mode and it doesn't really ever run packet mode in the current version. This has fundamental and significant impacts on the way packets are handled when being forwarded through the box which come with side-effects that cannot be overcome by mere configuration changes.
The Juniper ERX edge routers are what isn't "real" JunOS. It's as if they were trying to make a clone of the IOS CLI:
Those are not JunOS at all. They don't really try to pretend to be.
The SRX and J-Series Services routers, OTOH, are most definitely pretending to be JunOS while not behaving like JunOS at certain fundamental levels.
Owen
In a message written on Tue, Apr 10, 2012 at 08:31:04PM -0500, Tim Eberhard wrote:
While I know you are a smart engineer and obviously have been working with this gear for a long time you're really not adding anything or backing up your argument besides saying yet again the packet forwarding is different. While this maybe true..It's my understanding that enabling packet mode does turn it into a normal packet based junos.
I honestly don't remember what caused the problem when I ran into it, but the first time I configured IPv6 on a SRX I used per-packet and I had all sorts of problems. After contacting Juniper support and some friends who ran them they all told me to configure flow-based for IPv6, and it started working properly. Juniper support basically said IPv6 didn't work at all unless it was in flow mode. My vague memory at least was OSPFv3 would not come up in IPv6 per-packet mode no matter what changes were made, but with flow mode it came right up. In any event, I will back up Owen on this one. Any JunOS box with a security {} section (which I think means of Netscreen lineage) does a number of weird things when you're used to the JunOS boxes without a security section. For instance they basically default to a stateful firewall, so when I used a pair for redundancy and had asymmetrical paths it took way too many lines of config (4-5 features that had to be turned off) to make it not-stateful. That's a big surprise when you come from working on M-series. Still, they are very nice boxes, particularly for the capabilities you get at the price point. It's just that darn security {} section that seems to be quite poorly thought out, even all the working parts are just laid out in a way that's not intuitive to me and don't seem to match the rest of JunOS well. Want to list a netblock, you have to put it in an "address book". Want to list two, it has to be in an "address-book group", you can't just list them between brackets, and so on. It may be the only router platform where I turn to the web gui from time to time to configure things, otherwise it's an exercise in frustration trying to get the syntax right. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
I think GNS3 can emulate Juniper devices. http://www.gns3.net/ -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbrisson@uvm.edu On 4/10/12 12:31 AM, Steven King wrote:
Hello All,
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
Thanks!
There is no "olives". ;-) -- Eduardo Schoedler Em 10 de abril de 2012 10:03, Dan Brisson <dbrisson@uvm.edu> escreveu:
I think GNS3 can emulate Juniper devices.
-dan
Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbrisson@uvm.edu
On 4/10/12 12:31 AM, Steven King wrote:
Hello All,
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
Thanks!
-- Eduardo Schoedler ESDS Consultoria de TI
On 4/10/2012 5:31 AM, Steven King wrote:
Hello All,
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
Thanks!
Have you considered this http://www.juniper.net/us/en/products-services/software/junos-platform/junos... Regards, N.
http://www.juniper.net/us/en/products-services/software/junos-platform/junos... On Mon, Apr 9, 2012 at 10:31 PM, Steven King <sking@kingrst.com> wrote:
Hello All,
I am tasked with replacing an old linux router setup with Juniper gear in the near future. Though I am a Cisco guy myself.
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
Thanks!
-- Steve King
Network/Linux Engineer - AdSafe Media Cisco Certified Network Professional CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
-- -B
Does anyone know of any older cheap Juniper gear I might find on Ebay so that I may build a home lab without going broke?
I got my J series cheap off of ebay because it wouldn't power on. Turns out getting a replacement power supply was very difficult from Juniper or the manufacturer of the power supply. I ended up rebuilding a PC supply to do the job. Now to find rack ears and a module slot cover. Juniper quoted $150+ for the rack ears. If I can find a set, I think I might look to make a bunch of them.
participants (24)
-
Bret Clark -
brian nikell -
Carl Rosevear -
Carlos Martinez-Cagnazzo -
Dan Brisson -
Eduardo Schoedler -
Eric Van Tol -
Frank Habicht -
Jay Hanke -
Jeff Richmond -
Jimmy Hess -
Julien Goodwin -
Leigh Porter -
Leo Bicknell -
lorddoskias -
Mark Kamichoff -
Owen DeLong -
Randy Bush -
Robert E. Seastrom -
Steven King -
sthaug＠nethelp.no -
telmnstr＠757.org -
Tim Eberhard -
Tom Ammon