1,342 Words. Plan about 9 minute(s) to read this.
At long last, I have completed the NetMasterClass.com DOiT Volume 2 series of 25 full-scale practice labs. It’s been a long journey, having started back in August 2007. I wish I could say I know forwards and backwards everything that’s in these labs, but the fact is, I don’t. I’ve learned a lot, don’t get me wrong, but I could stand to go back through certain of them again. I’d like to do that – maybe pick 5 of these scenarios and just work on them again and again until I know them cold. But for now, I’m going to shore up my foundation by working on technology-specific labs from Soup-to-Nuts.
This lab took me about 7 comfortably-paced hours. I took my time, did diagrams for BGP and redistribution, thought all my solutions before I executed them, and checked each major section with the answer key as I went. The stuff I know, I know pretty well. I can quickly set up any routine exercise, and I’ve had to deal with many of NMC’s “hidden issues” enough times to see them coming. The stuff that I don’t know off the top of my head I can usually find in a hurry on the Doc CD and crank out at least a good part of the configuration. I think that all relates to why it’s taking me far less time on these labs than it used to. I wish it also translated to better scores, but I still make a little mistakes that would cost me in the real lab.
Here are the issues that I took special notice of in this practice lab.
- I didn’t think properly through a task that said “Choose shortest network mask on this subnet that will not break connectivity.” In other words, they left it up to me to choose the subnet mask for a particular point-to-point link. My brain hastily interpreted the task to mean “Make the subnet as small as you can,” which is wrong. The task says to choose the SHORTEST MASK, therefore the LARGEST subnet I could make it without clobbering anything else on the network. I don’t know why I do things like that. I need to get it through my head that when a flag goes up, and I need to think about the problem a little harder. The flag was definitely up on that task, but I just rushed ahead without reading the task until it sunk in what I was missing.
- This was a lab where it paid off to read ahead. That’s true of all the labs, but the point was well-illustrated with the OSPF configuration. Here, 2 significant OSPF tasks were not in the OSPF section. Rather, a task requiring OSPF authentication in area 0 was in the Security section, and another requiring the use of the “ispf” command was in IP Features section. In this case, it would have been easy enough to add them later. However, I much prefer getting my IGPs right the first time, and not having to tear them apart later because I overlooked a task.
- If you configure OSPF area 0 authentication, you will also have to perform that same authentication for virtual links. Otherwise, the virtual link will not come up. What’s strange is that I don’t see this function documented with the area virtual-link command. But here’s an example of how virtual-link authentication looks in the router ospf paragraph:
area 25 virtual-link 22.214.171.124 authentication message-digest
area 25 virtual-link 126.96.36.199 message-digest-key 100 md5 nmc25
- I had a task asking me to configure an OSPF network type that would only use 188.8.131.52 as a destination IP. This was a head-scratcher, because I couldn’t remember what 184.108.40.206 did, nor what other unicast or multicast addresses might be involved in OSPF communications. That’s theory stuff that I SHOULD know, but I didn’t happen to know off the top of my head. Well, 220.127.116.11 addresses all SPF routers, and 18.104.22.168 addresses all DR routers. That was the key thing to know, that I didn’t know – I needed an OSPF network type that avoided the election of a designated router, leaving out broadcast and non-broadcast, and selecting from what was left.
- An interesting task was to configure redistribution connected into OSPF for a specific loopback interface such that if the IP address of the loopback was changed, it would still be redistributed. That magic happened with the “match interface” command in a route-map, although that command doesn’t do quite what you might think it would. The Doc CD explains “match interface” like this:
To distribute any routes that have their next hop out one of the interfaces specified, use the match interface command in route-map configuration mode.
When using “match interface” to with a loopback, all you end up matching is the loopback. A loopback is highly unlikely to be a next-hop for anything other than itself. But be aware of what’s really going on if you try to apply this match command against other interfaces.
- If you make a router an “eigrp stub“, he won’t be used as a transit router. If you’re not familiar with this concept, you gotta read up. Stub routing incredibly useful in the real world on networks where you have customer edge routers that are dual-homed back to your company. Making your customer edge routers into EIGRP stubs means that you’ll never have a goofy convergence problem where one data center is trying to talk to another one via low-bandwidth, high-latency links running through a customer site.
- From the “Why Didn’t They Tell Me This Sooner” department – you can set distance on OSPF routes for intra-area, inter-area, and external routes, all independently of one another. Oh yes, it’s true. If you feel as cheated, used, and lied to as I do, read the “distance ospf” command for yourself and lab it up. Talk about another powerful bullet in the redistribution gun!
- The BGP in this scenario was not overbearing, although there was some funk about it. One odd-man-out router didn’t know how to forward for certain of the BGP prefixes, which was solved by redistributing routes to him through the IGP. That’s not a solution I cared for, but it was the right one in this case.
- One BGP task called for “R1 to immediately reset session if link to directly connected neighbor goes down.” There’s 2 different commands to handle that, depending on if the session is iBGP or eBGP. For iBGP, you can use “neighbor fall-over“. For eBGP, you can use “bgp fast-external-fallover“.
- The “bgp dampening” command was also needed in this scenario. BGP dampening is used to prevent a flapping route from taxing the resources of other BGP routers as the route is advertised and then withdrawn. From the Doc CD:
The bgp dampening command is used to enable BGP route dampening. This command can be entered without any arguments or keywords. The half-life, reuse, suppress, and max-suppress-time arguments are position-dependent; meaning that if any of these arguments are entered, then all optional arguments must be entered.
When BGP dampening is configured and a prefix is withdrawn, BGP considers the withdrawn prefix as a flap and increases the penalty by a 1000. If BGP receives an attribute change, BGP increases the penalty by 500. If then the prefix has been withdrawn, BGP keeps the prefix in the BGP table as a history entry. If the prefix has not been withdrawn by the neighbor and BGP is not using this prefix, the prefix is marked as dampened. Dampened prefixes are not used in the BGP decision process and not installed to the routing table.
- This scenario concluded with a multicast scenario using BSR for RP discovery and bidirectional PIM. I understood why the traffic flowed the way it did reasonably well. Even so, this was one of those multicast scenarios where I opted to walk it through with the answer key step-by-step, and check a lot of show command output to be sure I understood what was going on. I’m worlds better with multicast than I was, but the mechanics of multicast forwarding in different scenarios still requires a lot of thought for me.