From: Adam Quiggle (aquiggle@xxxxxxxxx)
Date: Sat Mar 30 2002 - 13:47:42 GMT-3
My initial read through the lab focused really on routing protocols,
physical link connectivity and how I needed to make the core work. Any
other subjects that sit on top of IP I just glanced at, since without the
core they don't work and they rarely affect the core anyway.
During my first attempt I did redraw the map, which in retrospect was
a complete waste of time. While I prefer my method for drawing maps
out, I did not think it was beneficial to spend that 15 minutes drawing
everything out.
Anytime I came across a new subject that required some kind of partial
mesh connectivity I drew a very quick map to outline how things should
come together. For example if I had DLSW border peers I would have drawn
out the two border peers and how the other routers connect to that border
peer. Or if I had BGP I would quickly draw any confederations,
route-reflectors
and ASes so that I could get an overall picture. However I spent maybe
45 seconds pulling those diagrams together and they were used to keep
me from accidentally misconfiguring connections.
Another problem that seemed to plague me was mistyping the ip addresses
in my rack. For whatever reason I must have mistyped some addresses at
least four or five times only to discover during my troubleshooting that
I had entered an IP like 151.1.1.1 instead of 151.9.1.1. Accuracy during
the configuration will save you a lot of time because you won't have to
troubleshoot your configurations.
Here are some other pointers:
1) Keep track of everything you've done as you go along
2) Make notes of what needs to be double checked
3) Put POINT VALUES by the tasks so that you can make sure the big ticket
items get addressed.
4) Watch the clock, don't let time slip away. If you spend more than five
minutes with something and you can't get it working, make a note and move
on. Sometimes just stepping away helps to take the blinders off.
5) Constantly use simple debug commands like "debug ip icmp and debug ip
packet xx detail" When doing redistribution, even if you haven't done your
mutual redistribution its nice to know that you have one-way redistribution
even if your pings fail.
That's all I can think of and probably my last post on the subject, since
I'm off for a week on vacation. :-)
Enjoy and good luck on your journey! :-)
AQ
CCIE #9049
At 10:50 AM 3/30/2002, ying chang wrote:
>Hi Adam,
>
>Congratulations! Did you copy the map and read through the whole thing
>before you start? I have about 2 months to go, and trying to build good
>habbit to do things, I found my time management is poor and trying to
>correct it before it's too late.
>
>Thanks,
>Chang
>
>
>>From: Adam Quiggle <aquiggle@nc.rr.com>
>>Reply-To: Adam Quiggle <aquiggle@nc.rr.com>
>>To: Brian McGahan <brian@cyscoexpert.com>, ccielab@groupstudy.com
>>Subject: Re: CCIE #9049
>>Date: Sat, 30 Mar 2002 10:20:10 -0500
>>
>>DOH! I guess I was so high on life that I couldn't see
>>straight. Good thing I wasn't driving a car when I found out. :-)
>>
>>AQ
>>
>>At 04:19 PM 3/29/2002, Brian McGahan wrote:
>>>Adam,
>>>
>>> Congratulations! We knew that you had it in you. BTW... your sig says
>>>CCIE #9409 :)
>>>
>>>Keep in touch,
>>>
>>>Brian McGahan
>>>CCIE #8593
>>>brian@cyscoexpert.com
>>>
>>>CyscoExpert Corporation
>>>Internetwork Consulting & Training
>>>http://www.cyscoexpert.com
>>>Voice: 847.674.3392
>>>Fax: 847.674.2625
>>>
>>>----- Original Message -----
>>>From: "Adam Quiggle" <aquiggle@nc.rr.com>
>>>To: <ccielab@groupstudy.com>
>>>Sent: Friday, March 29, 2002 2:18 PM
>>>Subject: CCIE #9049
>>>
>>>
>>> > Hi everyone,
>>> >
>>> > Well I got my email bright and early this morning (it was postmarked just
>>> > after midnight, but I didn't get it until 6:00am). As everyone has said,
>>> > the waiting is a killer. I had convinced myself that I had failed
>>> and was
>>> > prepared to reschedule the lab again, but when I opened my email and say
>>> > that "Congratulations on passing the CCIE Lab" I jumped out of my
>>> > seat! :-) Needless to say I've been on cloud 9 since early this
>>> morning.
>>> >
>>> > As to pointers for those pursuing the CCIE here are some of the things
>>>I've
>>> > done.
>>> >
>>> > 1) Read, read and read some more. There are a lot of different books out
>>> > there and I don't have any new books to add to the list, although there
>>>are
>>> > a few that I did appreciate more than others: Ciscopress Internetworking
>>> > with SNA (Sackett), Doyle vI and vII, Halabi (starts hard gets easier
>>> once
>>> > you get past the NAP concept) and Caslow.
>>> >
>>> > 2) Practice, practice and practice some more. I used the bootcamp labs
>>>for
>>> > a good understanding of what to expect. I did several of the FATKID labs
>>> > and even created some labs to explore the various technologies. The
>>> > bootcamp labs frequently took me much longer to do than I anticipated
>>> > because I frequently went off on tangents to explore "what if's".
>>> >
>>> > 3) http://www.cyscoexpert.com I went there before my lab when I
>>> thought I
>>> > was ready and had done most of the bootcamp labs with minimal
>>> > problems. However, they kicked my butt into gear and there is no doubt
>>> > that I would have failed if I hadn't taken this "class". It's really not
>>>a
>>> > class, as it is customized training. While many of the CCIE classes are
>>> > during the week and have a regimented approach, this one was
>>> customized to
>>> > your weaknesses. The first day they run you through a practice lab and
>>> > subsequently evaluate your performance and you go from there. There was
>>> > always one and almost always there were two and sometimes three CCIEs
>>> > during "class", which was from 9am to 10pm. In addition they were open
>>> > through weekends (9am to 10pm), so you can go during the weekend,
>>> which is
>>> > a definite bonus. They are really nice people there to boot!
>>> >
>>> > 4) Time management is critical. It's all true true true. Several
>>> times I
>>> > looked at a problem and couldn't figure it out quickly, so I made a note
>>> > and kept going. If I remembered how to do a little bit later I would go
>>> > back and add it, otherwise I waited until the end.
>>> >
>>> > At lunch time I was barely half way through the lab. I don't know how
>>> > other people get done by lunch, but my methodology was "how I can
>>>integrate
>>> > this concept/technology into the network without impacting the core".
>>>I
>>> > was always looking for problems as I went along, because nothing is worse
>>> > than trying to deal with multiple problems at the same time.
>>> >
>>> > All was well right up until five minutes before he called time and I
>>> found
>>> > that my routes were recalculating every 10 seconds..ugh...giant routing
>>> > loop...now I'm really hosed! How am I going to find a routing loop in
>>>less
>>> > than 5 minutes??? I'm not sure if I got lucky or if it was just
>>>experience
>>> > that led me to find what routes that were looping, but I managed to find
>>> > the problem and correct it just before he called time. Here is a tip,
>>> > start shutting down interfaces one at a time until the recalcs go
>>> away and
>>> > then focus on how that stopped them. Sometimes you have to shutdown
>>> > several interfaces (one at a time) to figure out the exit and entry
>>> > points. I walked away knowing I didn't get 9 points (didn't fulfill the
>>> > criteria) and thought I have 11 points to play with. Must have been my
>>> > lucky day. :-)
>>> >
>>> > 5) Keep track of your progess. I wrote down every question on a piece of
>>> > paper and the number of points, with a space for notes:
>>> >
>>> > Num Pts Notes
>>> > 2.1 2 Check for routes on R6
>>> > 2.2 4 Look at authentication
>>> >
>>> > This is important when it gets toward the end and you start to make sure
>>> > you've nailed the questionable stuff.
>>> >
>>> > 6) Don't overthink the problem. That is a direct quote from the proctors
>>> > who were great. They are there to help and they do their best to calm
>>>your
>>> > nerves before the lab and during lunch. However, make sure you ask the
>>> > right question, don't ask a "how" question, but if there is a requirement
>>> > to filter "LSA Type 5's" you might ask "Is it ok to filter Type-3 and
>>> > Type-4 LSA's".
>>> >
>>> > 7) Aliases. I'm a 60 words a minute typer and I found that I had about a
>>> > dozen commands that I aliased so that I can access things quickly and
>>>build
>>> > from that. For example:
>>> >
>>> > alias exec sio show ip ospf
>>> >
>>> > can be used as:
>>> > sio n - show ip ospf neighbor
>>> > sio v - show ip ospf virtual-link
>>> > sio i - show ip ospf interface
>>> >
>>> > In addition, for setting up the core I would recommend using the
>>> commands:
>>> >
>>> > so - show run | begin router ospf
>>> > se - show run | begin router eigrp
>>> > sb - show run | begin router bgp
>>> >
>>> > These work great on the 3640's, but tend to be slow on the 2500's.
>>>However
>>> > you don't have to go scrolling for what is missing.
>>> >
>>> > 8) Groupstudy! Almost every question you can think of has been asked and
>>> > answered on this list and can be found in the archives. I used the
>>> > archives extensively, which is probably why I didn't post that much.
>>>Huge
>>> > thanks to Paul Borghese!
>>> >
>>> > Well, that's all I can think of. Good luck to those pursuing your
>>> > CCIE. I'll be here in the flanks continuing to listen, learn and
>>>hopefully
>>> > extend a hand to others. :-)
>>> >
>>> > Later,
>>> > AQ
>>> >
>>> >
>>> > **********************************
>>> > Adam Quiggle
>>> > Sr. Network Eng II
>>> > Managed Network Services Worldcom
>>> > CCIE #9409, CCNP, MCNE, MCSE <----------- ;)
>>> > **********************************
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:26 GMT-3