Tony All good points in your post. As you wrote NOBODY knows anything and if you continue to believe that after geting your CCIE there is great future for you because you will never cease to learn and to develop both personally and profesionally. I am currently studying for CIT and IMHO it is really importand to understand OSI layers because you can learn to troubleshoot bottom up (from physical to data link to network and so on) and I believe that Cisco certs are much more vendor-neutral compared to other certs. If you dont just cram for tests and try to study in a broader perspective there is a lot to learn. A lot of people talk about paper certs but the least likely to be paper certs are CCIE and Red Hat because they have a lab section and that cannot be passed by cramming only without having hands-on experience (maybe lab not real world but this is certainly better than none at all). I am glad that at least something good came out of this long thread. I dont mean to insult anyone but please ignore stupid journalists that dont know what it takes to become a CCIE. Tony and other CCIE's in this list and the ones I had the priviledge to work with demonstrate that being an expert while remaining humble is the true sign of a wise person. George Yiannibas MCSE CCNA ""Tony Medeiros"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I have to agree with many, if not all the points raised by everybody. > My humble take is that there are 4 types of knowledge a great, capable of > hands on, design, etc. network engineer should have in the perfect world. > CCIE or not. Bear in mind that I am talking about a network engineer that > basically works with the equipment and maintains and designs networks. > Other types of network engineers that design hardware, software, and > protocols will come under a way different set of rules I would think. > > 1. Basic network and protocol knowledge: > This should be how all layer 2, 3, 4 and many layer 7 protocols work > including the management plane protocols, routing protocols, STP, etc. Not > necessarily what all the frame/packet/segment structures look like and where > and what each field in the PDU is and does. But enough PDU structure to know > what the engineer is looking at and understand how they work. Although this > is all excellent knowledge to have, I think it's improbable (at least for > me) to know all the PDU structures in detail. The main thing is to know the > behaviors (especially TCP) and how things can go right or wrong. Some layer > 1 stuff is good to know too!! Like what does it mean when I have slips on my > T1 interface or how a DS-3 works. Other things are cabling issues, what box > does what, where do I use a certain box (bridge vs.router, etc.), design > best practices, security issues and techniques. Also host behavior and > configuration knowledge is invaluable. I'm sure I left out a bunch of > stuff, but that is what I see as important(in my limited experience) to know > > Most, if not all of number 1 can be learned by reading books, RFC's white > papers, etc. Hands on experience will certainly help. > > 2. Platform specific configuration: > It's great to know all the above stuff, but If I can't make it happen on > whatever I am configuring be it Cisco, Foundry, Extreme, or whatever. I am > of little use as a hands on engineer. It's nice to know how EIGRP installs > a feasible successor, But if I can't get my routes to propagate correctly > because I left out "no auto summary", that knowledge doesn't serve me like > it should. OT. Why Cisco doesn't remove ALL classfull behavior from that > damn protocol is beyond me!! Again, I believe it's improbable to know how > to configure everything on even one vender or platform. But, the engineer > should know when to punt and ask for help. Or know how to access and find > the information he/she requires. And I don't just mean calling TAC :) Even > though the wonderful people at TAC have gotten my ass out of a ringer many > times. > > The Items in Number 2 comes from some book knowledge. But hands on > experience is key. The experience of producing a complex config and > fighting to make it work is the best teacher I know of. Be it in a lab or > live network. I never forgot the first time I got a DS-3 of ATM with about > 15 pvcs to work. Or even the first time I brought up a simple frame link > and pinged across and watched my routing table to grow !!! It was almost > better than sex !!(don't tell my wife please !!) I know, I'm sick. :>/ > > 3. Experience, PERIOD !! > Many a time it has been when I fought to get something to work and couldn't. > I checked the config against CCO, changed IOS's, changed modules, changed > my underwear, etc. Ending calling up a more knowledgeable peer to have her > tell me: "Oh, it's BLA, BA BLA". Type in the undocumented "BLA BA BLA and > it will work." That is why having peers and is essential to survival in > this business. Everybody of Group study is my peer whom I glean information > and support. I am a firm believer in "no man/women is an island' !! And > NOBODY knows everything. > > 4. The ability, motivation, and tenacity to solve problems, learn, and do a > good job. (self explanatory) > > I believe no attribute in itself is the most important, we need all of > them. > Sorry everybody for the long post. I'll refrain from posting for a while. > Tony M. > #6172 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=19105&t=19105 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
