On Thu, Feb 01, 2001 at 06:50:21PM -0500, Martin, Christian wrote:
> >
> > They do that too. Understand, the LONG term goal is to be able to
> > eliminate the need for the shell. Anytime you have to go to
> > the shell to
> > accomplish something you should open a case with JTAC so the
> > feature can be
> > added to the CLI.
>
> What is the time-frame for this?
Depends on the feature and the priority among it and the other
projects.
>
> > > And, why would a shell tool break routing?
> >
> > If you run out of memory due to a shell-tool memory leak, you
> > are out of
> > memory for everything. If your shell-tool starts sucking all
> > the CPU then
> > routing updates may not get done in a timely fashion. Part
> > of our tuning
> > is to make sure the existing tools can't do this to us.
>
> Hrmm. Interesting. What about this shell script?
>
> #!/bin/sh
> # foo.sh - dumb script to explode the process list and kill my M-Fotay
>
> while [ 1 ]
> do
> ./foo.sh
> done
>
> Should break routing pretty easily. However, this is supported by Juniper?
> Or are shell scripts unsupported? If so, then why have the shell available
> to customers?
Precisely our point. The shell is bad for router stability in the
hands of the unclued. Since we can't count on all our customers
being clued and headlines like "Juniper router failure causes major
network outage" are not desirable, we need to ultimately make it
clueless proof. Or, at least we need to try.
> known engineering holes (read: 'debug-eng> show saint', etc) yet they don't
> make them available. If I am foolish enough to jack with the Whistler
> registers on a Cat and the box decides never to work again, I can always
> shut-up, play dumb, and request an RMA...
Box failure is bad. Network failure is catastrophic. Routers dying
in malignant ways can cause (have caused (when I was at "the other
company")) Network failure.
>
> My personal opinion is to not stick stuff on the box because it may in fact
> cause problems. And I understand that J-TAC cannot support a box that is
> broken because of external software. But, you can't leave the keys to the
> Porsche on the table, go on vacation, and expect the Fresh Prince not to
> take it for a cruise... ;)
Keys are for the clueful (assuming there is at least one at each
company (yes, dangerous assumption)). The clueful should configure
the box such that the untrained can't get access to the shell.
> On moving everything to the CLI - should be done, but there are particular
> tools in the shell that may not be easily ported, like sed and awk, or perl.
None of which belong on a router.
> Yet I believe the TAC uses (and customers use) these tools to parse
> log-files and such.
Move the log-files to your workstation and then parse to your hearts
content.
> Ultimately, customers _will_ break their routing one way or another. May as
> well let 'em run a shoutcast server on the box to do so.
First statement: true. Second statement: false.
> Now, would someone kindly answer my SONET question! ;)
I've forwarded it to someone who should be able to. It is beyond my
ability. (;->)
GK
>
> chris
>
> > >>J-TAC is great. Hope it stays that way!
> >
> > Me too!
> > GK
> >
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:40 EDT