…only to hit a wall 25 minutes into the lab. There was a power surge and all of our computers/some racks rebooted. Luckily, all my work was already saved so there was no setback. I passed the TS section the last time around and felt pretty comfortable this time as well. I used this ‘confidence’ to push me into the configuration.

I read the test extremely slowly and carefully this time. I felt that certain questions were poorly written and the proctors absolutely refused to clarify any answers. In the end, I decided to “over” config rather than risk missing something because it wasn’t explicitly spelled out. I guess it turned out to be the right strategy.

The drive back to the airport was bumpy. We both felt like there was a shot we passed, but I felt the same way last time, so who knew. We did agree that the proctors did a poor job answering any questions.

Once we reached the airport I checked my email every 5 mins. Of course, they sent the score report email literally at the same time we boarded the plane. I was frantically trying to load my results when the flight attendant forced me to turn off my phone. There was no in-flight wifi, so I suffered 6 hours without knowing my result. As soon as we touched the ground I jammed my phone on and my score was waiting for me: 27704.

I couldn’t believe it and I started texting random people my result. It was an incredible way to end quite an incredible adventure.

I’d like to share some things I learned along the way.

The Lab

My home lab was crucial in getting me ready for the lab. It was also nice throwing together proof of concepts for work, etc.

The links are usually buried on this blog, but here are part 1 and part 2 detailing my home lab.

I went with the 4 switch, dynamips-for-routers design.

If you use are planning to use Linux, check out this post on tips with Screen and make sure to read the comments. There is a valuable script provided by Adnan Hassan.

Some Tips

I highly recommend finding a study partner for your lab studies. You will push other and achieve things a lot faster. Two heads are better than one and it’s always interesting to see how someone else approaches a solution.

Here’s how we prepared for the troubleshoot section. We created a “test bed” in Dynamips with all the standard topologies – Frame Relay, P2P, MPLS, etc. We then set up all the protocols and services that we wanted. We then went in and “broke” things for the other person to solve. This achieved a few different goals. One, you get solid TS experience. Make sure to practice with time limits, etc, to get a feel for the real thing. Second, when you are the person breaking things, you certainly see things differently. And finally, the test scenarios will probably be harder than the real lab, making the real thing easier. I know I used hidden commands and all sorts of crazy things to test my co-worker.

The most important thing I learned, though, was to just lab up everything you questioned. My work laptop always had a simple dynamips lab running a hub-and-spoke topology and a simpler 3 router point-to-point. 99% of things I came across I was able to quickly lab up and verify with my own eyes. The other 1% required me to turn on my rack at home, but even that was not a big deal. If you only get one piece of advice from this page: Lab everything and verify with your own eyes!

The Books

I used these mostly during my prep for the written, but they are a great resource even for the lab.

Cisco LAN Switching – Old, but the first half is excellent and still relevant today. It’s super cheap and the best book on layer 2 available IMO.

TCP/IP Routing Vol 1 – They call it The Bible for a reason. Get your core down with this book.

Developing IP Multicast Networks – Probably my favorite Cisco Press book. You can skips lots of chapters (that are not relevant for this test) and it’s smooth reading.

Internet Routing Architecture – Great BGP resource.

MPLS Configuration on IOS Networks – The examples in this book are amazing. Do a few MPLS labs and then clarify everything with this book.

More to come shortly…

I’m deeply humbled and I still can’t believe that I did it. It wouldn’t have been possible without my friends, family, co-workers, and everyone else grinding away, sharing, and teaching this tech.

I’ll post a more detailed account in the near future. I don’t plan on touching my computer this weekend.

It’s true what they say about this lab – it’s 80% mental. I knew the material, but my mind was not prepared for the stress. I thought I possibly failed the TS section and this ate away at me during the config section. Every time I pushed this thought away, it would come back stronger.

I feel positive about my next attempt and I’ve already booked the lab (early December). I haven’t turned my lab on in over a week and I’m steeling my mind for another push. I feel like I let some people down (friends, family, co-workers) but they’ve been supportive. I have to get this thing done for them.

We’ll go through all 4 options with the following target address assignments:

static – 1.1.1.10
local – 1.1.1.11
dhcp pool – 1.1.1.12
dhcp – 1.1.1.13

Our network diagram:

R1————————————————-R2———————————R3
ip add negotiated                       1.1.1.2                 2.2.2.x /24

R1 will be negotiating the addresses, R2 will be providing the addresses, and R3 will be our DHCP server.

Our configuration on R1 which won’t change throughout the task:

R1#sh run int s0/0
Building configuration...

Current configuration : 89 bytes
!
interface Serial0/0
ip address negotiated
encapsulation ppp
clock rate 2000000
end


Option 1 – STATIC

Static is pretty simple. Here’s our set up on R2:

R2(config-if)#peer default ip add 1.1.1.10

Bouncing the port on R1 brings us the correct address:

Oct 6 19:50:06.585: Se0/0 IPCP: O CONFREQ [ACKsent] id 2 len 10
Oct 6 19:50:06.585: Se0/0 IPCP: Address 1.1.1.10 (0x03060101010A)
Oct 6 19:50:06.597: Se0/0 IPCP: I CONFACK [ACKsent] id 2 len 10
Oct 6 19:50:06.601: Se0/0 IPCP: Address 1.1.1.10 (0x03060101010A)
Oct 6 19:50:06.601: Se0/0 IPCP: State is Open
Oct 6 19:50:06.609: Se0/0 IPCP: Install negotiated IP interface address 1.1.1.10

Option 2 – LOCAL POOL

First we create our pool on R2:

R2(config)#ip local pool R2_LOCAL 1.1.1.11

Now we set the correct mode on the interface and point to the named local pool:

R2(config-if)#peer default ip add pool R2_LOCAL

Bouncing the interface gives us what we’d expect:

Oct 6 19:52:34.305: Se0/0 IPCP: I CONFACK [ACKsent] id 2 len 10
Oct 6 19:52:34.309: Se0/0 IPCP: Address 1.1.1.11 (0x03060101010B)
Oct 6 19:52:34.309: Se0/0 IPCP: State is Open
Oct 6 19:52:34.309: Se0/0 IPCP: Install negotiated IP interface address 1.1.1.11

Option 3 – DHCP POOL

This one is similar to the local pool, except R2 will act as a DHCP server and provide the address that way.

Here’s our DHCP pool and excluded addresses to make sure the correct address is assigned:

R2(config)#ip dhcp excluded-address 1.1.1.0 1.1.1.11
R2(config)#ip dhcp excluded-address 1.1.1.13 1.1.1.255

R2(config)#ip dhcp pool R2_DHCP
R2(dhcp-config)#network 1.1.1.0 /24

The peer address configuration on R2:

R2(config-if)#peer default ip add dhcp-pool R2_DHCP

We see the goods on R1:

Oct 6 19:55:08.745: Se0/0 IPCP: I CONFACK [ACKsent] id 4 len 10
Oct 6 19:55:08.745: Se0/0 IPCP: Address 1.1.1.12 (0x03060101010C)
Oct 6 19:55:08.745: Se0/0 IPCP: State is Open
Oct 6 19:55:08.745: Se0/0 IPCP: Install negotiated IP interface address 1.1.1.12

Option 4 – DHCP

This one is a little tricky because we have to use R3 as the DHCP server.

If you put R3 onto the same subnet as R1 or even provide IP reachability, it’s quite possible that R3 will assign the address directly to R1.

The key here is to make sure R3 is using R2 to pass the address off.

The DHCP settings on R3:

R3(config)#ip dhcp excluded-address 1.1.1.0 1.1.1.12
R3(config)#ip dhcp excluded-address 1.1.1.14 1.1.1.255

R3(config)#ip dhcp pool R3_POOL
R3(dhcp-config)#network 1.1.1.0 /24

R2′s interface configurations, make a note of the helper address.

R2(config-if)#peer default ip add dhcp
R2(config-if)#ip helper-address 2.2.2.3

We see the following debug on R3:

*Mar 10 02:04:54.321: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d31.2e31.2e31.2e32.2d53.6572.6961.6c30.2f30 (1.1.1.13).
*Mar 10 02:04:54.321: DHCPD: unicasting BOOTREPLY for client c201.6d65.0000 to relay 1.1.1.2.

Success on R1:

Oct 6 20:13:23.321: Se0/0 IPCP: I CONFACK [ACKsent] id 2 len 10
Oct 6 20:13:23.325: Se0/0 IPCP: Address 1.1.1.13 (0x03060101010D)
Oct 6 20:13:23.325: Se0/0 IPCP: State is Open
Oct 6 20:13:23.329: Se0/0 IPCP: Install negotiated IP interface address 1.1.1.13

R3 does need a route to 1.1.1.2 for this to work. (I used a static route).

As usual, everything becomes nice and clear once you lab it up.

Just read through Anthony’s expanded blueprint and picked out a dozen items that I’m gonna spend some quality time with over the next couple of weeks. These are items that I’ve already configured and labbed up…but I want to get really down and dirty with them. (I’m looking at you, MSDP).

I want the debug messages to caress my skin. I want to see hex dumps when I close my eyes at night. I want the options to dance on my tongue when I eat dinner. OK, you get the idea.

All joking aside, I’m pretty happy with how my studies have progressed. Looking over the blueprint is a revelation. The amount of material I’ve learned is crazy. It’s also quite humbling, as I realize that this is just the tip of the iceberg in the networking world.

I have to admit that I’m nervous, but pass or fail, I know I’ve come out ahead.

We can (soft of) mimic how RIP deals with maximum hop routes.  As you are well aware, RIP’s maximum hop count is 15.  Any route with a hop count greater than 15 will not be installed in the routing table.  We can do the same with EIGRP and what’s cool is that we can set the metric maximum-hops to any number we like (up to 255).

First, we can see that EIGRP has a default maximum-hops of 100:

Rack1R3#sh ip protocols | i hop
EIGRP maximum hopcount 100

Rack1R3#sh ip ei top 192.10.1.0/24
IP-EIGRP (AS 10): Topology entry for 192.10.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2561024256
Routing Descriptor Blocks:
167.1.13.3 (Serial0/1), from 167.1.13.3, Send flag is 0x0
Composite metric is (2561024256/2560512256), Route is External
Vector metric:
Minimum bandwidth is 1 Kbit
Total delay is 40010 microseconds
Reliability is 1/255
Load is 1/255
Minimum MTU is 1
 Hop count is 2

Rack1R3(config-router)#metric maximum-hops 1

Rack1R3#sh ip ei top 192.10.1.0/24
% IP-EIGRP (AS 10): Route not in topology table

Rack1R1#sh ip prot | i hop
EIGRP maximum hopcount 1

It worked! Forget distribute-lists, we all know hop counts are where it’s at!

]]> http://ciscofun.wordpress.com/2010/09/21/eigrp-metric-hop-filtering/feed/ 0 suffah http://ciscofun.wordpress.com/2010/08/22/using-the-lab-workbooks/ http://ciscofun.wordpress.com/2010/08/22/using-the-lab-workbooks/#comments Sun, 22 Aug 2010 15:46:46 +0000 charliec http://ciscofun.wordpress.com/?p=187 ]]> Took me about 6 weeks to get through Workbook 2.

Like many others, I took a by-increasing-difficulty approach and broke the lab book down by difficulty levels.

I really feel this is the way to go when you’re just starting.  Hitting a level 9 early on when you can barely tackle a level 7 is demoralizing and inefficient.  More importantly, it’s difficult to gauge your progress.  This is a great motivational tool and, let’s face it, we need every advantage we can get.

Here’s how my schedule looked every day for the past couple of months:

Weekdays

• Read Vol 1 during my commute (2 hours per day).  Originally, I planned on reading topical books but I realized that I still retained a lot of the theoretical knowledge from prepping for the written.  My time is better served with vol 1.  On a side note, the Kindle DX is an amazing tool for this.
• Instead of using google to look up things at work, I tried to use the DocCD first.  We all know what a bastard navigating the DocCD can be, so the more exposure the better, in my opinion.
• 4 hour lab session every night.  I think I only missed 1 night during the past 6 weeks.  This is when I got the bulk of the work done.  20 hours a week on top of whatever I could squeeze in at work.
• I also did reviews every day.  I want to emphasize how important reviewing is.  Whether your preference is physical flash cards, a software SRS program (Supermemo, Mnemosyne, Anki, etc), mindmapping, or even jotting down traditional notes in a notebook, make sure you incorporate reviewing into your routine.

Weekends

• I usually did two 3-hour sessions each day, one in the morning and one late at night.  This way I still had time to do “normal” stuff during the day and not drive myself crazy by labbing 24 x 7.

The first 3-4 labs kicked my butt real bad.  I even held some concerns that I booked the lab way too early.  However, by the 10th lab I could tell I was really gaining steam.  When I finally hit the level 9 labs, something really interesting happened.  At times they felt easier than many of the level 7-8 labs.  My co-worker who is also working through the workbooks made a similar observation – he thought the level 9 labs were written by a completely different person.

Upon further analysis, we both realized the truth.  Our hard work had payed off.  We’re seeing the fruits of our labor.  The key at this point is to continue pressing hard.  I can’t take my foot off the gas pedal.

The lab date is 2 measly months away.   It’s daunting, but I know the reward will be that much more satisfying.  I wouldn’t want it any other way.

]]> http://ciscofun.wordpress.com/2010/08/22/using-the-lab-workbooks/feed/ 2 suffah http://ciscofun.wordpress.com/2010/07/10/mastering-regular-expressions/ http://ciscofun.wordpress.com/2010/07/10/mastering-regular-expressions/#comments Sat, 10 Jul 2010 19:28:59 +0000 charliec http://ciscofun.wordpress.com/?p=150 ]]> Regular expressions are not inherently difficult.  They just require a lot of practice.  The difficulty is finding an easy way to practice.

That’s where looking glass servers come in.  The bottom of this website lists numerous BGP route servers that allow anonymous telnet access.

I’ll pick a random server for this example: tpr-route-server.saix.net

First, we need to telnet in:

[769][charlie] ~/.dynamips $ telnet tpr-route-server.saix.net

Trying 196.25.9.46...

Connected to tpr-route-server.saix.net.

<snip>

tpr-route-server>

This brings us to our trusty command prompt.  A quick “show ip bgp” shows the prefixes.

tpr-route-server>sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
* i1.9.0.0/16       196.43.9.234             1    100      0 3491 4788 i
* i                 196.43.9.234             1    100      0 3491 4788 i
*>i                 196.25.9.45              1    100      0 3491 4788 i
* i                 196.25.9.45              1    100      0 3491 4788 i
* i1.12.0.0/24      196.25.9.45              1    100      0 3491 4134 4847 18245 i
* i                 196.43.9.234             1    100      0 3491 4134 4847 18245 i
* i                 196.43.9.234             1    100      0 3491 4134 4847 18245 i
*>i                 196.25.9.45              1    100      0 3491 4134 4847 18245 i
* i1.12.0.0/14      196.25.9.45              1    100      0 3491 4134 4847 18245 i
<snip>

Let’s see what routes our favorite evil megalocorporation is originating.

tpr-route-server>sh ip bgp regexp _714$
BGP table version is 138080411, local router ID is 196.25.246.90
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i17.0.0.0/9       196.25.9.45              2    100      0 3356 714 i
*>i                 196.25.9.45              2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
* i17.31.0.0/16     196.25.9.45              2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
*>i                 196.25.9.45              2    100      0 3356 714 i
* i17.34.0.0/16     196.25.9.45              2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
*>i                 196.25.9.45              2    100      0 3356 714 i
* i17.36.0.0/15     196.25.9.45              2    100      0 3356 714 i
* i                 196.43.9.240             2    100      0 3356 714 i
<snip>

That’s it. With a little practice you’ll soon master regular expressions.

]]> http://ciscofun.wordpress.com/2010/07/10/mastering-regular-expressions/feed/ 4 suffah http://ciscofun.wordpress.com/2010/07/08/link-status/ http://ciscofun.wordpress.com/2010/07/08/link-status/#comments Thu, 08 Jul 2010 04:21:18 +0000 charliec http://ciscofun.wordpress.com/?p=152 ]]> I had a co-worker help write this nifty command that I’ve trimmed down.

It’s a quick way to check your ports after starting your switches in your home lab.

I’ve found it particularly useful when used with remote power (ie IP Power).

ifconfig | cut -f1 -d' ' | tail -n +2 | xargs -n1 sudo ethtool $i | egrep '(Se|L)'

This is the output I get from running this command:

Settings for eth1:
Link detected: yes
Settings for eth2:
Link detected: yes
Settings for eth3:
Link detected: yes
Settings for eth4:
Link detected: yes
Settings for eth5:
Link detected: yes
Settings for eth6:
Link detected: yes
Settings for eth7:
Link detected: yes
Settings for eth8:
Link detected: yes
Settings for eth9:
Link detected: yes
Settings for eth10:
Link detected: yes
Settings for eth11:
Link detected: yes
Settings for eth12:
Link detected: yes
Settings for lo:
Link detected: yes
Settings for vmnet1:
Settings for vmnet8:

Be aware that 3560 links take a while to show as “up” due to Auto-MDIX.

]]> http://ciscofun.wordpress.com/2010/07/08/link-status/feed/ 0 suffah http://ciscofun.wordpress.com/2010/07/04/notepad-for-speed/ http://ciscofun.wordpress.com/2010/07/04/notepad-for-speed/#comments Sun, 04 Jul 2010 05:55:44 +0000 charliec http://ciscofun.wordpress.com/?p=155 ]]> I just finished lab 1 from INE workbook 2 and experimented with using notepad, actually gedit in my case, and the results have been positive.

In fact, I am positively sure that this will enhance my speed as it forces me to rely less on IOS help.  It’s also easier to spot and fix typos.

Feel free to share your notepad tips and tricks.

]]> http://ciscofun.wordpress.com/2010/07/04/notepad-for-speed/feed/ 0 suffah