How do you remotely display debug output
Francis Garder
I am trying to get the debug info for Novell RIP and SAP traffic from
a cicso, and the cisco is hundreds of miles away so I can't plug a console
into it!!
According to the manual (release 9.1) I can use the 'terminal monitor'
command to get debug command output sent to the current terminal as well
as the console. I have done this then issued the 'debug novell-routing'
and 'debug novell-sap' commands..... but nothing appears to happen :-(
What have I missed??
Thanks in advance
Francis.
--
gard...@irl.cri.nz
Industrial Research Limited
Network Engineering
John Hawkinson
>According to the manual (release 9.1) I can use the 'terminal monitor'
>command to get debug command output sent to the current terminal as well
>as the console. I have done this then issued the 'debug novell-routing'
>and 'debug novell-sap' commands..... but nothing appears to happen :-(
That's correct. Note that you must type ``ter mon'' each type you
connect to this cisco via telnet.
Perhaps nothing is happening under those categories. Try something
like debug ip-icmp and then ping your router.
Additonally, debug-level messages are syslogged to the logging host.
--
John Hawkinson
jh...@panix.com
David Howard
|> In <f.gardner....@irl.cri.nz> f.ga...@irl.cri.nz (Francis Garder) writes:
|>
|> >According to the manual (release 9.1) I can use the 'terminal monitor'
|> >command to get debug command output sent to the current terminal as well
|> >as the console. I have done this then issued the 'debug novell-routing'
|> >and 'debug novell-sap' commands..... but nothing appears to happen :-(
|>
|> That's correct. Note that you must type ``ter mon'' each type you
|> connect to this cisco via telnet.
Here's what I do...
enable [password]
ena mon
term mon
debug [x]
I forget where the need for "ena mon" came from, but it seems as if I need both
to get the debugging info....
--
"Oh, to be one's own boss so that the views of one and one's
employer may coincide." - 'NETter's Lament (And mine !)
"Shit doesn't >happen<, shit >is<..." - Nominalistically Me
Steve Cunningham
In article <2tj6gi$m...@panix.com>, <jh...@panix.com> writes:
> Path: > Subject: Re: How do you remotely display debug output
> Date: 13 Jun 1994 23:00:34 -0400
>
>
> >According to the manual (release 9.1) I can use the 'terminal monitor'
> >command to get debug command output sent to the current terminal as well
> >as the console. I have done this then issued the 'debug novell-routing'
> >and 'debug novell-sap' commands..... but nothing appears to happen :-(
>
> That's correct. Note that you must type ``ter mon'' each type you
> connect to this cisco via telnet.
>
> Perhaps nothing is happening under those categories. Try something
> like debug ip-icmp and then ping your router.
>
> Additonally, debug-level messages are syslogged to the logging host.
>
> --
> John Hawkinson
> jh...@panix.com
-------------------------------------------------------------------
Please check what is logging where ( show logging ) !
If you have syslog going to a host somewhere and you then set about
a nice long debug session from a term ( term mon ) your box is doing
double work and sending every debug message to your syslog server.
So, the trap springs : ( I have done this so giggle away )
Details of trap ( have term mon and syslogging going )
Do a hefty debug session, fix a problem and feel like a hero !
Then the phone rings as the server has a disk full error
since your nifty hero producing session filled up the file system
on your syslog server. Groan . . .
So here is what we do : In the config file I turn off all
logging no console logging ( or is it no logging console ) etc.
I only do syslog for higher than debug messages ( so debug doesn;t
get logged )
Now when I need to do debug I temporarily turn on the console
or the terminal to do my thing. When finished turn logging off again
and check sho logg to make sure.
Another tip from John Wright ( I think ). The console has a higher
priority than a vty so don't debug from the console. And set a scheduler
interval in the box, which allows the processor to check other processes
periosically. Then always debug from a vty. If the box is busy and
you are a little too vigorous with debugging and the box is starting to sink,
quickly run, don't walk to your console and kill the session on the vty. If
you are on the console your debugging has top prioority and then the only way
out is the power switch. This of course makes remote debugging a real
sweaty palms adventure especially on a crowded box. Caveat debugger !
steve
Paul Ferguson
> Another tip from John Wright ( I think ). The console has a higher
> priority than a vty so don't debug from the console. And set a scheduler
> interval in the box, which allows the processor to check other processes
> periosically. Then always debug from a vty. If the box is busy and
> you are a little too vigorous with debugging and the box is starting to sink,
> quickly run, don't walk to your console and kill the session on the vty. If
> you are on the console your debugging has top prioority and then the only way
> out is the power switch. This of course makes remote debugging a real
> sweaty palms adventure especially on a crowded box. Caveat debugger !
Heh... Try 'debug source-bridge' sometime. Preferrably in the middle
of the business day. Oh, and make sure that you do it remotely.
,-)
_______________________________________________________________________________
Paul Ferguson
US Sprint
Managed Network Engineering tel: 703.904.2437
Herndon, Virginia USA internet: pa...@hawk.sprintmrn.com
John Hawkinson
>Heh... Try 'debug source-bridge' sometime. Preferrably in the middle
>of the business day. Oh, and make sure that you do it remotely.
I've alwaysed preferred ``debug all'' myself. Non of those
protocol/environment dependancies, 'ya know...
--
John Hawkinson
jh...@panix.com
Peter P Morrissey
We are about to increase our dial-up lines by about 32-64 ports this
fall due to increased demand. We will be offering SLIP and/or PPP and
possibly ARA along with the usual telnet.
We currently own an ASM that is fully populated. We are running
TACACS for authentication.
One dilemma is whether to buy another ASM which offers a lower cost per
port, or CSC 500's which are more expensive, but offer full hardware
flow control and more processors per port. The other issue is that
we will need a greater number of CSC500's, thus adding management and
administration overhead.
While cost is an important issue, we have also heard that the ASM is
going to be discontinued, which is supposedly the reason they will
not be coming out with a board that will do full hardware flow control
for it.
The other question is, How much value does hardware flow control add?
Better performance? Less load on processor? Has anyone benchmarked
any of this?
The ASM does have hardware flow control "out" which is the direction where
the most volume of data will be moving as people grab stuff off the Internet
and our timesharing systems. Perhaps this is really all we need anyway?
Then what about the DTE speed limitation of 38K. With the v.34 standard
imminent, it will soon be practical to buy modems that have a theoretical
best case aggregate DTE speed of >100K with compression. Is it wise to
invest in any hardware that will not be able to take advantage of the next
generation of modems' speed capabilities? Someone correct me if I'm wrong,
but I don't think this is an ASM v. CSC 500 issue. I do believe that
it really needs to be addressed.
Pete Morrissey
Syracuse University
Yaron Zabary
> Then what about the DTE speed limitation of 38K. With the v.34 standard
> imminent, it will soon be practical to buy modems that have a theoretical
> best case aggregate DTE speed of >100K with compression. Is it wise to
> invest in any hardware that will not be able to take advantage of the next
> generation of modems' speed capabilities? Someone correct me if I'm wrong,
> but I don't think this is an ASM v. CSC 500 issue. I do believe that
> it really needs to be addressed.
You are dead right. Same dilemma here. I was thinking about SCSI
terminal servers, DEC terminal server (some of them even have Kerberos !),
but the CS-500 has all these nice features (Xremote is available only from
Cisco). It just that this 38K problem makes me sit on the fence for a very
long time now. I would have bought three of them if they were running at
57K (or better yet at 115K), no matter what they cost.
>
> Pete Morrissey
> Syracuse University
--
Karl Denninger
Two words on this issue:
Telebit Netblazer
The MEC-8 card for these units can run 115kbps, their older serial cards
have always supported 57.6 (which is what we run here).
CISCO makes great routers, and MCSNet owns a number of them (3102s and AGS+,
and we're considering a 7100).
I wouldn't use their terminal servers through. CISCO is *way* behind the
other guys in the terminal server department.
All IMHO, of course, and I'm biased -- I own a *lot* of Netblazers.
--
--
Karl Denninger (ka...@MCS.Net)| MCSNet - The Finest Internet Connectivity
Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland
Voice/FAX: [+1 312 248-8649] | Email "in...@mcs.com". MCSNet is a CIX member.
Ask about "MCSNet Rewards" | WWW: http://www.mcs.net, gopher: gopher.mcs.net
Sesquipedalian
>
> You are dead right. Same dilemma here. I was thinking about SCSI
> terminal servers, DEC terminal server (some of them even have Kerberos !),
> but the CS-500 has all these nice features (Xremote is available only from
> Cisco). It just that this 38K problem makes me sit on the fence for a very
> long time now. I would have bought three of them if they were running at
> 57K (or better yet at 115K), no matter what they cost.
>
You might look at Xyplex's terminal servers. I believe they offer Xremote,
Kerberos, ARAP, TN3270, and some other stuff, too. Some models are restricted
to 38K (older models), but most will run at 57.6K or 115K, depending on the
model. For 115K, look at an MX-1620. I have no idea how they compare
price-wise (I've never priced CS500's), but we have a lot of them and have been
happy, though I don't run any at 115K.
Kevin Yoders
System and Network Manager
Wittenberg University