RE: GSR, 7600, Juniper M?, oh my!

Mailman List Mirror (Read Only)
1

Richard A Steenbergen wrote:
I already have a very nice empty M160
chassis for a chair at the colo,

I don't like it for a chair, too high (29"); A 7500 is a lot better for
that use. It's really nice as a heater too, particularly a dual AC
loaded with legacy blades. Other possible uses for a 7500 include a
temperature sensor
(Router temperature).

My views on the original question:

Cisco vs. Juniper: Whatever some people might say, everyone that uses
both will tell you that the real picture is not Cisco=100% crap and
Juniper=100% perfect :slight_smile: Besides, if you're a Cisco shop it's hard to
find sound arguments to have only one or two Junipers (common business
sense: twice the training, each one rejecting responsibility on the
other, more difficult to find JunOs experts than IOS experts, etc...).

7600 vs. GSR: These are not the same boxes. There is stuff that the 7600
won't do, but there's also stuff that the GSR won't do in terms of
aggregating a bunch of disparate links together.

Michel.

2

Never under any condition let anyone tell you that Juniper is perfect...
But, as everyone that uses both will tell you, it is "better" (at most
things).

3

Richard A Steenbergen wrote:

Never under any condition let anyone tell you that Juniper is perfect...
But, as everyone that uses both will tell you, it is "better" (at most
things).

They tend to be (in our experience) a "set it and forget it" thing, while you can spend considerable time tweaking your Cisco; but admittedly ours is just an M5 edge (two gig-Es into an OC48). The rest of our gear is Cisco, and yes, we draw straws to see who has to mess with the Juniper when it has to be messed with.

And speaking ancient history, we retired a 7505/RSP1 to the testbed a few years ago. It had two 6E cards (original core) and later a 2FE to play router-on-a-stick to a 5500/NFFC-II.

We're now using 6500s (core) and 4500s/3550s (distribution). The old RSP1 looks pretty silly now :slight_smile:

Jeff

4

> Never under any condition let anyone tell you that Juniper is perfect...
> But, as everyone that uses both will tell you, it is "better" (at most
> things).

They tend to be (in our experience) a "set it and forget it" thing,
while you can spend considerable time tweaking your Cisco; but
admittedly ours is just an M5 edge (two gig-Es into an OC48). The rest
of our gear is Cisco, and yes, we draw straws to see who has to mess
with the Juniper when it has to be messed with.

  If you can set aside time to study JUNOS a bit perhaps the straw draws
  won't be necessary! Although you are correct about the "set and forget"
  nature of JUNOS vs other platforms, especially when the larger DDOS's
  hit...

  The 1980's origin of IOS becomes clear when you look at more modern
  systems like JUNOS, especially if you've had structured and/or
  object oriented programming.
  
  Many interesting network solutions that have to be dismissed outright
  because of IOS limitations, weaknesses or bugs can be easily expressed
  in newer systems, not just JUNOS.

  If you have the time to give them a look, the non-IOS systems have
  ALOT to offer in terms of expressing new/innovative ways to solve
  networking design/arch problems.

  Its too bad Juniper never released the old "Olive" JUNOS's for
  general download; they worked on stock x86 hardware with Intel
  and 3com(?) ethernet interfaces. They were GREAT for learning
  JUNOS on. Maybe Juniper will rethink that decision
  for marketing gains of exposing more people to JUNOS?

  -Rob

5

Many interesting network solutions that have to be dismissed outright
because of IOS limitations, weaknesses or bugs can be easily expressed
in newer systems, not just JUNOS.

Example, please.

(Agree with Jiniper OS for x86 - many people avoid Juniper because do not
know it).

6

"used to be..." One could lay hands on a magic Cd that
turned an ordinary PC with (Commonly available but the Brand
Escapes me) Nics into a Juniper Olive that ran the full
JunOS. It has disappeared, much to the disappointment of
those of us that would love to use one to study for a
cert/resume fodder.

-Ejay

From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]

On

7

"used to be..." One could lay hands on a magic Cd that
turned an ordinary PC with (Commonly available but the Brand
Escapes me) Nics into a Juniper Olive that ran the full
JunOS. It has disappeared, much to the disappointment of
those of us that would love to use one to study for a
cert/resume fodder.

If one were searching for ISO images of such a thing, what would perhaps
be some keywords to type into one's P2P application?

Charles

8

Ejay,

Those would be Intel NICs.

9

> Many interesting network solutions that have to be dismissed outright
> because of IOS limitations, weaknesses or bugs can be easily expressed
> in newer systems, not just JUNOS.

Example, please.

  Due to a barrage of e-mails I received on the subject I thought I'd
  send a generic reply to the list rather than try to cook up a plethera
  of examples on a one-to-one basis...

  First, if you haven't done so already, I suggest watching the Intro
  to JUNOS web training session on the juniper.net web site:

  Juniper Networks US – Leader in AI Networking, Cloud, & Connected Security Solutions

  Next, the full docs for JUNOS are available without registration at

  Documentation | Juniper Networks

  For M series, click on the software link and pick the highest version
  listed their; 6.x would be the most current.

  Once you've looked at the training video and downloaded the docs you
  should be able to drill down to the areas that interst you most. The
  comprehensive index might be good to actually print out for handy
  reference.

  Some areas of interest might include:

  Group inheritance

  Using function/procedure invocation in policys

  Virtual router features; N logical routers in 1 box, more extensive
     than Redback contexts.

  Operational goodies:

  "Auto Chicken mode" - Basically the JUNOS config is a database and
     as such you commit changes. You can do an auto reverting commit that
     restores a known good config after N minutes if the candidate config
     isn't confirmed; i.e. "#$%#%#$, I just downed the infrastructure link
     on a remote router"... See "commit confirmed <x>" for details. This
     feature has been rumored to have saved many a chicken hide!

   You can leave insane levels of debug turned on without killing the
   routing or forwarding engines.

For Juniper: ( You know who you are! )

   Why not release an "Olive CD" with each new major JUNOS bump? It
   wouldn't hurt to have every schmoe in the universe that can boot
   a FreeBSD ISO also be competant in JUNOS! Place it as an iso download
   in the software docs area.

   For the squemish in the legal dept. you could remove the code that
   handles Juniper hardware from the distro and still have an excellent
   CLI engine and minimal routing platform simulator.

   I bet if you passed out a stack of "Olive CD's" at a NANOG there would
   be plenty of takers!

  -Rob

10

I still think there is a market for low-end 100Mbps-only "PC routers" for
which they could easily sell thousands of copies of JunOS without the jpfe
package at $1000 a pop. Considering they actually managed to add
hardware-less firewalling in 5.x, I'm still not entirely convinced that
they aren't thinking the same thing. But alas, it's probably too
innovative a concept, and might cut into the "stupid with too much money"
M5 buying market a tiny bit.