[152044] in North American Network Operators' Group
Re: Cheap Juniper Gear for Lab
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Apr 10 15:02:38 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <3B729EA8-5782-4D29-AC33-FD2CE5AA7FC6@delong.com>
Date: Tue, 10 Apr 2012 11:57:31 -0700
To: Owen DeLong <owen@delong.com>
Cc: jgoodwin@studio442.com.au, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 10, 2012, at 7:58 AM, Owen DeLong wrote:
>=20
> On Apr 10, 2012, at 7:24 AM, Tim Eberhard wrote:
>=20
>> I find it humorous that you think J/SRX junos isn't real junos.
>>=20
>> So what makes it not real junos? The fact it has a flowd process? =
Lets
>> technically talk about this for a moment.
>>=20
>=20
> The fact that you can't put it into flow mode.
s/flow/packet/
(oops, wasn't awake yet)
>=20
>> 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?
>=20
> 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.
>=20
>> 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.
>=20
> 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.
>=20
>> 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.
>=20
> 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.
>=20
> 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".
>=20
> Owen
>=20
>>=20
>> -Tim Eberhard
>>=20
>>=20
>>=20
>> On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong <owen@delong.com> wrote:
>>=20
>>> If you want real JunOS, avoid SRX or J series at all costs.
>>>=20
>>>> 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).
>>>>=20
>>>=20
>>> Don't forget their SSL VPN boxes which are an acquired doesn't =
behave at all like a Juniper device line of products.
>>>=20
>>>> 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).
>>>=20
>>> With the caveat about Services JunOS above.
>>>=20
>>> Owen
>>>=20
>>>=20
>=20
