It's interesting that by quickly perusing the thread one that one could infer an equation of troubleshooting tool with "device capable of revealing the content of packets sent across the transmission medium."
I'd have to agree that making that sort of data readily available to those stuck bet is not the Cisco router family's /IOS' strong point. I'd have to note that this is somewhat vendor specific. Nortel routers not currently serving as dust epicenters in technology museums ARE, to some extent, packet sniffers (via pcap), but then again, since they didn't deliberately assemble the most underpowered microprocessor-based boxes they could get away with, the difference approaches understandability. I'd have to concur that having packet captures available is my first choice as far as implements of troubleshooting are concerned (it's amazing what a dedicated sniffer pc at a remote workstation can do to reduce the number of sleepless nights spent on seemingly intractable problems). I'd have to say that I've recently come to regard snmp-enabled CSU/DSU's as a reasonable substitute for overpriced, media-specific inline WAN packet capturing tools. Certain debug argument hierarchies, for example those associated with ppp & ospf, DO give enough header information to solve some problems such as mtu negotiation mismatches. ----- Original Message ----- From: "Priscilla Oppenheimer" To: Sent: Friday, May 24, 2002 4:30 PM Subject: Re: Provider Backbone Engineering and CCIEs [7:44876] > Well, maybe I overstated it a bit. ;-) My main complaint about the debug > commands is that the output is too cryptic. Also, some of them were clearly > designed for the Cisco developers not for the end user of the router > (network admin, engineer). The information they provide is simply not > helpful. > > Inserting a sniffer can definitely be a pain on a WAN, on the other hand. > Plus WAN sniffers are terribly expensive. Actually inserting a sniffer is > more of a pain than it used to be on LANs too. But at least the result is a > plain-language decode of every packet. > > By the way, do you remember which EIGRP debug commands you used and how > they helped solve the problem? That might be helpful info for us (if you > have time to explain, no biggie if you don't.) > > Thanks > > Priscilla > > At 03:35 PM 5/24/02, MADMAN wrote: > >I have to respectfully disagree, > > > > Done correctly with caution when necessary the router is an excellant > >and often the only troubleshooting tool. If your unpacking a Sniffer > >your in deep doo doo as it's quite rare I require it to solve a network > >problem. Don't get me wrong, they are essential and have a purpose but > >too often people are going too deep too fast to solve problems that do > >not require an analyzer. > > > > I used a couple of EIGRP debugs yesterday to help a hospital whose > >core 6500 was melting down and for those that do remote support debug is > >our friend. > > > > DebugDave > > > > > >Priscilla Oppenheimer wrote: > > > > > > At 07:32 AM 5/24/02, dre wrote: > > > > Cisco router to solve any problem, even those that shouldn't be solved > > > >with > > > >a router! > > > > > > And how about all the people who try to turn the router into a > > > troubleshooting tool? You wouldn't believe how many times I've had to > > > convince people that the debug commands aren't a replacement for a > sniffer. > > > Not only are there issues with eating CPU resources to display the debug > > > info, but a lot of the commands don't show packets (which they > shouldn't). > > > Also, regardless of whether they show events or packets, they don't > display > > > the information in English (in many cases). In fact, many of the debug > > > commands were written to help Cisco software and hardware developers do > > > some debugging on flaky code/hardware. They weren't written to help a > > > network administrator or engineer. > > > > > > I know this is a tangent from the real discussion, but I just wanted to > > > make that additional point about a Cisco router not being the solution to > > > every problem. > > > > > > Priscilla > > > > > > ________________________ > > > > > > Priscilla Oppenheimer > > > http://www.priscilla.com > >-- > >David Madland > >Sr. Network Engineer > >CCIE# 2016 > >Qwest Communications Int. Inc. > >[EMAIL PROTECTED] > >612-664-3367 > > > >"Emotion should reflect reason not guide it" > ________________________ > > Priscilla Oppenheimer > http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45013&t=44876 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
