Hello loyal CCIE candidates! I have to apologize ahead of time because I am going to be writing my reviews of Volume 3 labs 1 and 2 at the same time. So, they may not be as thorough as usual. To be honest, I’ve been going so hard at these labs, I kind of have already forgotten what the hell I did on Lab 1! I am going to sift through the proctor guide now to try and remember some things.

Task 1.4 — This had an interesting verification command I picked up. Part of the task said to “use the template on Cat1 that will allocate the TCAM resources to support the highest number of indirect unicast routes” Well, I was almost sure it would be “sdm prefer routing” but wasn’t positive. The docCD didn’t really mention any of the key words either when I looked up the different templates. I had forgotten all about the command “show sdm prefer”. This command is awesome, because it will actually show the numbers for template. So, if you run this command against each template you can simply look at the numbers and figure out which has the highest number of unicast routes. I’m still not sure what was meant by “indirect” but oh well. Oh yeah, don’t forget to save your config and reload your switch after changing the sdm template!!! Even though it tells you to do so, it is so easy to say “Oh yeah, I’ll do that after the switching section” Not good if you come to find out later you got 0 points for that task!

Cat1#sh sdm prefer routing
routing template:
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1K VLANs.

number of unicast mac addresses:Â Â 5K
number of igmp groups:Â Â Â Â Â Â Â Â Â Â Â Â 1K
number of qos aces:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 512
number of security aces:Â Â Â Â Â Â Â Â Â Â 512
number of unicast routes:Â Â Â Â Â Â Â Â Â 16K
number of multicast routes:Â Â Â Â Â Â Â 1K

Task 2.2 – EVIL at it’s best — This task made me want to punch somebody in the mouth repeatedly. Or perhaps beat them on the head with one of those old style terminal keyboards…you know the really solid ones that could have potentially be used as a weapon 🙂 At first it looks innocent, “For the connection between R4 and R5 use a PPP over frame configuration with RFC 1973 encapsulation. The connection should use CHAP authentication. For authentication, both devices should use a username of T3ST123 and a password of PPPoverFr@m3. Both sides should challenge and respond”

OK, so PPPoFR, not so bad. I did a quick check for “1973” in the command reference to make sure I wasn’t missing something weird, but it turns out that RFC just specifies PPPoFR. The evil part came with the CHAP configuration. By default CHAP will use the router name as a username. Therefore, you would need to define “username <remote router> password <password>” in a simple config. Alternatively, you can specify what username and password to use with the “ppp chap hostname” and “ppp chap password” commands. If you just use “ppp chap hostname” it appears you also need that hostname set up as a user on the remote end with a password defined.

So here we had “ppp chap hostname T3ST123” on both ends as well as “username T3ST123 password PPPoverFr@me” on both ends…NOTHING…and everytime I did debug on ppp auth all you get is some error saying the authentication was rejected because you have the same username on both ends. After 45 minutes of searching the documentation and playing on the router I broke and looked at the PG. The magic answer is an undocumented command called “no ppp chap ignoreus”. Even in IOS help you cannot see this command, and it is nowhere in the command reference. Truly insane.

Task 2.3 — This was the first task I have had that required one end of a PPP link acquire it’s IP address from the other end. I was aware of IPCP before, but had never configured it. I went to the doccd and was able to figure out “ip address negotiated” on the remote end. However, in the documentation it really doesn’t tell you how to specifiy which address you will receive from the other end. Turns out the answer to that one is “peer default ip address” If you look that up on the doc cd it makes perfect sense, but it sure would be nice if they had an example with both commands in the same place.

Task 3.6 — I pat myself on the back for getting these right. I love these questions that make you use insane access-lists! “Configure R4 to receive routes via RIP from BB2. R4 should receive routes from BB2 of the format 172.20.x.y. Only allow routes with a third octet from 33 to 46, using an access-list. Your access list should use the fewest number of lines that will not allow any extra networks”

The first thing I do with tasks like these is write out the binary. So in this case I wrote out in notepad the binary versions of 33 – 46. Then, carefully examine them and find out where you can group things together. I no longer have that notepad around, but the end solution was

access-list 20 deny

access-list 20 deny

access-list 20 permit

Nailed it!

Task 3.9 — Redistribution — Here we had to “redistribute as needed on R1, R2, R5, and R6 so that all routers can reach all networks” This is a section where I am trying to improve my speed. This was the first time I attempted it with no filtering to save time, and it worked out OK. I carefully examined my diagram to make sure no loops would happen, and turned on “debug ip routing” on all the redistribution routers just in case. All was good!

Task 6.2 — Frankly, this task turned out to be a real bitch. I knew how to do it, it just was NOT working. I kept getting frame-relay encapsulation failed and it didn’t make any sense. After 2 or 3 days of having some of the most respected engineers in the industry graciously looking at my configs I found out it was an IOS bug. Go figure. This was a DHCP task. You had to setup a DHCP server on R4, to hand out addresses to hosts on an ethernet that was across R4’s frame cloud. The trick was using ip helper on R6, not that hard in theory.

I used to fear IPv6. I was just very unsure about it. But after doing these practice labs, I am considering IPv6 to be easy points! Most of the configurations are fairly straight forward. It’s just a matter of knowing the basics. Hopefully the real lab is as kind

task 8.3 — This was cute, in that it asks you to configure R2’s fastethernet interface to drop ICMP type 0 and type 8 packets within a certain size range. Pretty simple QoS task IF you know what ICMP type 0 and 8 happen to be. Luckily for me, I had been debugging some ICMP earlier in the lab and if you do a debug ip packet detail on an icmp ACL it will actually reveal to you that type 0 and 8 are ICMP echo and echo-reply. Marvelous!

All in all, this was a success. I definitely passed this lab.

Stay tuned for Lab 2 review maybe when I finish this beer 🙂