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!