Re: Provider Backbone Engineering and CCIEs [7:44876]
At 3:33 PM -0400 5/23/02, Ron Trunk wrote: >Howard and dre, >First of all, thanks for the excellent thread! First, thanks for letting me know you are still around! >You've given me a great deal >of information about service provider issues. I was dimly aware of some of >them, but now I see how they really affect ISP operations. I've printed out >the whole thread and when I can get some quiet time away from the wife and >kids (ha!), I'm going to go over it in detail. Thanks for all the links >too! It's helpful to know what the best things to read are. > >At the risk of extended an already belabored subject, I did want to comment >on the whole CCIE issue. I'm not sure it's fair to blame Cisco for not >making the lab exam deal with real-life issues, especially those for service >providers. If I've given that impression, it was in error. One of my concerns, however, was that some people get the incorrect impression that a CCIE shows qualification for every conceivable networking job. Your analogy to medicine is not bad; it basically says you are ready for the specialty training. More on that later. >Cisco's goal, after all, is not to make great network engineers, >but to make engineers who are proficient with all of Cisco's features and >functions. I do have a problem with the emphasis on "all." There are any number of features that shouldn't be touched unless one has a thorough understanding of the proper environment to use them. I rather regret that X.25 has come off the lab, because it's still an amazing protocol for certain very specialized applications. A lot of the IBM stuff makes very little sense unless you have had substantial experience with mainframes/front ends, and then some of the Cisco features become quite clever. It's probably not unreasonable to know how to configure a basic route reflector, but even though I might JUST be able to set it up with 6 routers, hierarchical route reflectors (and there are a couple of commands, but more design issues) are really too specialized. I'm the first person to admit I know very little about Microsoft networking, especially when one gets into domains and the like. But I can be very busy with real networks and not need that knowledge. In other words, I'd rather see the CCIE a little more specialized (i.e., even more variants), and perhaps a little more in-depth in those areas. There's still a certain mystique that it qualifies someone to work in every area of networking at a senior level, and that's just not the case. >That is why some of the lab scenarios are a bit contrived, and >also why you should be fired for trying to use some of those features on a >real network. Cisco's aim is to make sure CCIEs know how to configure a >Cisco router to solve any problem, even those that shouldn't be solved with >a router! Again, my concern is with "any." I understand why _Cisco_ is well served by some version of that. How does a hiring manager, however, find the people that know when there are better tools than a router for some problems? > >You guys have obviously great expertise in a relatively specialized field. >Should everyone have to understand all these issues before they can rightly >call themselves a network engineer? How many SP jobs are there at that >level, especially in today's market? Good question, really, and hard to answer in the current economy. Last year, I was on an Internet Society panel on the future and scalability of Internet routing. One of my co-panelists was Sue Hares, who is vice-chair of the IDR (BGP) working group and founder/CTO of NextHop. One of her slides read something like "CLI jocks don't scale." In other words, in the minds of everyone on the panel, if the growth rate continues, we MUST develop better automated tools because there simply won't be enough qualified global routing engineers. Once the current economy shakes out, I think you'll find more demand than supply of such specialists, just as you will for VoIP/AVVID, etc. >I would love to be able to specialize >like you have, but the realities of my job require me to be conversant in >everything Cisco sells. To use Howard's medical analogy, while I want to >master neurosurgery, I work in the ER and have to deal with everything from >heart attacks to broken bones to earwax. Please, Ron. You're a nice guy. Do you know any neurosurgeons? Their personalities tend to be like Catbert's. > >To push the medical analogy just a bit farther, I think having the CCIE is >like graduating from medical school. You have mastered a body of knowledge >and have earned the right to put letters after your name, but no one is >going to give you a scalpel until you have completed a lengthy internship. >That's where the experience comes in. It's important to know where to cut. >It is even more important to know when not to cut. As I say, a good example. It's amazing how many levels of "certification" exist in medicine -- the
Re: Provider Backbone Engineering and CCIEs [7:44876]
""Ron Trunk"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Howard and dre, > First of all, thanks for the excellent thread! You've given me a great deal > kids (ha!), I'm going to go over it in detail. Thanks for all the links > too! It's helpful to know what the best things to read are. Very cool. I know exactly how you feel, so any feedback would be highly appreciated. > At the risk of extended an already belabored subject, I did want to comment > Cisco router to solve any problem, even those that shouldn't be solved with > a router! Exactly the reason why the CCIE: Design didn't pan out, and why the CND/CID course material is a wee bit out-of-date. Real world experience is impossible to test on any type of standardized exam. There is no "shortcut" class or paper written to teach you what you need to know for the real-world. > You guys have obviously great expertise in a relatively specialized field. The "Internet" is considered a specialized field in networking? I never thought of it that way before. Please explain what you mean. I think that a CCIE: R&S is more specialized. No knowledge of SONET, per se (never touched an ADM or DCS). No real knowledge of ATM (never been inside an ATM switch). No real knowledge of anything except R&S. That's specialized! > Should everyone have to understand all these issues before they can rightly > call themselves a network engineer? Well plenty of NT administrators call themselves network engineers or network administrators. I think you can call yourself anything you want. It's not like you are claiming to be "Dr. Ron" with no Ph.D. However, if I were a hiring manager and needed this level of expertise for a TBD requisition for employment at my business, you can bet I'm not going to "just hire up a CCIE". Something to think about for a lot of people on this list who think CCIE is the Holy Grail. CCIE is *not* the Holy Grail. It's just one path to get to it. One path out of maybe thousands. But a highly respected one by some people, much like a paladin journeying against a band of ogres (the Shrek kind, not the mean kind). > How many SP jobs are there at that > level, especially in today's market? You'll find somewhere in our posts that there is so much need for these types of people, it is like an unstoppable force (in my mind). How else are we supposed to build this thing (and even keep it from crashing constantly) that allows us to have these discussions right now? How many job postings are there on hotjobs or dice right now? Who cares about that?! Move to a third-world country and connect them to the Internet! There's a job for you! > I would love to be able to specialize > like you have, but the realities of my job require me to be conversant in > everything Cisco sells. To use Howard's medical analogy, while I want to > master neurosurgery, I work in the ER and have to deal with everything from > heart attacks to broken bones to earwax. You can "specialize" like we have! Are you assuming that my job doesn't require me to be conversant in everything Cisco sells? And I seriously doubt you are as equally conversant in everything Cisco sells as some people out there. Cisco sells a lot of software in addition to their large set of hardware gear that ranges from R&S gear to IP Phones to ATM switches to DSLAM's to CDN products. And Cisco is not the only network equipment vendor. And they aren't the only software vendor specializing in networked applications. I work in the ER and do neurosurgery all the in same hour sometimes, to use your frame of reference. Networking is a *dynamic* field, filled with almost supernatural levels of constantly changing equations. It's best to be able to wear about a dozen different hats everyday. You have to pretend you're an end-user, a sys admin, a programmer, a content provider, a telco switch tech, a routing person, a switching person, a project manager, and a regular human in the same 5 minutes sometimes. That's what's so great about it, IMO. > To push the medical analogy just a bit farther, I think having the CCIE is > like graduating from medical school. You have mastered a body of knowledge > and have earned the right to put letters after your name, but no one is > going to give you a scalpel until you have completed a lengthy internship. > That's where the experience comes in. It's important to know where to cut. > It is even more important to know when not to cut. I'm not a medical student, so I can't say. I'm not going to bother to try to do analogies. There's a really long and detailed thread on NANOG-L right now discussing this exact same topic. It's seems like they really aren't getting anywhere with it. I think the exciting thing about the networking field is that it can't be described. It's so new, it's so exciting, and it's so constantly evolving and changing. Just so people don't get the wrong idea about me and where I come from, I want you guy
Re: Provider Backbone Engineering and CCIEs [7:44876]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44973&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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! > snip for brevity > > 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. most of us here are really just a bunch of router jocks. what do you think we would use? ;-> when your only tool is a hammer, all your problems look like nails!!! :-> Chuck > > Priscilla > > > > > > Priscilla Oppenheimer > http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44976&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Provider Backbone Engineering and CCIEs [7:44876]
Really? So I shouldn't being doing a "show mem" and looking at the data contained in specific memory addresses labeled *packet data* to turn my router into a sniffer? :-) -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 1:20 PM To: [EMAIL PROTECTED] Subject: Re: Provider Backbone Engineering and CCIEs [7:44876] 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44978&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
Why can't I sniff my telnet login/password in clear text but can sniff my pop3 login/password in clear text? I'm using Sniffer Pro 4.5. Thanks, -H - Original Message - From: "Priscilla Oppenheimer" To: Sent: Friday, May 24, 2002 1:20 PM Subject: Re: Provider Backbone Engineering and CCIEs [7:44876] > 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44980&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
At 1:25 PM -0400 5/24/02, Chuck wrote: >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> 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! >> >snip for brevity >> >> 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. This goes beyond tangent. It is a sin. > > >most of us here are really just a bunch of router jocks. what do you think >we would use? ;-> >when your only tool is a hammer, all your problems look like nails!!! :-> > >Chuck Only tool? Match up column A and column B (I'm only citing things that actually are in my own shop), and cite the equivalent routers. tack hammer6" spike 8 oz two-faced mallet 4d finishing 16 oz two-faced mallet 16d galvanized common 10 lb sledge 18gauge brad 16 oz black rubber mallet 8d bright common 16 oz ball-pein3" masonry drywall hammer drywall nail 8 oz ball pein 2" masonry 2 lb sledge16d bright common 24 oz wood handled carpenter 8d finishing 32 oz all metal carpenter 6d finishing Meat tenderizer3/4" aluminum roofing 8 oz wood handled carpenterwire staple for Romex dead blow hammer carpet tacks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44981&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 1:25 PM -0400 5/24/02, Chuck wrote: > >""Priscilla Oppenheimer"" wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> 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! > >> > >snip for brevity > >> > >> 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. > > This goes beyond tangent. It is a sin. > > > > > > >most of us here are really just a bunch of router jocks. what do you think > >we would use? ;-> > >when your only tool is a hammer, all your problems look like nails!!! :-> > > > >Chuck > > Only tool? Match up column A and column B (I'm only citing things > that actually are in my own shop), and cite the equivalent routers. > > tack hammer6" spike > 8 oz two-faced mallet 4d finishing > 16 oz two-faced mallet 16d galvanized common > 10 lb sledge 18gauge brad > 16 oz black rubber mallet 8d bright common > 16 oz ball-pein3" masonry > drywall hammer drywall nail > 8 oz ball pein 2" masonry > 2 lb sledge16d bright common > 24 oz wood handled carpenter 8d finishing > 32 oz all metal carpenter 6d finishing > Meat tenderizer3/4" aluminum roofing > 8 oz wood handled carpenterwire staple for Romex > dead blow hammer carpet tacks cisco makes routers of any number of sizes, for all occasions. an 827, for example, might take the place of a tack hammer, while a 3660 or a 7206 might make a good replacement for a 10 lb sledge. in fact, after a frustrating all nighter, trying to fix some problem or another, I have often been tempted to use my routers in such a fashion ;-> Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44982&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
Because pop3 username and password use two packets (one for "USER username" and another for "PASS password" command). With telnet, every keystroke is transmitted in separate packet. It is possible to collect them all and reconstruct username/password, but it's not trivial as with pop3. Sasa CCIE 8635 Henrique Duarte wrote: > > Why can't I sniff my telnet login/password in clear text but can sniff my > pop3 login/password in clear text? I'm using Sniffer Pro 4.5. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44983&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
At 02:42 PM 5/24/02, Howard C. Berkowitz wrote: >Only tool? Match up column A and column B (I'm only citing things >that actually are in my own shop), and cite the equivalent routers. > > tack hammer6" spike > 8 oz two-faced mallet 4d finishing > 16 oz two-faced mallet 16d galvanized common > 10 lb sledge 18gauge brad > 16 oz black rubber mallet 8d bright common > 16 oz ball-pein3" masonry > drywall hammer drywall nail > 8 oz ball pein 2" masonry > 2 lb sledge16d bright common > 24 oz wood handled carpenter 8d finishing > 32 oz all metal carpenter 6d finishing > Meat tenderizer3/4" aluminum roofing > 8 oz wood handled carpenterwire staple for Romex > dead blow hammer carpet tacks Oh, I thought that was router debug output! ;-) It could have said: 4d3h: %LINK-3-UPDOWN: Interface Serial0/1, changed state to 6d finishing 4d3h: carpet tACKs 4d3h: Se0/1 CHAP: O CHALLENGE id 32 oz len 3/4" from Romex 4d3h: %LINK-3-UPDOWN: Interface Serial0/1, changed state to 4d finishing 4d3h: two-faced mallet communications established 4d3h: %LINK-3-UPDOWN: Interface Serial0/1, wood handled carpenter failed 4d3h: tACK hammer 4d3h Se0/1 CHAP: Using alternate hostname black rubber mallet 4d3h: %LINK-3-UPDOWN: Interface Serial0/1, changed state to 6d dead blow hammer 4d3h: failed wire staple for Romex 4d3h: 8d bright common channel 16d galvanized 4d3h: drywall circuit nailed 4d3h: drywall hit firewall 4d3h: 10 lb sledge hit firewall 4d3h: go back to using a ball-pein for communications 4d3h: go back to work now! Priscilla Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44985&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
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" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44984&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=44988&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
Priscilla Oppenheimer wrote: > > 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 Actually I used debug eigrp packet found a couple of neighbors were bouncing eratically which I had also noticed in the ip routing table. I tried pinging these neighbors and was loosing many packets, this is over a 100M ethernet. Since this customer mentioned that they had done some work on a Microsoft server including adding a second interface (arghhh) I had a good suspect. Since I have seen in the past multiinterfaced servers do wierd things like foward multicast packets I suspected a possible routing loop. I enabled debug ip icmp and basically crashed the MSFC. It was so busy spewing out ICMP TTL expired messages that caused the CPU to hit 99% and the router was not able to maintain it's routing functions etc... I asked the customer to grab the server guy and have him shut down the second interface, problem solved. The IP ICMP debug was really the helper here but the point is I was able to find the problem using debug, I'm 300 miles from this customer, much more quickly than finding someone locally who could drive a sniffer and read/email the output. I admit crashing the router was not good but "normally" a ip icmp debug will not do that hence I say use any debug with some caution and customer warning, this may be hazardous to your network!! Dave David Madland Sr. Network Engineer CCIE# 2016 Qwest Communications Int. Inc. [EMAIL PROTECTED] 612-664-3367 "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44991&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
""MADMAN"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Priscilla Oppenheimer wrote: > > > > 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 > > Actually I used debug eigrp packet found a couple of neighbors were > bouncing eratically which I had also noticed in the ip routing table. I > tried pinging these neighbors and was loosing many packets, this is over > a 100M ethernet. Since this customer mentioned that they had done some > work on a Microsoft server including adding a second interface (arghhh) > I had a good suspect. Since I have seen in the past multiinterfaced > servers do wierd things like foward multicast packets I suspected a > possible routing loop. I enabled debug ip icmp and basically crashed > the MSFC. It was so busy spewing out ICMP TTL expired messages that > caused the CPU to hit 99% and the router was not able to maintain it's > routing functions etc... I asked the customer to grab the server guy > and have him shut down the second interface, problem solved. CL: you sure you didn't say something more like "grab the server guy and throttle him a good one!" ??? > > The IP ICMP debug was really the helper here but the point is I was > able to find the problem using debug, I'm 300 miles from this customer, > much more quickly than finding someone locally who could drive a sniffer > and read/email the output. I admit crashing the router was not good but > "normally" a ip icmp debug will not do that hence I say use any debug > with some caution and customer warning, this may be hazardous to your > network!! > > Dave > > David Madland > Sr. Network Engineer > CCIE# 2016 > Qwest Communications Int. Inc. > [EMAIL PROTECTED] > 612-664-3367 > > "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44993&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
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]
Re: Provider Backbone Engineering and CCIEs [7:44876]
It figures, Howard, that you would have a plethora of sizes and types of hammers in your garage. I have only one, and believe me, just about every household repair problem indeed looks exactly like a nail. Even the one involving the pulling up of carpet to repair the rotted flooring underneath. It is absolutely correct that the skilled professional SHOULD have a variety of tools on his/her belt, and SHOULD know how to use those tools, and in what circumstances. A number of the real world problems we discuss on this list tend to result from the limits of people's expertise. Some folks just "try things" until they solve a particular problem. After several months of this they have One Giant Mess, they don't know what to do. One can hope that the folks on this list are making a best effort to acquire a variety of tools, and the knowledge necessary to use them appropriately. Chuck ""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 1:25 PM -0400 5/24/02, Chuck wrote: > >""Priscilla Oppenheimer"" wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> 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! > >> > >snip for brevity > >> > >> 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. > > This goes beyond tangent. It is a sin. > > > > > > >most of us here are really just a bunch of router jocks. what do you think > >we would use? ;-> > >when your only tool is a hammer, all your problems look like nails!!! :-> > > > >Chuck > > Only tool? Match up column A and column B (I'm only citing things > that actually are in my own shop), and cite the equivalent routers. > > tack hammer6" spike > 8 oz two-faced mallet 4d finishing > 16 oz two-faced mallet 16d galvanized common > 10 lb sledge 18gauge brad > 16 oz black rubber mallet 8d bright common > 16 oz ball-pein3" masonry > drywall hammer drywall nail > 8 oz ball pein 2" masonry > 2 lb sledge16d bright common > 24 oz wood handled carpenter 8d finishing > 32 oz all metal carpenter 6d finishing > Meat tenderizer3/4" aluminum roofing > 8 oz wood handled carpenterwire staple for Romex > dead blow hammer carpet tacks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45041&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
The challenges involved in maintaining & expanding a toolkit probably differ when you contrast hardware-based tools with software-based ones, as well as the sets of tools used for design/implementation vs. those used for troubleshooting purposes (although there's certainly some opportunity for overlap between those two). To expand your set of troubleshooting skills, simply perform successful analysis of the next connectivity, performance issue you are charged with without telnetting/consoling to the router. There's a lot of underexploited features of commonly-deployed software lying in wait. Now, when you are trying to solve a problem that requires you to identify the right combination of software/hardware to serve as an intermediate system, expanding your "toolkit" might not be an option due to the tendency the manufacturers' have to charge for their products. Maybe an altheon or a checkpoint might be a better solution for the problem at hand rather than the corresponding set of router commands that allegedly provide comparable functionality, but you aren't a billionaire or refuse to buy into sadistically complex licensing schemes. As usual, real-world outcomes tend to not always reflect the optimal leveraging of technology. I'd certainly agree that people don't make enough use of the tools they DO have, both hardware & software, for both design & troubleshooting purposes, due mainly to a lack of familiarity with non-standard ways using technology, which may or may not be linked to a lack of willingness to explore these options. As far as hammers go, If you order the list from those implements which can bring the least amount of classical/newtonian force to bear to those implements which can bring the most amount of force to bear, i'm pretty sure that you start matching them with cisco routers, and you almost certainly end up with a different vendor's products when you get to the more powerful hammers. I'd appreciate any insight on completing the following: "If the only tool at your disposal is disconnecting and reconnecting power cables, then every problem looks like a " - Original Message - From: "Chuck" To: Sent: 25 May 2002 3:48 pm Subject: Re: Provider Backbone Engineering and CCIEs [7:44876] > It figures, Howard, that you would have a plethora of sizes and types of > hammers in your garage. I have only one, and believe me, just about every > household repair problem indeed looks exactly like a nail. Even the one > involving the pulling up of carpet to repair the rotted flooring underneath. > > It is absolutely correct that the skilled professional SHOULD have a variety > of tools on his/her belt, and SHOULD know how to use those tools, and in > what circumstances. A number of the real world problems we discuss on this > list tend to result from the limits of people's expertise. Some folks just > "try things" until they solve a particular problem. After several months of > this they have One Giant Mess, they don't know what to do. > > One can hope that the folks on this list are making a best effort to acquire > a variety of tools, and the knowledge necessary to use them appropriately. > > Chuck > > > > ""Howard C. Berkowitz"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > At 1:25 PM -0400 5/24/02, Chuck wrote: > > >""Priscilla Oppenheimer"" wrote in message > > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > >> 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! > > >> > > >snip for brevity > > >> > > >> 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. > > > > This goes beyond tangent. It is a sin. > > > > > > > > > > >most of us here are really just a bunch of router jocks. what do you > think > > >we would use? ;-> > > >when your only tool is a hammer, all your problems look like nails!!! :-> > > > > > >Chuck > > > > Only tool? Match up column A and column B (I'm only citing things > > that actually are in my own shop), and cite the equivalent routers. > > > > tack hammer6" spike > > 8 oz two-faced mallet 4d finishing > > 16 oz two-faced mallet 16d galvanized common > > 10 lb sledge 18gauge brad
Re: Provider Backbone Engineering and CCIEs [7:44876]
Howard, When is your book "Building SP Networks" going to be coming out? I think that this book can really help me out. I have noticed in my quest to build the best SP that I can, that there's not really any one resource to address all of the issues. Being new to the SP space, I am looking for direction on the specific issues that affect Service Providers. Travis Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45140&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
>Howard, > >When is your book "Building SP Networks" going to be coming out? I think >that this book can really help me out. I have noticed in my quest to build >the best SP that I can, that there's not really any one resource to address >all of the issues. Being new to the SP space, I am looking for direction on >the specific issues that affect Service Providers. > >Travis > To be honest, I wish _I_ knew. I was supposed to have received my author copies, and was told they are on a shipping cart at Wiley. Amazon lists June 10. All I can say is Real Soon Now -- I'm confused myself! I do know it's back from the printer. Howard Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45145&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
""dre"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... ... > Exactly the reason why the CCIE: Design didn't pan out, and why the > CND/CID course material is a wee bit out-of-date. Real world experience > is impossible to test on any type of standardized exam. There is no > "shortcut" > class or paper written to teach you what you need to know for the > real-world. > No question, and if my post implied otherwise, let me correct that impression now. FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Provider Backbone Engineering and CCIEs [7:44876]
""Howard C. Berkowitz"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 3:33 PM -0400 5/23/02, Ron Trunk wrote: > >Howard and dre, > >First of all, thanks for the excellent thread! > > First, thanks for letting me know you are still around! > I've started teaching 'unofficial' Cisco courses, so I thought I'd start keeping an eye on questions on this list. > >Cisco's goal, after all, is not to make great network engineers, > >but to make engineers who are proficient with all of Cisco's features and > >functions. > > I do have a problem with the emphasis on "all." There are any number > of features that shouldn't be touched unless one has a thorough > understanding of the proper environment to use them. OK. Change the "all" to "most of the important" and we're in agreement. > >That is why some of the lab scenarios are a bit contrived, and > >also why you should be fired for trying to use some of those features on a > >real network. Cisco's aim is to make sure CCIEs know how to configure a > >Cisco router to solve any problem, even those that shouldn't be solved with > >a router! > > Again, my concern is with "any." I understand why _Cisco_ is well > served by some version of that. How does a hiring manager, however, > find the people that know when there are better tools than a router > for some problems? > Often the problem is that hiring managers don't even know the first thing about networking. I can't tell you how many clients I have where a junior or mid-level engineer is the only networking engineer in the place. How does his manager asses his or her talents when he only knows that someone "has to keep the routers going"? For better or worse, the manager often relies on certifications. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45157&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Provider Backbone Engineering and CCIEs [7:44876]
One of the nice features of Ethereal is that you can do "TCP Stream Analysis." Basically, this shows the ASCII stream of data going back-and-forth between the client and server. When analyzing telnet sessions it is pretty easy to see the clear-text passwords this way. HTH Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sasa Milic Sent: Friday, May 24, 2002 2:32 PM To: [EMAIL PROTECTED] Subject: Re: Provider Backbone Engineering and CCIEs [7:44876] Because pop3 username and password use two packets (one for "USER username" and another for "PASS password" command). With telnet, every keystroke is transmitted in separate packet. It is possible to collect them all and reconstruct username/password, but it's not trivial as with pop3. Sasa CCIE 8635 Henrique Duarte wrote: > > Why can't I sniff my telnet login/password in clear text but can sniff my > pop3 login/password in clear text? I'm using Sniffer Pro 4.5. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45226&t=44876 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
