From: Yash Bajpai (ccieyash@yahoo.com)
Date: Fri Jul 29 2005 - 18:18:17 GMT-3
Hello Friends!
...and say HELLO to the newest CCIE on the
block...ME!!! heh heh heh....I passed CCIE R&S
yesterday in san jose. This was my 3rd attempt.
Before i begin with my viewpoints and suggestions, i
would like to take this time and thank all of you in
this groupstudy! YOu are a strong motivating force
that every CCIE candidate should use ("Use the force,
Luke"). I would especially like to thank NMC for their
excellent Checkit labs. I took 5 of them mostly back
to back in may-june2005 before my 2nd attempt. They
are much more challenging than the real thing and they
have an excellent feedback/verification system. Being
in 'customer support' myself, i would really like to
give my kudos to Indy and Bruce for their great
service and support. I also used Internetwork expert
labs and i really liked the lab content and material
they cover in their labs.
OK, now for my personal suggestions/comments about the
lab prep. For maximum benefits, I would break this
down into three cateogories
1) For the absolute newbies to Lab prep and this group
study.
* You would have heard this before, read about it,
discussed it with friends and colleagues and it doesnt
hurt to repeat: CCIE Lab is unlike any other exam! Its
a different beast that require a different strategy
than what we might be accustomed to for any 'paper
exam'.
* Having said that, its definitely an achievable goal
given that you are seriously focussed, determined and
commited towards the goal. (say goodbye to those
weekly parties)
* I started with Jeff Doyle vol1 vol2 which really
enforced my fundarmentals on core topics. After that,
Practical studies volumes were virtually a breeze. In
between all this, ofcourse there were generous CCO
readings for topics not covered in books (or atleast
in the books i had access to).
* Don't get disheartened by some of the posts in this
groupstudy. Take whatever positive you can out of it.
I remember when i first enrolled, i would not log in
to check my mails because i would be 'terrified' of
the level of questions some people would ask or when i
heard that someone failed inspite of their enormous
efforts! Just be optimistic and take only good points
from here!
* I started with the 'technology lab' in Jan-Feb2005.
These were focussed on a particular technology and
gave me the requisite comfort level on a particular
topic.
* Then i progressed to 8 hour labs. I would admit
having access to a CCIE rack was the greatest
'enabler' in my pursuit.
* Finally take the challenge labs from the top
vendor(s) of your choice.
2) For people ready to take their labs very soon
* At this point, you probably know so much already
that you are already a CCIE! really!!! Believe in that
and believe in yourself.
* I failed my 2nd attempt *not* because of lack of
preparation but due to my inferior "exam taking
skills" (i still get mad thinking about it). Granted
there were topics on which iam still amazed as to how
i got so few points in my 2nd failed attempt. But
overall, i realized i didn't do some basic
verification of my work and all the things that i
would do so diligently in my mock labs, i didnt do in
the REAL lab. Can you belive that...aaarghhh!!! Long
story short, don't take anything for granted when you
see the actual lab much more simpler than the mock
labs you have been practising! you can still pay a
heavy price for that...This is a very very easy exam
to FAIL :(
* Keep it simple. Know the basics. if there is
anything that i learnt from my 3 attempts then it was
this. At this stage in your prep, you may know the
intricacies of all the protocols out there, you may
know complex/obscure technology in great
detail and you may still find your concepts tested
only on the more basic aspects of routing and
switching! That is not to say that you don't need to
prepare as hard as you are right now. As a future
CCIE, you have a reputation to live up to and ofcourse
"anything is fair game in the lab".
3) For the "rest" out there midway in their lab prep.
You can do it! dont give up on it!!! I have some
points/tips in general that i made in the last month
of my prep. They are not in any particular order and
perhaps may not make complete sense too. Its more of a
scribble pad on points that i felt were easy to forget
and i have pretty much put them as-is with no special
interest in its order or lucidity. But iam sure they
would help you even without you knowing them...Here
are those 'precious' (please recheck its validity and
accurate-ness)
* eigrp would not advertise secondary addressess on an
interface unless split horizon is disabled
* you cannot change the AD of a specific external
EIGRP route.
* isis would not redistribute its 'connected'
interfaces running isis into other protocols. Perhaps,
the same is true for all IPv6 IGP routing protocols
too.
* For ISIS on ATM, remember to map clns protocol by
"protocol clns 00 broadcast"
* for ISIS on ISDN, remember that interesting traffic
is mapped by (hidden) clns_is protocol and not clns.
* some ways to stop distance vector IGP to *not*
advertise a route/interface:
> distribute list
> offset list
> distance
> make the interface metric infinity (delay,
bandwidth)
* For ATM to pass DHCP requests, do the following
under pvc x/y "protocol ip 255.255.255.255 broadcast"
(and enable "protocol ip inarp" for multipoint
interfaces).
* "ip msdp redistribute list" is nothing but
(logically) msdp sa-originate-filter
* "dlsw remote-peer 0 tcp x.x.x.x backup-peer y.y.y.y
linger 20" should be interpreted as x.x.x.x IS the
backup-peer OF y.y.y.y (implies y.y.y.y is already
configured separately as a primary remote peer)
* dlsw timer explorer-wait-time 100 should be used
when there is 'dlsw load-balance' involved to give the
peer enough time to listen to all explorer traffic.
* in dlsw remote-peer encapulations: TCP and dlsw-lite
(llc2) do reliable delivery and local acknowlwdgement.
llc2 shuould be mapped in FR multipoint. FST and
Direct are NOT reliable and have no local
acknowlwdgement. dlsw should be mapped in FR
multipoint.
* OSPF will generate host routes instead of
subnet/network route when the interface is configured
for point-to-multipoint network type.
* Under router rip, use "no validate-update source" to
disable source address validation
* user "no peer neighbor-route" under ISDN for
dis-allowing the host-route creation. (best practice)
* when using dialer watch on ISDN, set idle-timeout on
the *other* end as '0' so that ISDN does not flap.
* in ISIS route leaking, 'distribute-list' keyword is
required even if no existing ACL is referenced by it.
* dlsw transparent ethernet redundancy may also needs
a "dlsw transparent switch-support" command. (best
practice)
* If ISIS needs to redistribute static routes then
remember to use the 'IP' keyword and also prefer to
use the "metric-type external" option in the
redistribute static command.
* In IPv6 across FR, remember to map the link local
addresses ALSO.
* Shaping: Token bucket is filled with Bc *bits* at
the start of interval. Be is simply a 'larger space'
in the same token bucket.
* Policing: Tokens are prorated in the time interval
to match Bc and are measured in 'BYTES'. Be is another
token bucket which is filled either thru splill-over
i.e. single rate or filled at Peak rate (PIR) i.e.
dual rate Policing
* Use "log" as the first command as a best practice
when defining router isis.
* Rate-limiting or Policing: normal rate = CIR
Normal Burst Bc = CIR*1.5/8 (in bytes) and Be = 2 Bc
(where burst is allowed) or Bc = Be (no burst allowed)
* Leasked ISIS routes (from L2 into L1) cannot be then
redistributed out from a L1 router.
* CBWFQ percent (bandwidth percent) on FR is the
percent of BW of the MINCIR
* Be = (AR-CIR)*Tc/1000
* 4 lines of IOS commands for NTP authentication!
ntp authentication-key 1 md5 CISCO
ntp authenticate
ntp trusted-key
ntp server IP address key 1
* dont forget dot1x system-auth-control and keep a
"aaa authentication login default none" as a backup in
the lab.
* Dialer callback is based on PPP and requires some
form of PPP authentication to work (dialer
callback-server username)
* Multiple Dialer profiles using the same pool of BRi
interface need either PPP authentication (preferred)
or isdn caller screening to map the profile to the
incoming call.
* "ip ospf database-filter all out" interface command
would give "passive interface" like features on RIP.
It will form adjacencies but not send out LSA on that
interface.
* NSSA ABR does *not* automatically generate the
default route in the nssa area unless area nssa
default-originate is given.
* Adjusting OSPF hello interval automatically adjusts
its dead interval (to 4 time hello time) but *not*
vice verca.
* passive ftp acl e.g.
access-list 101 permit tcp any any eq ftp
access-list 101 permit tcp any any gt 1023 established
* rate-limit has a 'continue' option to keep the
packet in question go thru other rate-limi lists
configured on the interface.
* LLQ is not supported for FR interface.
Thank you!!!
Yash Bajpai
CCIE # 14964
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:32 GMT-3