CCIE Candidate

Keith again. Yesterday I talked about the difference between the two bootcamp styles, but now that that’s out of the way, let’s get groovy on the tech-talk. This is a 5.5-day class in the Fremont facility. This evening marked the end of the fourth day, so I feel I’ve got a reasonable amount to discuss. As an aside, Fremont is the perfect place for a hardcore class like this. I think one vendor has a bootcamp in Chicago, which is far too fun a place to be studying all day and going to bed at 9pm. Fremont on the other hand … it’s like no one has ever seen a grown man with a mohawk. Weirdos.

Day 1 comprised of what felt like a couple of half-labs. Nothing too fancy, do a little IGP, some redistribution, BGP, a little QoS, the normal routine. I didn’t have too much trouble, which isn’t to say I did a great job, just that I was able to dig around until I got everything done. More or less. Some of the things I ran into that gave me problems:

• I don’t run DHCP servers on routers. I haven’t since about 2000, so sometimes I have to look up simple things like option-82. Unfortunately the doccd lumps option-82 in with DHCP snooping which led me to the somewhat dubious conclusion that I needed DHCP snooping to use option 82. You don’t, and I wish the documentation was clearer on this. Maybe it’s spelled out somewhere and I just missed it?
• Another conclusion I gleefully leapt to was that the requirement for a switch to “access the MAC address even after a reboot” meant sticky port-security. They were actually looking for a static MAC entry. That one could have gone either way, but port-security also limits the number of MAC addresses on the port, so technically I went out of scope. Next time I’ll look for something alluding to MAC address limitations, ports shutting down, MAC addresses in running configs, etcetera.
• One thing I flat out did not know was that RIP disables split-horizon when applied directly to NBMA physical interfaces. Hmph. I’d like to hear a transcription of how that conversation went. At any rate I got nailed on that again Thursday. Bah.
• Another easy one that got me was mincir in Frame Relay. Mincir defaults to 50% of the CIR, and IOS has a kind of safety feature that stops you from allocating more than mincir when you’re doing bandwidth guarantees - it kicks up an error and refuses the command. The easy way around this is to increase mincir, and if a task requires that you allot the entire bandwidth of an interface it’s really your only solution.
• I configured TCP Intercept correctly … almost. This is another feature I’ve never used in production and only lab up every few months. I got everything right except I overlooked the fact that by default it is in watch-mode, meaning it is not a proxy. I set up all the timers but forgot to set it to intercept mode.

Day 2 hit OSPF pretty hard, and covered some easy multicast areas. I was surprised to see that there were no RPF failures in any of the multicast configurations. My primary study material thus far has been IE Volume 2, and RPF failures are a favorite torture device of theirs. I was actually fresh enough after finishing day 2’s work to start looking it over before Rahim gave me what-for, and I managed to catch a few stupid things like forgetting to advertise a couple of loopbacks into OSPF and leaving off the “no-summary” on a stub area ABR. Easy points there. Some things I *didn’t* catch were:

• I neglected to apply the authentication key to an interface. I alias “show ip ospf” to the letter “o” because I use it so much, and I checked “show ip ospf neighbor” and “show ip ospf interface” multiple times, even grepping out things like “then” (that picks up “Authentication”), but this half-way up neighbor eluded me because it was on a broadcast network, and in my rushing to and fro’ I just assumed that the 2-way state was two DROTHERs being themselves. Meh. Assumptions really kill you. A simple clear ip ospf process with debugging turned on would have shown exactly who did *not* neighbor up after the smoke cleared.
• Rahim admonished me for using differing OSPF network types. I made an NBMA hub router p2m, and the spokes p2p, and just changed the timers on the hub. Rahim said this would result in a corrupted route table. Other vendors have repeatedly and confidently said that this will work just fine, but if they don’t ask for different type or mention timers, I’ll just do all p2m next time.
• It turns out PPP Chap authentication is even easier than I thought. I had R6 authenticate to BB3 via PPPoFR and added the line “ppp chap password cisco” to the virtual-template interface. This turned out to be unecessary as I already had “username BB3 password 0 cisco” in the global configuration. This was new to me - I always thought that the username was for one-way authentication only. I still had to specify the hostname on the virtual template, but after removing the password line and flapping the interface with ppp authentication debugging on it worked fine.
• L2 QoS on the 3550 … Rahim showed me a great trick today. I spent about 45 minutes on five simple QoS tasks, and I still missed a command on one of them. I trusted a cisco IP phone on a switchport with “mls qos trust device cisco-phone”, but forgot to “mls qos trust cos”. I also spent a lot of time remembering and looking up how to change COS and IPP maps. Rahim popped on the box, went to an unused port and did a “auto qos voip cisco-phone”. This created a bunch of crap, some asked for, most not. But it had all the required commands that you can manipulate in notepad and paste into your target port. Then simply default your dummy interface. BAM! 10 minutes or more saved.
• WCCP on a L2 device confused me again by being too easy. I only configure it every few months, and I always forget that there are only two commands. You just tell the SVI with the web clients to “ip wccp web-cache redirect in”, then enable it globally. The *output* interface is determined by the protocol, so I need to stop searching the docs for how to configure it.
• Multicast helpers threw me again with a couple of small details that the docs didn’t cover, or covered wrong. Specifically you only need the ip directed-broadcast on the first incoming interface, but the docs have it on the outgoing as well. Worse is the doc showing the multicast-to-broadcast conversion configuration on the outgoing interface, when it should be on the interface on which the multicast stream is entering the last-hop router.
• IPv6 was really frustrating. It wasn’t hard, it was just that I needed to change a neighbor discovery timer and wanted to check it in the docs first, only to find that the IPv6 command references for 12.3, 12.3T and 12.4 are all gone. This includes the master index AND the command reference. All links point to some stupid documentation index page. I hope Cisco fixes this before I take the lab.

There’s even more excitement where that came from, but my eyes sting and this post is already pretty long. Overall I’ve been able to finish the material every day so far, but had some reasonably large problems with my finished configurations. The good part is I’m out of my comfort zone - the same chair, the same keyboard, the same cat, the same interface numbers going to the same places, etcetera. Being on-site somewhere else makes it feel like a test too, and it drives me even harder than normal. And while I’m getting punished on IOS features and L2 QoS, I can take solace in the sound drubbing I’ve handed BGP and the IGPs.

---