I completed IE’s Volume II lab 3 for the second time yesterday. I’ve started redoing all of the labs in order (I hope to make it through all 20 before my lab date). As I’ve stated before, I was surprised that I don’t memorize labs. It looks like I last did this lab back in December (where has the time gone?) so it shouldn’t be too big of a surprise.
This was a difficulty level 6 lab, so it was pretty straight forward. I did hit a couple of snags, but I was able to get through them because I finally have my head around some of the technologies. As Brian Dennis says, “You never stop making mistakes, you just get better at spotting them.”
The first time through this lab I was nowhere near as strong in BGP and multicast (I’m still not “lab ready” in either technology, but I’m way better than I was). In this lab there were two AS 100. I was having a heck of a time because I could not get the backbone prefixes advertised into one AS 100 to propagate to the other AS 100 (there was a transit AS between them). So I stepped back and thought about it. I could see the prefixes in the peer’s BGP table and I could see that they were being advertised (‘show ip bgp neighbor x.x.x.x adv’) from the peer but not received by my router (“show ip bgp neighbor x.x.x.x route’). My router was installing 3 other prefixes that were originated from a different backbone router. WTF? So I started mentally running through the reasons why my router would not accept those routes. What was it that was different about those 3 prefixes that were installed and the 10 that were not being installed. Voila! Those 10 prefixes were being advertised to the other AS 100 then to the transit AS and then dropping when hitting this AS 100. DOH! A BGP router will not install prefixes that already contain its own AS number. That was the problem. Now I could concentrate on solving this issue rather than wasting time on troubleshooting.
Now you’re probably thinking “big deal” and/or “how does this guy expect to pass the lab?”, but my point is that I was able to solve this issue by knowing the technology. I’m pretty sure that the first time through this lab I did not even notice this issue (you eventually filter those routes, so it becomes a non-issue) nor would I have successfully found the reason. Doing a lab for a second (or third…or forth…) time can help catch problems that you did not see the first time through.
I hit another snag when I got to multicast. Try as I might I could not get one of my routers to recognize the RP. The interface was configured correctly and I was seeing the PIM neighbor. By doing a simple traceroute I was able to see that traffic was routing over a PTP link instead of the Frame Relay link. But I took care of that earlier in the lab by setting the OSPF cost to a high value, right?. Unfortunately, after that task I set the OSPF auto-cost so that all of the other links now had a higher cost. My PTP link was now preferred over my Frame Relay link. I had used a high cost value (6000) but it was not high enough once the other costs were adjusted 😦 Again, I was able to (relatively) quickly find the issue and I understood how and why it was happening (as well as how to fix it). My multicast configuration was correct. The first time through I most likely did not catch this issue because I probably did not verify everything with the degree of anal-retentiveness that I do now. I could have easily overlooked this issue if I did not verify the RP mapping on that router. The problem would not show up in my ping scripts. I would have lost points for at least two sections.
Anyhoo…my point is that you should definitely do labs more than once, especially if it’s been a while since you last did the lab.