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.