Friday, November 27, 2009

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!

Tuesday, November 24, 2009

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!

Sunday, November 22, 2009

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!

Thursday, November 19, 2009

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.

Wednesday, November 18, 2009

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.

Sunday, November 15, 2009

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