Saturday, November 14, 2009

EIGRP CCNA Lab Review


I spent this morning creating a simple EIGRP lab and manipulating the bandwidth settings on the Yosemite interface to simulate FS routes on the network. I haven't ran into any real problems besides a subnet misconfiguration which was my fault. EIGRP is surprisingly simple but can become a little confusing due to the metric values it uses compared to the IOS metric values. I'm officially done with chapter 10 and I'll probably scan through chpt. 11 since it's just covering routing troubleshooting tips to use for the exam.

Friday, November 13, 2009

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.

Thursday, November 12, 2009

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!

Wednesday, November 11, 2009

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.

Sunday, November 8, 2009

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.

Friday, November 6, 2009

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!

Thursday, November 5, 2009

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.