If you also do these scenarios, you’ll realize that I don’t blog about each and every thing that I could. I usually mention things that I don’t think I’ve mentioned before, or that was particularly challenging for me at this stage of preparation. If I don’t mention something that you want to see discussed, by all means register and leave a comment with your thoughts. Glad to hear what other candidates are working through.
Here we go with a wrap-up of NMC DOIT v.2 scenario 14 highlights. Lots of these you might consider fundamentals, but they’ve become such a rote part of the scenarios, it felt it worth writing down (again, in some cases). After all, we have to know the fundamentals to pass, period.
- When you are instructed to “not rely on frame-relay inverse-arp”, what that really means is that you are to do a “no frame-relay inverse-arp” and manually map IPs to DLCIs with “frame-relay map” statements. “Not rely on” doesn’t mean “use it if you want, but don’t count on it”. What it really means is “shut it off”.
- I was staring at a problem where I had the same address space spread across 2 different VLANs. I knew some kind of bridging was in order, but I got hung up because I’d incorrectly decided that the VLAN bridging had to happen in the 3550 switch. The correct (and topologically obvious) answer was to use the router that was a member of the 2 VLANs and use IRB. I say “topologically obvious” because when you looked at the diagram, the router with his feet in both VLANs was the spoke – the 2 other devices he was to eventually EIGRP peer with was hanging off as spokes. Just by design then, it should have been obvious to me to bridge on the router. But it wasn’t, not sure why.
- When looking at an OSPF design, spotting the need for virtual-links should be automatic. As you look at an OSPF topology diagram, you should see that certain areas don’t have connections to the backbone area and begin seeking out the best area to make a virtual link. It should not come as a surprise that some areas are unreachable, if there’s a virtual link requirement. I’m finding that NMC never tells you that you need a virtual link. That’s an issue you should be readily able to spot.
- To unicast (not broadcast or multicast) RIP, set the interface to passive, then use “neighbor” statements to manually configure unicast RIP neighbors.
- You successfully complete any NMC scenario and presumably the actual lab, you need to be highly competent with protocol-independent routing features such as using distribute-lists to filter inbound and outbound routing updates, distance to manually adjust the administrative distance of routes learned from specific neighbors, redistribute to pump routes from one IGP domain into another, and route-maps to filter redistribution plus many other functions. You need to know what these features do, where to use them, and how their behavior differs in different IGPs.
- It is possible to perform automatic installation of a router over the wire. In other words, the naked router pops on the wire, puts a DHCP request out there, and the response from the IOS DHCP server includes an option 150 response with the IP of the TFTP server, plus the name of the boot file the naked router should be requesting. I haven’t read up on this autoinstall process enough myself to comment further, but I can say it looks like a lot of error-prone headache. I’m going to get smarter about it by reading, but I don’t plan to obsess over it.
More in the next post…