This lab (NetMasterClass.com DOiT Vol2 Scenario 15) was a little short, but had that standard number of “odds and ends of IOS that I was not previously acquainted with”. Overall, if this has been the actual lab, I think I would have passed. In that sense, the lab was too easy. Too much of it was straightforward, or featured commonplace tasks. That’s not to say I nailed every task – I did not. But I’m fairly confident that 80+ points were mine.
I finished this lab in just under 7 hours. Had I been on my game, I could have got it done in more like 6 hours. But I made a few simple errors that cost me time in troubleshooting, plus I had an interesting phone call in the middle that threw off my concentration. It took a little bit to get back into the zone after the call.
And there’s something else that I think is really worth mentioning. About hour 5, I started to get tired. You know – sleepy. Why? I had lots of sleep last night. I think the reason is that I simply didn’t eat enough this morning. I had an apple. And a little later, I had a cereal bar. I’m a fairly big boy (hey, no smart remarks, I’m 30 pounds less than what I used to be!), and the ~200 calories just didn’t cut it. I burned through that in nothing flat, and eventually started running out of steam. The lesson I’m taking away from that is to make sure I get a decent breakfast the morning of the actual lab. Not overdo it, but make sure I get enough to fuel me until lunch.
Here’s the tech highlights from this scenario.
- You can configure back-to-back frame-relay (frame-relay with no frame-relay switch in the middle) a couple of different ways.
- If asked to use the trunking method that does not support native VLANs, you must use ISL. 802.1q trunks support native VLANs; ISL trunks do not.
- On a trunk port, the “switchport trunk allowed vlan” command allows you to control what VLANs will be carried across the trunk. This is what’s needed if you are asked to make sure that only the necessary VLANs are permitted across the trunk.
- Read carefully when doing any tasks. I know I’ve said this before. Maybe if I took my own advice, I’d have less issues here. In this case, I overlooked where it said “Use the OSPF non-broadcast network type”. And so I had to go back to Notepad after almost all my OSPF was written, set the network type, and then add neighbor statements. It’s not that it was hard to do, just that I was thinking I was moving right along, only to discover I had to go back and re-engineer something because “Johnny can’t read”.
- Don’t forget that if you configure an area to be stub, totally stub, NSSA, etc. that EVERY router in that area has to be configured the same way.
- The network making up this lab happened to be 188.8.131.52/16. When configuring the RIP section in Notepad, I keyed “network 184.108.40.206″, and promptly pasted it to several of the RIP paragraphs I was duplicating for various RIP routers. When I pasted the code in, I sanity checked my routes, and discovered that RIP wasn’t running. Well, THAT was odd…after several minutes of scratching my head, running “debug ip rip“, etc., I discovered my typo in the network statement and fixed it. That was a waste of valuable time for something that should have just worked the first time out the door. And it also points out that sometimes the most likely explanation is the right one…even on CCIE practice labs. :) I was thinking to myself, “Man, it’s like the network statement isn’t configured, but THERE IT IS! So it must be something else…” I was wrong – the network statement was configured for the wrong network, and my brain just didn’t see it. Silly brain.
- In the context of RIP, filter out 4 continguous /24 inbound advertisements with one filter statement. Now, here’s a fun task <groan>. I’m thinking to myself – “You can’t do it. You could with a prefix list, but you can’t do a prefix-list with RIP. Distribute lists require an exact prefix length match in the wildcard mask. So you can’t do it.” And then I crossed my arms and began to pout like my 9 year old. :) But after the pouting, I started thinking that I could summarize the 4 contiguous networks on the upstream router, then filter the summary route with one statement on the downstream router. But the way the task was worded, that wasn’t really what it was asking me to do. Figure it out yet? Let’s say the routes to filter were 192.168.152.0/24, 192.168.153.0/24, 192.168.154.0/24, and 192.168.155.0/24. Your filter statement would be “access-list 1 permit 192.168.152.0 0.0.3.0”. If you keep the last octet of the wildcard mask “0”, and tweak with the third octet, the distribute list will match like you want. It’s awesome. I had no idea you could do that.
- How about this for another funky wildcard mask? Let’s say you have to match 192.168.157.0/24 and 192.168.159.0/24 (but NOT 192.168.158.0/24 or 192.168.160.0/24) in one statement. That would be “access list 1 permit 192.168.157.0 0.0.2.0”. How do you come up with this funky mask? You write out the 2 prefixes in binary, then stack all the little 1’s and 0s on top of each other, as if you were adding up a couple of really long numbers. Then you do an XOR binary comparison on the numbers. (XOR compares 2 binary numbers. The result of the comparison is “0” if they are the same, and “1” if they are different.) Use the XOR result and convert back to decimal for your wildcard mask. It just occurred to me that if you don’t know how to convert decimal to binary and back, then this makes no sense. But if you’re a CCIE candidate, it’s got to be a safe assumption that you can convert binary to decimal and back, doesn’t it?
- I have to mention that I forced myself to write my own TCL script for reachability in this scenario. I had been in the habit of copy ‘n’ pasting NMC’s handy little script from the DOiT page, but I’m not going to be able to do that in the actual lab of course. I strongly recommend that you do that same if you’re used to using those little TCL scripts. Of all things, getting the brace syntax correct was actually a pain. I need to do it several more times so that it’s automatic. It is a huge time saver.
More in the next post…