EIGRP CCNA Theory Review

Today I started with going ahead and labbing out a multi area OSPF scenario without using ANY type of books for reference. Everything went surprisingly smooth without any hiccups, I was able to confirm that the two routers in both area o and 1 was working along with one router being inside area 1 completly. After that I spent a few hours reviewing EIGRP Routing theory at the CCNA level of things. I really focused my efforts on how EIGRP calculates its routing metrics and how it converges using RD's (Reported Distances) to determine if it could be used as a feasible succesor route to a certain network. Tomorrow I begin my 3 day work week but I'm working the weekend schedule again so I'll be bringing in my PC from home and studying throughout the day since I should have some downtime.

OSPF Broadcast CCNA Lab

Today I spent a few hours playing with an OSPF broadcast lab which is basically an inter-network within a LAN instead of the usual point-to-point WAN. The main purpose of this lab was for me to determine which router would become the DR (Designated Router) that would be responsible for the LSA's. I created the network using the 192.168.146.0 /26 network and set the RID's up in the way where R1 would be the DR, R4 would be the BDR (Backup Designated Router), and the other two would be DRother's (non-DR's). I spent some time confused because I would notice that even if R1 had the highest R.I.D. (9.9.9.9) it still wouldn't become the DR for this network. After I did a little research it hit me that it all depends on which routers comes up first because with OSPF when a new router comes up within the OSPF network, the network won't change it's DR settings regardless if the new router has a higher RID or not. The best way to get around this without having to reload the routers in a tedious particular order is to run the clear ip ospf process command. This basically restarts OSPF on the network and will force all the routers to form fully adjacent connections with each other b.ased on the routers currently running OSPF within that area.

I was forced to think about how OSPF functions using LSA's in a single area which was good because this is something you could run into on a production network. I didn't do a multi area network lab today because it really isn't much to it CCNA wise. You do have to understand the area 0 is the backbone area while other area are seperated with an ABR (Area Border Router). An ABR is exactly how you would think it would be it sits on the border between different OSPF areas to allow the different areas to communicate while preventing the areas from having to share LSDB info which would cause more processing power and slower convergence due to the area being larger. Breaking large OSPF networks into smaller areas is always a good idea, especially when there are 100's if not 1000's or routers and subnets in the Autonomous System. Different areas allows the network to be more scalable and not have to converge every time a single router interface is changed!

OSPF CCNA Lab Review

I spent the better part of my morning reviewing OSPF CCNA theories and how this link-state protocol works. It was good to get my head wrapped around LSA's and LSDB's and how each router calculates it's own routing table using SPF Algorithm. A Link-State Data Base (LSDB) is basically a map that each router uses to plan the best route to reach every other router in its inter-network. Routers use OSPF to find out what information it's neighboring router has such as it's IP, subnet, and RID (Router I.D.) along with rather it should even communicate with its neighbors. Routers sends multicast Link-State Advertisments (LSA's) to the 224.0.0.5 address out all of it's interfaces in hopes that one of it's neighboring routers will respond back. I created a simple OSPF lab today and tomorrow I will hopefully create a lab consisting of Priorities and OSPF interface cost associations to pre-determine a path the router should take to reach certain networks.

CCNA Routing Protocol Theory Review

This morning I went through most of Chapter 8 in the CCNA ICND2 book regarding routing protocol theory. This was a really good refresher on how distance-vector works in regards to convergence and why it takes so long to converge. Due to Distant-Vector protocols being overly simple, it's very easy to cause routing loops. The only way to really deal with these routing loops with distance-vector is to use very long drawn out mechanisms such a Hold-Down timer that can take as long as 3 minutes before the inter-network can converge! I'm going to go over the rest of the chapter here shortly which reviews CCNA link-state routing theories. There isn't much to lab for this chapter but I will be doing a lot of labbing on the next chapter which is regarding the OSPF protocol.

Frame/ACL CCNA Review Lab

Today was a pretty eventful day, it took me FOREVER to get the Frame Relay Toplogy working correctly. What I've learned when using GNS3 to create a fram relay lab is that if you make a simple mistake on the Frame Relay Switch you need to delete the physical serial connections on the routers to the switch and re-connect them once you corrected your changes on the FR Switch. I setup the R1 router with frame along with R2 and they could ping each other fine. However when i configured the R3 router I couldn't ping the R1 router. After double checking my configs I realized on the FR Switch that I had the phyisical serial connections for the DLCI's set incorrectly. I changed this and I tripled and qaudrupled checked that everything was configured correctly. Even after this I STILL couldn't reach R1 from R3!

So I decided to run the show Frame-Relay PVC command on both R1 and R3 which shows the currently active and inactive DLCI's on the router. That's when I noticed that the DLCI's related to R3 on both routers were showing up as deleted! Which was really strange I've never seen this before. After doing some research it turns out that this usually points to an issue on an ISP's FR Switch. After triple checking my FR Switch I knew everything was setup perfectly. I had one last ditch effort which was to delete the actual Router serial connections and reconnect them. I did this, restarted the router devices, and voila...the routers came right up! I finished configuring R4 and throwing EIGRP into the mix and this lil network was ready to go. I actually didn't get to the ACL portion of this lab due to spending so much time just getting the thing setup, but tomorrow I plan on finishing this lab and starting chapter 8 on CCNA Routing Theories!

Extended ACL CCNA Lab Review

This morning I created my own little Extended ACL Lab, mainly because the examples given weren't possible to create exactly in GNS3, well at least not without creating Virtual Machines and things of that sort (saving that for CCNP). The lab went fairly well I knew what I needed to do and how to go about doing it without needing to reference the Cisco book. Since I was creating the lab in my head on the fly I made a lot of silly mistakes however since I didn't really document or check my work. This ended up taking me twice as long because I kept having to go back change my config for simple things such as denying the wrong IP subnet in my access list or applying the access list to the wrong interface. Tomorrow I plan on reviewing ACL administration and then moving on to the next chapter in the CCNA book!

I attached an image that shows the access list I created for this lab. Basically I wanted to block 192.168.2.0 subnet on the Mumbai_Backup Router from reaching the HewittInternet Routers address 10.1.1.1. I also wanted to block 192.168.3.0 subnet on the Mumbai_Back Router from reaching the other HewittInternet address of 10.1.2.1. I accomplished both goals while allowing all other IP's to reach all other locations in this network topology.

VLSM Lab

I have completed the second and final VLSM Lab for my CCNA review. Surprisingly everything went pretty smooth, I believe partly due to the fact that I've been slowing down and making sure my math is correct. This actually saves more time then rushing through subnetting then seeing that you messed up your addition somewhere which causes your entire network to fail. I finally finally finally figured out how to stop my console connections from timing and logging out after 10 minutes. I knew it would be simple but couldn't for the life of me figure out the command. So for all the people out there wondering what command it is here ya go:

Router(config)#line con 0
Router(config-line)#exec-timeout time (enter number of minutes where time is)

I haven't used telnetting sessions but I'm betting the command is the same besides logging into the vty.

The VLSM had a lot of parts to with of course the main part was figuring out over-lapping subnets and creating additional subnets within the current network. I honestly was expecting something a little harder because I was seeing the problems as I was labbing everything out. I think this is a sign that I am starting to have the CCNA fundamentals down and that I'm about ready to move onto the CCNP. The on the job experience I'm getting is great, it is especially helping me with my frame-relay knowledge as I was able to grasp the concepts again very easily this time around during some of my review labs. I'm learning a lot of WAN concepts, CCVP concepts, and technologies at my job; really good stuff even though some days we are absolutely busy the entire 12 hour shift.