Cheap Juniper Gear for Lab

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.

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

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

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

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..

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

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

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

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)

I was bitten by a similar issue when I deployed a couple of J2350s at
our edge.