CCIE #23707

Obviously I cannot go into many details here, but I do want to share my story in hopes that others will benefit in some way. It is long, but will probably be my last for awhile :-)

First of all, CCIE has to be something you really want. There are many reasons to go for it: better job, more money, etc. That is fine, but underneath it all, you must have the desire to be a CCIE. I made many career choices and mistakes before getting somewhat settled in this industry, so don't ever think this task is too big for you. The industry needs people that have the desire.

I first heard of the CCIE exam about 6 years ago when I started out towards a networking degree. It was never in my mind that I would go for it. It was only for the Elite. My degree consisted of a couple Cisco classes, and that was enough for me at the time. Shortly after the degree, I was doing technical support for Nortel Networks and really starting to dig the L2 and L3 technologies. I mean I LOVED IT! THIS WAS MY BAG! Nortel did not have much rep (or a declining one at least) in the industry and I decided to focus on Cisco networking. I got my CCNA near the end of my tenure there.

The desire to be CCIE started after I was CCNA, when I started going for CCNP. I peaked ahead at the CCIE blueprint and thought to myself, "this is stuff that I can handle, and stuff that I want to learn." I knew CCNP was not required, but I took that path because I knew it would be good preperation towards that goal. It took me one year to get my CCNP and the day I passed my last exam I was already making notes on the blueprint and scouring the Internet for lab tips :-)

I started my blog a few months later because I really had no focus as to what I was doing. I didn't have any workbooks or anything, I just had the written guide, dynamips and my 3550/3560 switches. I played around with my own labs and blogged ideas. Mike Down at IPexpert found my blog and gave me good deal for some rack time and for the Blended Learning Solution. This was the turning moment as now I felt I had a real path to follow. I passed the written shortly after (about 6 months in) and then joined groupstudy and the onlinestudylist.

Around this time, so many people were passing, I felt like time was slipping away! I decided the best thing to do was ignore all the stories and rumors and focus on my own path.

I did all the volume 1, 2 and 3 labs in order. Took me about 6 months doing a couple every weekend, sometimes 3 or 4. Actually I jumped ahead to Volume 3 at times because they were graded and I wanted to see how I was doing along the way. Any issues or new technologies I ran into, I would break down to small scenarios and lab them and blog about them.

On my way to work I would listen to the audio bootcamp. I probably listened to each track twice. After Volume 3 I bought an IE mock lab and did both Assessor labs. If not anything else, these gave me confidence in my last month of preperation. I did well on all of them and the things I missed were mainly because I did not follow the questions properly. I spent my final week watching the VODs with Scott Morris. I watched ALL the videos in the final weekend, probably about 25 hours or more :-)

The day of a lab I had huge headache. I popped some excedrin and some tylenol and refused any caffeine for fear of worsening it. I got to the lab a little early and there ended up being about 10 people there, 4 for R&S. My mind was a wreck, I felt like crap. The one thing that kept me going was my belief in my preperation. I knew what I had to do. If it's one thing you will learn about taking the CCIE lab exam, it is to trust your preperation.

The procotor explained the deal with the open ended questions (to curb cheating) and to be honest, they were very simple. No tricks. He said one or two lines should be enough but you have 30 minutes and no documentation. I finished them in a few minutes with the only bottleneck being my slow typing skills.

I started reading the lab. It was almost 1 hour before I logged into a router. I kept a level head throughout. I heard stories of people saying they were so confident when they left, but the still failed. I understood them now but I did not want to be that way. I could see how this lab could defeat me. After 5 hours I was done, but I stayed until the end verifying everything 1, 2 or 3 times. Pinging everything, saving all the time.

One hour I left, I finally broke for a Mountain Dew! Boy did I need that. I was finding minor issues still 30 minutes left in the exam, I fixed a few but I really had to talk myself into relying on my configurations and instincts. I could see several ways of doing things and I had to pick one. I really think I saved at least 10 points in the last couple hours of verification. Do not leave early!

I watched a movie after the lab with my Dad who was in town that weekend. I got home at 10 or so and checked my email. The score report was ready. I was SHAKING. I had to re-type my ID and crap a few times to get it right. First thing I saw was "submit critique" or something like that. Then I saw "Congratulations..." or something. I didn't believe it. Then I saw "PASS"...I still didn't believe it. Then I saw #23707. It was official.

What a relief. It was wonderful journey and I learned so much. I met a lot of great people that I never expected to meet. I look through my blog archives and see how dumb I was! Just another noob, a little wannabe Cisco networker, a tiny little soul on the path to who knows where, a CCIE to be :-)

TO BE

On my way back home from San Jose. I want to thank those that follow this blog and especially IPexpert for all the help. Will right more soon :)

-CCIE# 23707

PIM NBMA, DR and RPF issues

Below is the topology. RIP is running everywhere, PIM-SM on all interfaces and everyone has R4 at 192.168.100.4 as the static RP.


R1 has the following config on its LAN interface:

interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 239.0.0.1

Let's ping from R6:

R6#ping 239.0.0.1 re 5  

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
.....
R6#

Hmmm....what gives? Let's look at R4:

R4#sho ip pim neighbor
PIM Neighbor Table
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
192.168.34.3      Ethernet0/0              03:29:50/00:01:39 v2    1 / S
192.168.100.2     Serial0/0                02:25:22/00:01:38 v2    1 / S
192.168.100.5     Serial0/0                02:25:22/00:01:39 v2    1 / DR S
192.168.100.1     Serial0/0                02:25:22/00:01:38 v2    1 / S

R4#sho ip mroute 239.0.0.1 | be \(
(*, 239.0.0.1), 00:24:31/00:02:33, RP 192.168.100.4, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0, 192.168.100.2, Forward/Sparse, 00:24:31/00:02:33

(192.168.56.6, 239.0.0.1), 00:02:03/00:02:45, flags: T
  Incoming interface: Serial0/0, RPF nbr 192.168.100.5
  Outgoing interface list:
    Serial0/0, 192.168.100.2, Forward/Sparse, 00:02:03/00:00:57

R4#

Well, it looks R2 is showing up in the OIL, but why isn't R1? It is a PIM neighbor afterall. The reason is because R2 has won the DR election and has the right to forward traffic. So it is the neighbor that sends PIM joins to R4. R1 receives the traffic, but it comes in on its LAN interface and thus fails the RPF check.

R1#debug ip mpacket
IP multicast packets debugging is on
03:40:21: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=197, ttl=251, prot=1, len=114(100), not RPF interface
03:40:23: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=198, ttl=251, prot=1, len=114(100), not RPF interface

It is important to remember we have at least two ways to resolve this:

1) Make R1 the DR

R1(config)#int e0/0
R1(config-if)#ip pim dr-priority 3000

R6#ping 239.0.0.1 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.100.1, 60 ms
R6#

R1(config-if)#^Z
03:41:47: IP(0): s=192.168.56.6 (Serial0/0) d=239.0.0.1 (Ethernet0/0) id=207, ttl=252, prot=1, len=100(100), mforward

2) Static mroute to R2 for 192.168.56.6

R1(config)#int e0/0
R1(config-if)#no ip pim dr-priority 3000
R1(config-if)#exit
R1(config)#ip mroute 192.168.56.0 255.255.255.0 192.168.0.2

Make sure to clear mroutes otherwise previous state may mislead you :)

R4#clear ip mroute *

R6#ping 239.0.0.1 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.100.1, 56 ms
R6#

This is one of those labs where I had no idea where I was going and I ended up with a nice troubleshooting scenario. If multicast is one your weaknesses than I highly recommend digging in and making something happen. Debug ip mpacket works best with "no ip mroute-cache" on your interfaces. In this scenario, I started troubleshooting on R5, then worked my way around to resolve the issue :)