Frame Relay and Inverse ARP
If you're reading this blog, I shouldn't have to explain basic Frame Relay and I shouldn't have to explain Inverse ARP. You already know this stuff or you can read it elsewhere. What I want to explain in this post is how important this may be to your exam - something that I didn't realize until recently.
Granted, FR is not cutting edge tech today and your lab may not focus so much on it - but it's very likely to have some area of FR on the exam. And the first time I saw this, I basically nodded my head and went on with the next video - yeah, that made sense. After my first lab attempt, I went back to review each video and re-wrote my notes and I didn't even write this down the first time. Wow. But I really got it the second time I saw it.
Here's how this plays out and why it's so important to remember. Take this scenario:
At first glance it doesn't seem like much. The original configuration would give you the default, natural Inverse ARP resolution between R1 - R2 and R1 - R3 and the 'issue' is that you can't ping .3 from R2 and you can't ping .2 from R3. So you add your static mappings and go on your merry way. It works.
I saw this the first time and said...okay...and went on. The second time...it hit me. You probably won't reboot. BUT when you lab ends, there WILL be a reboot between what you see and what the proctor grading your lab will see. Think about this. You will break your stuff and not even know it's broken!
So as you're doing practice labs, you look at this and say...oh, well, that's probably only worth 3 points. No, it's not. Think about it deeper and the implications of this one little thing suddenly mushroom. After your reboot, you have no connectivity from R2 to R1 and from R3 to R1. Doesn't this look like a hub and spoke kind of setup? Wouldn't this be a MAIN area that you would want to work?
This simple little thing will probably not be on the Troubleshooting section of the lab - it's too simple for that. This is likely to be an ingrained part of the Configuration section - where it will really get you. Think about all the practice labs you have ever seen - no matter where you have seen them. How many routers are involved? You're looking at about half of your configurable routers. True, some lab scenarios call for using some of the switches as routers...so okay, maybe you're looking at a setup using about 10 configurable devices? 100% of the configuration will be on those devices. You have just disabled connectivity between the hub and spokes of 3 of those devices.
So any of the routing that you would expect to work, probably won't work - or at least not 100%. Any of the security points you thought you were going to get for configuring feature X, Y or Z on R1 doesn't work anymore. Kiss those points bye-bye. And the scary part is that you thought you had those points in the bag. You tested it afterwards and it worked.
I wonder how many hearts got broken over that little screwup?
Three "takeaways" from this warning:
1) If you configure a static mapping, change all the mappings for that DLCI to static (for that protocol).
2) If something seems small and unimportant, look again - it may not be as unimportant as you think.
3) Reboot and recheck your rack at the end of the exam.
The last one is hard to swallow, but solid advice. This is how the PROCTOR grading your lab is going to see your configurations. You want to see what he/she sees -before- he/she sees it, and hopefully fix anything you missed the first time around. However, in order to do this, you need to finish early. It's going to take some time for your devices to reboot and then a bit longer to check everything again. PLAN on it. The more you know dead-on-inside-out-backwards-and-forwards the quicker and more efficiently you will configure the required items. The quicker and more efficiently you configure, the more time you have to check your work.
Oh, and the real lab shouldn't be the first time you reboot and check. You should do this with your practice labs as a routine part of your 'system' so you are comfortable with this method. This will also give you practice and build speed on checking your configuration. If you're used to checking things before declaring them "done," you will start to develop methods (and good habits) that will not only help you on your lab, but carry over to your work performance.