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.

Manual Summarization CCNA Lab

I ended up creating my own Manual Summarization lab this morning going by the examples in the CCNA ICND2 book. I started with creating 5 routers with one side being in the 10.3.0.0 /16 network and the other side being in the 10.2.0.0 /16 network with a few subnets on both sides using the /24 mask. I used the EIGRP routing protocol for this lab this time instead of OSPF protocol. Once I had all my routers up and running, interfaces configured, and EIGRP setup I had to think about the best way to summarize the address on both sides. I started by giving the ip summary-address eigrp 1 10.2.0.0 255.255.0.0 and ip summary-address eigrp 1 10.3.0.0 255.255.0.0 command on both sides.

However this wasn't the best way to manually summarize these networks because I was summarizing networks that didn't actually exist similar to how auto-summarization works. I had to not only calculate a range that would summarize all of the existing subnets on both sides but also summarize the least amount of non existing networks as possible. After going through the manual summarization strategy I was able to summarize all the way down to 10.2.0.0 255.255.252.0 and 10.3.0.0 255.255.252.0 on both sides. This accomplished both goals of summarizing the existing subnets and summarizing the least amount of non existing networks as possible. I spent quite a bit of time doing this lab so I wasn't able to get to the VLSM Lab this week but I will finish it before I move on to the access-list chapters, all in all a good day!

VLSM-OSPF LAB

I've just finished reviewing some VLSM and even OSPF (unexpectedly) this evening. I am still getting use to all the quirks with GNS3 such as actually saving your lab correctly! This was a 5 router lab setup with multiple tasks such as figuring out if any subnets over lapped which of course they did. I also had to set OSPF in a specific way on each router. For example one task required me to set one router with the RID of 3.3.3.3 (I know easy stuff) and another task required me to set one routers interface in a different area. This was a pretty good lab and it was good because it got me to think about the path a packet takes when using OSPF and how routers uses its algorithm to determine this. I also went through some of the concepts regarding manipulating interface path costs that OSPF uses to determine a packets route. Tomorrow I'm doing another big VLSM lab and finishing up the chapter with manual route summarization review!

CCNA Static Routing Review

Today and yesterday I did a lot of configuring for a static route lab. Everything went pretty smooth and I'm glad I remembered most of the commands without having to refer to any documentation. I even got pretty detailed with Packet Tracer and laid it all out in a purrty picture as you see off to the side in this post! I also played around with a lab from the networking-forum.com website in regards to how RIPv1 routes IP's. Interestingly enough RIPv1 is smarter than what we give it credit for. You CAN route IP's that aren't a standard classful IP address and it is smart enough to determine the mask. However it will summarize the subnet if it's sent over a different class boundary, such as routing a class A address to a class C address, it will summarize the class A address before routing the packet. However if it's a class A network forwarding packets to another class A network it will know what the subnet mask is. Based on comparing it's IP network address to the other class A network addresses and will then take a best guess on what the subnet mask is.