RIP Protocol and Floating Static Routes

Today I read up on topics related to the two different RIP versions 1 and 2 which was mostly review for me. There was some good stuff such as using both RIPv1 and RIPv2 on a network which i of course created a lab for. I also went over topics related to classful and classless routing over a network and how routing updates are summarized over Dis-contiguous or over different major classful networks. It was a good read and confirmed my suspicion that you can subnet within a classful network using RIPv1 as long as that subnet number is consistent throughout that network. However the network will still be summarized to a /16 when crossing major network boundaries.

I finished up today by learning about Floating Static Routes which was A LOT simpler then I imagined it to be. A floating static route is primarily used when a dynamic routing protocol fails or when you have a WAN link fail and would like to have an automatic fail-over route say through anISDN/DSL backup connection. A floating static route is configured by setting the administrative distance (AD) on a static route higher than the dynamic protocol (AD). By doing this the static route "floats" above the dynamic protocol since best routes when using mutli protocols uses AD to determine the best protocol to use. By default a static route has an AD of either 0 or 1 depending on the configuration. The higher the AD the less likely it is to be used over another protocol as indicated in the picture above.

Static Route and ODR Overview

Well today was my first real study session on CCNP, from the get go I could tell there is a higher level understanding needed if I'm going to pass this certification. The BSCI goes a lot deeper into routing than anything I've came across so far and just through the first few pages I already set up a few labs pertaining to the information I was reading. I went through setting up a simple static router network which was easy enough followed by setting up a static default lab which wasn't bad at all either. I then finished up by learning and creating a lab for On-Demand Routing (ODR) which is really a Cisco Prioperty way of setting up a cisco network by using CDP rather than a true Dynamic Routing Protocol or setting up Static Routes. All in all not to bad, I didn't get as much as I wanted done today because I came down with a cold and I'm sitting here hoping it doesn't turn into a fever or the flu. Tomorrow I am going to go over some RIP topics and labs which shouldn't be too bad hopefully but we'll see!

SDM Setup Through GNS3

I spent the past two days trying to setup SDM on a router on GNS3 but after several attempts I wasn't successful. I finally decided to use a real 3600 router at our NOC thinking that it was an issue with the GNS3 IOS's I was using (which it was). Before I began the upgrade I noticed that the router IOS version I was using was 12.2 and I needed at least the 12.4 version so I spent quite a bit of time scavenging cables, tftp software, and even a switch (didn't have a cross-over cable). FInally after I upgraded the IOS I noticed that one of the commands I needed to run on that router wouldn't work (ip http secure-server)! So finally I scratched using the real router idea and went back to square one. I ended up using the more appropriate 12.4 IOS I downloaded on my machine for GNS3 and sure enough everything installed. When I finally went to connect to my router through SDM I ran into one last little snag which was the Java applet itself. I would enter my credentials to log in but not much else would happen. After updating to the latest and greatest version everything came right up! Good experience all around just to at least say I know how to install SDM if needed and know what to look out for in the future.

I started and finsihed what I am sure the shortest and easiest CCNP chapter as well. I went through Chapter 1 which basically goes briefly into network design and some processes to think about and implement when trying to build a completely converged network with data, voice, video, security, and etc. all running on one network. It was a good read but now to get into the meat and potatoes of network engineering finally!

IPv6 CCNA Lab Review

Well this is my 50th blog posting and most likely my last posting on CCNA related material! From here on out most of my post will be related to CCNP topics for the most part. I finished up the last chapter in the CCNA book by going through the IPv6 material once again and labbing out a quick scenario on the topic. The configuration is a little different and thankfully there are some good work a round's to not having to type out and configure those long 128 bit addresses! Tomorrow I'll probably mess around with setting up SDM in GNS3 and finally finally finally move on to the CCNP material!

Connecting GNS3 to the Outside World!

Well I knew the time was coming to learn how to connect GNS3 to the outside world aka the internet or at least my computer. The reason for this is that for the CCNP BCMSN (Switching) exam, I could use GNS3 for my router devices and all I would have to do is buy a few switches and I would have a full BCMSN lab! Setting everything up in GNS3 to connect to the internet was just as hard as I expected it to be. I spent the better part of 5-6 hours troubleshooting and following video examples to get everything working. I didn't want to connect to the internet for now, I just wanted to be able to telnet from my PC to a GNS3 router.

To do this I had to create a loop back network card on my computer and set it up with an IP address. Next I had to setup GNS3 with a switch and a cloud that pointed to my loopback device. In retrospect I'm betting I could skip using a switch but hey I was just following instructions. Last but not least I had to configure my GNS3 routers with IP addresses on the respective interfaces that connected to that cloud and then I was good to go! As you see in the attached picture, I also setup Putty for telnetting and configuring routers from here on out.

Yesterday I actually went through the VPN chapter of the Cisco ICND2 book along with reading through the NAT Theory portion in this book. I'm going to hopefully finish up today with configuring some NAT Labs and then it'll only be 1 chapter left befor I offically begin the CCNP!

CCNA Partially Meshed Frame Relay Network Lab

Today I polished off the rest of my CCNA Frame-Relay review by completing the Partially Meshed Frame Relay Network Lab. All in all I think I finally have my head wrapped around most of the CCNA Frame-Relay concepts and I'm ready to move on to the last few chapters of my CCNA material! A partially meshed frame network is a Frame-Relay network in which some sites are fully meshed while others are only point-to-points. The thing that could trip you up the most is making sure you have all your PVC's configured correctly and that you configure the right type of interfaces for the right type of VC connections. Not to bad of a lab without to many hiccups besides my Router E I forgot to no shut the physical S0/0 interface but once I did that everything came right up. I used EIGRP for my routing call which seems to work fairly well with this type of network.

CCNA Fully Meshed Frame Relay Network Lab

I was a little bored this evening so I decided to get my hands dirty and try out a Fully-Meshed Frame Relay Network. It was actually a lot simple then I expected but I actually drew out a diagram before hand so i could picture in my head exactly how each VC was setup and with what DLCI. Something I have been kinda messing up is not using proper network design when creating my Frame-Relay networks. Previously I had been assigning the Point-to-Point Frame Relay router multiple DLC's that corresponded to each respective Point-to-Point link. I should have assigned one DLCI per DTE device but in my mind I could never picture how it worked so today I drew it out to help get my head wrapped around how it works.

DLCI's are locally significant between each DCE and DTE on a Frame Relay network. No other DTE knows what the other DTE use's as it's DLCI mapping to other DTE devices. So in this way you can logically have one DLCI mapping for every DTE so when configuring or reviewing the Frame-Relay network, it will be a lot easier to logically figure out which VC's go where. I actually managed to set everything up without any problems. The nice thing about LMI's is that the FR Switch (DCE) and the Router (DTE) sends LMI messages to each other that reports what DLCI's should be to reach the other DTE devices in the Frame Relay network. Each access link (DTE to DCE) reports LMI messages for their link but again the other access links could care less what DLCI's are setup for any other access links besides its own. As you can see in the GNS3 diagram I have setup this Fully-Meshed network with one IP subnet on the WAN connections and a VC between each device. I have also designed the network in such away that there is only one reported DLCI on each device!

Frame Relay CCNA Theory Review

Today I read the entire Frame Relay chapter 13 in the ICND2 book to review any topics I may have missed previously. Tomorrow I plan on creating labs for point-to-point, full-mesh, and partial mesh Frame Relay WAN's. I also started learning Linux on the side too, I created it in VMware and I'm using the Ubuntu Distro. Linux/Unix and telecommunications seems to go hand in hand so it's something I'm going to have to at least know my way around with.

PPP CCNA Review and Lab

Even though I'm only working on about 4 hours of sleep (out way to late last night) I managed to get through the rather simple PPP Chapter in the Cisco ICND2 book. The lab that the Cisco press book provides was rather simple and I decided to come up with my own real world scenario based on some of the WAN setups at my job. A lot of circuits actually use what's called a multilink which basically allows you to load-balance a WAN connection over multiple serial interfaces. I never setup a multilink before but seen it plenty of times when I have referenced running configs on routers. I decided to give this a whirl and ran into a few hiccups but managed to get everything running smoothly with one caveat. I never could get the RIP protocol to work across it for one reason or another, I believe it was due to using a classful network address on both routers. Even with the no auto-summary command I was still unable to get the two routers to exchange RIP info about their 172.16.0.0 /16 networks. I simply used OSPF and sure enough everything came right up, even though I misconfigured my multilink setup at first as well. When setting up a PPP multilink you don't put an IP address on the actual serial interfaces. Instead you create a virtual interface called multilinknumber in which you apply the ip address. You also need to add all the serial interfaces along with the multilink interface into what's called a multilink group. Once this is setup you should be ready to go, I've included what one of the router running configs looks like below:

I highlighted things of importance
R0#sh run
Building configuration...

Current configuration : 14
!
version 12.4
service timestamps debug d
service timestamps log dat
service password-encryptio
!
hostname R0
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$vn1e$JT
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
no ip domain lookup
ip auth-proxy max-nodata-c
ip admission max-nodata-co
!
multilink bundle-name auth
!

username R1 password 7 001
archive
log config
hidekeys
!
!
!
interface Loopback0
ip address 172.16.2.1 255
!
interface Multilink1
ip address 192.168.124.1
ppp authentication chap
ppp multilink
ppp multilink group 1
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0
no ip address
encapsulation ppp
clock rate 64000
ppp authentication chap
ppp multilink
ppp multilink group 1
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
encapsulation ppp
clock rate 64000
ppp authentication chap
ppp multilink
ppp multilink group 1
!
router ospf 1
log-adjacency-changes
network 172.16.0.0 0.0.25
network 192.168.124.0 0.0
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
control-plane
!
!

!
line con 0
exec-timeout 3000 0
password 7 00171E090B490E
login
line aux 0
line vty 0 4
login
!
!
end

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.

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.