Lesson 10 -- Spanning Tree

As the company has grown, management has hired more employees, and your poor old 2924 switch finally ran out of ports. However, it's worked reasonably well, so you found another one on E-Bay, and installed it in your main office server rack. You connected an Ethernet patch cable from Fa0/1 on the first switch to Fa0/1 on the second switch, then copied the config using the same trick you used on the routers: copy the config to a TFTP server, modify just the lines that were different (like hostname and IP address) and download the new config onto the new hardware. You also hired a well-meaning, but very, very green assistant to help you with the IT work. He's enthusiastic, but...

Anyway, you leave for lunch one day, and when you return, you find your assistant -- we'll call him George for now -- in the server room, laptop connected through a console cable to the switch, and frowning in thought as he scratches his head.

"What's the matter, George?" you ask.

George shrugs, taking a few seconds to compose his thoughts before replying. "While you were at lunch, I received a phone call from the manager of Customer Service, who was asking if there was anything we could do to speed up the Internet for some of the new employees on the new 2924 switch we installed last week. They said access to the file server was kind of sluggish, too. So, I came in here to the server room and connected a second Ethernet cable between the two switches, but it didn't seem to make any difference. I see both ports are up, but I can't figure out why they aren't seeing any improvement in speed*."

You chuckle, then have George run a couple of commands on his laptop:

lab2924b# conf t
lab2924b(config-if)# int fast0/1
lab2924b(config-if)# shut
lab2924b(config-if)# no shut
lab2924b(config-if)# exit
lab2924b(config)# exit
lab2924b# sho span


Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
Bridge Identifier has priority 32768, address 00d0.58dd.d180
Configured hello time 2, max age 20, forward delay 15
Current root has priority 32768, address 0003.e3e4.f880
Root port is 13, cost of root path is 19
Topology change flag not set, detected flag not set, changes 2
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0


Interface Fa0/1 (port 13) in Spanning tree 1 is LISTENING
Port path cost 19, Port priority 128
Designated root has priority 32768, address 0003.e3e4.f880
Designated bridge has priority 32768, address 0003.e3e4.f880
Designated port is 13, path cost 0
Timers: message age 2, forward delay 0, hold 0
BPDU: sent 4, received 185
^C


George repeats the "sho span" a few times with the same results, then...:

lab2924b# sho span
<...snip...>
Interface Fa0/1 (port 13) in Spanning tree 1 is LEARNING
Port path cost 19, Port priority 128
Designated root has priority 32768, address 0003.e3e4.f880
Designated bridge has priority 32768, address 0003.e3e4.f880
Designated port is 13, path cost 0
Timers: message age 2, forward delay 11, hold 0
BPDU: sent 4, received 187
^C
lab2924b# sho span
<...snip...>
Interface Fa0/1 (port 13) in Spanning tree 1 is FORWARDING
Port path cost 19, Port priority 128
Designated root has priority 32768, address 0003.e3e4.f880
Designated bridge has priority 32768, address 0003.e3e4.f880
Designated port is 13, path cost 0
Timers: message age 1, forward delay 0, hold 0
BPDU: sent 5, received 194


George is thoroughly confused now. "What is with all of the 'listening,' 'learning' and 'forwarding' jazz?"

"Patience, grasshopper, and all will be explained. First run a few more commands..."

lab2924b# sho span int fa0/2
Interface Fa0/2 (port 14) in Spanning tree 1 is BLOCKING
Port path cost 19, Port priority 128
Designated root has priority 32768, address 0003.e3e4.f880
Designated bridge has priority 32768, address 0003.e3e4.f880
Designated port is 14, path cost 0
Timers: message age 1, forward delay 0, hold 0
BPDU: sent 1, received 4
^C


"You see, lucky for you, our switches are running a protocol called 'Spanning Tree.' Spanning tree is a way of making sure there are no loops when you connect multiple switches together. Suppose the switches were forwarding packets through both network interfaces where you've got the network cables connected. What would happen the first time a host on the network sent a Layer-2 broadcast message?"

George furrowed his brows. "I don't know, I guess."

"Think it through. Say my laptop on port 9 sends a broadcast. What does the 2924a switch do with that frame?"

"Oh, that's easy,?" George replied, brightening. "The switch will forward it out every port."

"Including port 1?" you ask.

Again George nods. "Yep."

"Which is connected to the 2924b switch," you add.

"Yep," George agrees again.

"And what does the 2924b switch do with the broadcast frame?"

"Since it's a broadcast, it sends it out every port except the one it received the frame on."

"Including port 2, where you connected the second Ethernet cable between the two switches?" you prompt.

The lightbulb of understanding finally fires in George's brain, and you suppress a laugh -- barely -- as his jaw suddenly falls to the floor. "Ohhhh..."

"Mmmm-hmmm."

"So the broadcast frame just continues to circle repeatedly between both switches, then."

"Exactly. It's called a 'broadcast storm' and, especially on older switches like these 2924's, it can bring your network to a screeching halt. It will easily max out the CPU on the switches so that you can't even log in to fix the problem. Sometimes the only way to stop a broadcast storm is to turn off one of the switches, or start pulling Ethernet cables until you see the switch start responding to telnet or pings again. Here is another command that is helpful for troubleshooting problems with Spanning Tree."

lab2924b# sho span brie
<...snip...>
Port                    Designated
Name Port ID Prio Cost Sts Cost Bridge ID Port ID
------- ------- ---- ---- --- ---- -------------- -------
Fa0/1 128.13 128 19 FWD 0 0003.e3e4.f880 128.13
Fa0/2 128.14 128 19 BLK 0 0003.e3e4.f880 128.14
Fa0/3 128.15 128 19 FWD 19 00d0.58dd.d180 128.15
Fa0/4 128.16 128 19 BLK 19 00d0.58dd.d180 128.16
Fa0/5 128.17 128 19 BLK 19 00d0.58dd.d180 128.17
Fa0/6 128.18 128 19 BLK 19 00d0.58dd.d180 128.18
Fa0/20 128.34 128 19 BLK 19 00d0.58dd.d180 128.34
Fa0/21 128.35 128 19 BLK 19 00d0.58dd.d180 128.35
Fa0/22 128.36 128 19 BLK 19 00d0.58dd.d180 128.36
Fa0/23 128.37 128 19 BLK 19 00d0.58dd.d180 128.37
<...snip...>


"This shows you which ports are forwarding, shown as 'FWD' or blocking, shown as 'BLK.' Now let's see what we can do to troubleshoot that bandwidth problem..."

Post-Script: Lest you think that this is an exaggerated tale, yes, this really happened to me. I was working for a service provider at the time, and a network admin working for one of my customers -- also a service provider -- called at the very end of the business day to request that I turn up a second port on one of my switches in a Metro Ethernet ring. The alarm bells went off in my head, but I foolishly ignored them, and, rather than inquiring about his plans for a second port on the same switch, I simply turned the port up and called it a day. When I returned to work the following day, I had a series of messages in my voice mail, wondering if I had turned the port up, if I had configured it properly, etc. I called my peer at the other service provider back, and started troubleshooting the problem with him. I finally figured out that he was trying to configure a redundant port between his switch and my switch, and really had to suppress a laugh when he admitted that he couldn't figure out why his port was going down when he plugged in his network cable. "Ummm...spanning tree?" I prompted as gently as I could. "Oh..." was his reply.

Lesson 9 -- VLANs and Cisco's Insistence on Using Incorrect Terminology

As the company has grown, so has the use of network resources. In particular, there has been a dramatic increase in broadcast traffic, due to the use of some very chatty applications on a number of new servers. Having spent the better part of a full day sniffing network traffic with Wireshark, you have come to the conclusion that it's time to start segregating your users on the network.

You briefly consider the idea of installing separate switches in each department, but that seems like overkill. Every switch port on the 2924 switch is full, but HR assures you that the mad hiring rush is over for now, and your boss tells you that you don't have enough money left in the budget to install separate switches for every department. Nevertheless, you can't help but think that it would be nice to put each department into its own Local Area Network. Fortunately, you realize that your 2924 has the ability to create separate logical networks, even if they share the same physical hardware. Even better, this modification is something you can do without leaving your office -- there's no need for you to run new cables or install any new hardware. Best of all, this upgrade to the network will allow you to quickly and easily move users to different logical networks, if they should change positions within the company, whether or not they change offices. The logical networking that allows you this incredible flexibility is known as "virtual LANs", or "VLANs." On Cisco equipment, there are two types of VLANs that you can create -- a Cisco proprietary VLAN through a protocol called "ISL" and a standards-compliant protocol known by the obscure moniker "802.1q." Knowing that some day, you might need to incorporate non-Cisco equipment in your network, you decide to use the 802.1q protocol in your VLAN implementation.

One other thing to consider is what Cisco calls "access ports" and "trunked ports" (grrr...). This is a bit of a pet peeve of mine, since pretty much every other vendor on the planet calls them "untagged" and "tagged" ports, respectively. "Trunk" ports -- to seemingly everyone but Cisco -- is when you bind two or more Ethernet ports together for greater reliability and/or greater bandwidth. For example, you could trunk two 100Mbps Ethernet ports together to have a single 200Mbps channel. This is also sometimes called "Link Aggregate Groups" or "LAG." LAG is beyond the scope of this particular article, but we will get to it a little later. You can tell the switch that all traffic coming in on a particular port will belong to one particular VLAN (untagged, or access ports), or you can tell the switch to expect a tag in the Layer-2 frame header (tagged or trunk ports). This tag will tell the switch which VLAN that particular frame should belong to. If you are using untagged VLANs on a particular port, then in essence, you have told the switch that all traffic coming in on that port belongs to one and only one VLAN. Think about it -- how would the switch know how to route traffic to different VLANs if all of the traffic is untagged? On the other hand, if you are using tagged frames on a particular port, then the switch can differentiate between all the of VLANs that you can configure on the switch. (Actually, that isn't strictly true. You can also create a hybrid port, where all tagged traffic will go to the VLAN that is tagged on the frame, but all untagged traffic will default into one, specific, other VLAN.)

Two last things to consider before we set up the VLANs. First, each VLAN is a separate network, so hosts on each VLAN cannot talk to each other without passing through a router. Second, since each VLAN is a separate network, each VLAN will have its own IP addressing scheme, and you will need to configure the router with IP addresses on virtual sub-interfaces to route between the VLANs.

To build this logical separation between groups, you log in to your main office router using a console cable (you will lock yourself out of the router before you complete the configuration, if you attempt this through telnet or SSH). Then, you run the following commands:

lab2651rtr# conf t
lan2651rtr(config)# no ip dhcp excluded-address 192.168.1.1 192.168.1.31
lan2651rtr(config)# no ip dhcp pool LANPOOL
lan2651rtr(config)# ip dhcp excluded-address 192.168.1.65
lan2651rtr(config)# ip dhcp excluded-address 192.168.1.81
lan2651rtr(config)# ip dhcp excluded-address 192.168.1.97
lan2651rtr(config)# ip dhcp excluded-address 192.168.1.113
lan2651rtr(config)# ip dhcp excluded-address 192.168.1.129 lab2651rtr(config)# ip dhcp pool IT
lab2651rtr(dhcp-config)# network 192.168.1.64 255.255.255.240
lab2651rtr(dhcp-config)# dns-server 192.168.1.35
lab2651rtr(dhcp-config)# default-router 192.168.1.65
lab2651rtr(dhcp-config)# domain-name mis.example.com
lab2651rtr(dhcp-config)# lease 0 6 0
lab2651rtr(config)# ip dhcp pool Exec
lab2651rtr(dhcp-config)# network 192.168.1.80 255.255.255.240
lab2651rtr(dhcp-config)# dns-server 192.168.1.35
lab2651rtr(dhcp-config)# default-router 192.168.1.81
lab2651rtr(dhcp-config)# domain-name exec.example.com
lab2651rtr(dhcp-config)# lease 0 6 0
lab2651rtr(config)# ip dhcp pool Acct
lab2651rtr(dhcp-config)# network 192.168.1.96 255.255.255.240
lab2651rtr(dhcp-config)# dns-server 192.168.1.35
lab2651rtr(dhcp-config)# default-router 192.168.1.97
lab2651rtr(dhcp-config)# domain-name acct.example.com
lab2651rtr(dhcp-config)# lease 0 6 0
lab2651rtr(config)# ip dhcp pool Sales
lab2651rtr(dhcp-config)# network 192.168.1.112 255.255.255.240
lab2651rtr(dhcp-config)# dns-server 192.168.1.35
lab2651rtr(dhcp-config)# default-router 192.168.1.113
lab2651rtr(dhcp-config)# domain-name sales.example.com
lab2651rtr(dhcp-config)# lease 0 6 0
lab2651rtr(config)# ip dhcp pool CustServ
lab2651rtr(dhcp-config)# network 192.168.1.128 255.255.255.224
lab2651rtr(dhcp-config)# dns-server 192.168.1.35
lab2651rtr(dhcp-config)# default-router 192.168.1.129
lab2651rtr(dhcp-config)# domain-name custserv.example.com
lab2651rtr(dhcp-config)# lease 0 6 0
lab2651rtr(config)# int fast 0/0
lab2651rtr(config-if)# no ip address
lab2651rtr(config-if)# no ip nat inside
lab2651rtr(config-if)# description Physical LAN port
lab2651rtr(config-if)# int fa0/0.1
lab2651rtr(config-subif)# encapsulation dot1q 1
lab2651rtr(config-subif)# description NetMgmt
lab2651rtr(config-subif)# ip address 192.168.1.1 255.255.255.224
lab2651rtr(config-subif)# int fa0/0.2
lab2651rtr(config-subif)# encapsulation dot1q 2
lab2651rtr(config-subif)# description Server Farm
lab2651rtr(config-subif)# ip address 192.168.1.33 255.255.255.224
lab2651rtr(config-subif)# ip nat inside
lab2651rtr(config-subif)# int fa0/0.3
lab2651rtr(config-subif)# encapsulation dot1q 3
lab2651rtr(config-subif)# description IT
lab2651rtr(config-subif)# ip address 192.168.1.65 255.255.255.240
lab2651rtr(config-subif)# ip nat inside
lab2651rtr(config-subif)# int fa0/0.4
lab2651rtr(config-subif)# encapsulation dot1q 4
lab2651rtr(config-subif)# description Exec
lab2651rtr(config-subif)# ip address 192.168.1.81 255.255.255.240
lab2651rtr(config-subif)# ip nat inside
lab2651rtr(config-subif)# int fa0/0.5
lab2651rtr(config-subif)# encapsulation dot1q 5
lab2651rtr(config-subif)# description Acct
lab2651rtr(config-subif)# ip address 192.168.1.97 255.255.255.240
lab2651rtr(config-subif)# ip nat inside
lab2651rtr(config-subif)# int fa0/0.6
lab2651rtr(config-subif)# encapsulation dot1q 6
lab2651rtr(config-subif)# description Sales
lab2651rtr(config-subif)# ip address 192.168.1.113 255.255.255.240
lab2651rtr(config-subif)# ip nat inside
lab2651rtr(config-subif)# int fa0/0.7
lab2651rtr(config-subif)# encapsulation dot1q 7
lab2651rtr(config-subif)# description CustService
lab2651rtr(config-subif)# ip address 192.168.1.129 255.255.255.224
lab2651rtr(config-subif)# ip nat inside
lab2651rtr(config-subif)# exit
lab2651rtr(config)#

The only new thing in this config is configuring the sub-interfaces under fa0/0. The name of each sub-interface is derived from the physical interface upon which they are connected (fa0/0, in this case), and the VLAN number to which they are assigned. For example, VLAN 1 on fa0/0 would be fa0/0.1, VLAN 2 would be fa0/0.2, and so on. Next, we have to tell the router to encapsulate the VLANs using the 802.1q protocol. We have subnetted the 192.168.1.0/24 network into multiple subnets, with the size of the subnet determined by the expected number of hosts in each group. We have 30 hosts each in the network management subnet (probably gross overkill, but <shrug>), the server farm and in Customer Service, and 14 hosts each in IT, Accounting, Executive and Sales. Since we are still NAT'ing to the Internet, we have moved the "ip nat inside"statement to each sub-interface (except for the network management subnet, which I don't want accessible from the Internet, for security reasons).

Now, we need to configure the switch. The changes are rather long, since we are configuring 24 network ports, so instead of pasting the entire config here, I'll link to it here, and we'll just cover the highlights below. Basically, we need to configure network ports for two types of services -- trunked ports to the router(s), and access ports to users' workstations. One example of a trunked port is the uplink to the router:

interface FastEthernet0/3
description Network Mgmt
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-7,1002-1005
switchport mode trunk


I am hard-coding the speed and duplex because I have seen...oddities...in the behaviour of Cisco routers (in particular) when you try to auto-negotiate speed and duplex, particularly in their lower-end routers (2500 series, 2600 series and 2800 series). It is important to be sure that your router and switch have the same settings, since "auto-negotiate" doesn't mean exactly what you think it means, if one side is hard-coded and the other side is negotiating speed and duplex. The speed will match up (the auto side will detect and match the carrier frequency on the wire), but the auto side will default to half-duplex if the other side isn't auto-negotiating also. The tell-tale sign of this is a large number of CRC errors on the network interface. If one side is hard-coded to 10M and the other side is hard-coded to 100M, however, the port will show down when you show the interface.

After setting speed and duplex to 100M-Full, I am telling the switch that I want to use 802.1q encapsulation, just as I did on the router. This is important -- make sure both connected devices are using the same VLAN protocol. If one device is NOT a Cisco device, you will have to use 802.1q rather than ISL (which is why I prefer to go with 802.1q regardless).

Next, I set the VLANs that I am allowing on the interface. I really only wanted VLAN 1-7 (because all hosts on the LAN need to talk to the router for Internet access), but as the Cisco switch supports Token Ring and FDDI interfaces (at least in software), Cisco, in their infinite wisdom (!) has decided that 1) Ethernet uses VLAN 1 as the managment/native VLAN and VLANs 1002-1005 for the native/management VLANs for other physical media; and 2) you cannot remove the native/management VLANs from trunked ports, even in physical topologies that you aren't using (although you can reassign the native VLANs to other, more convenient numbers, if you so choose). Therefore, if you create a trunked port, you will ALWAYS see VLAN 1 and VLANs 1002-1005 on that port. Whatever.

Finally, I am telling the switch that I want to make FA0/3 a trunked VLAN port.

However, on FA0/7, I have created an access (untagged) port for the server farm to connect to. The config for this interface looks a little different:

interface FastEthernet0/7
description Server Farm
switchport access vlan 2


The Cisco switch uses access ports by default, so all I have to do is tell the switch to use VLAN 2 (server farm) on this port, rather than the default VLAN 1 (network management VLAN). Pretty simple, right? Remember, with a tagged/trunked VLAN port, traffic will be directed to the appropriate network based up tag; with an untagged/access port, any traffic entering a particular port will be directed towards the appropriate network.

Once you've got the configs in place on your equipment, make sure hosts on each of the VLANs can route to each other, as well as to the router. If something isn't working, don't give up -- you'll learn a lot more by troubleshooting and fixing problems than you will by copying and pasting configs! (In fact, while I was able to create the other labs in this series so far in a matter of an hour or two, I found configuring this lab -- since I still don't have access to the console port on my switches -- a lot trickier, taking about 18 hours to design and configure, most of which was troubleshooting). If you do need to troubleshoot, you'll find the "show vlan", "show vlan brief" and "show vlan id <VLAN ID Number>" commands very helpful. Good luck!

Lesson 8 -- Dynamic Routing with EIGRP

Later in the week, your boss calls you to ask about another dynamic routing protocol known as EIGRP. She explains that she read that EIGRP is a Cisco proprietary routing protocol, and since we are using Cisco equipment, wouldn't it be best to use the routing protocol that Cisco designed for their routers? Also, she continues, the article said that EIGRP allows the network admin to configure authentication between routers, which can help keep malicious hackers from injecting bogus routes into your routing tables. You try to tell her that while that's true, you are only sending and receiving route updates across a point-to-point link on a private, leased line -- there's no way for a miscreant to inject a route into your routing tables unless they have physical access to your T1 line, but she tells you that she thinks you should remove OSPF and move to EIGRP, anyway. You roll your eyes (you're on the phone, after all), and agree to give it a try, silently fantasizing about shutting off her Internet access so you can stop reconfiguring your routers every time she reads a new article on-line.

Once again, you log into the main office and branch office routers, remove OSPF and configure EIGRP:

lab2651rtr# conf t
lab2651rtr(config)# no router ospf 2112
lab2651rtr(config)# router eigrp 42
lab2651rtr(config-router)# network 192.168.3.4 0.0.0.3
lab2651rtr(config-router)# redistribute connected
lab2651rtr(config-router)# redistribute static
lab2651rtr(config-router)# no auto-summary
lab2651rtr(config-router)# key chain EIGRP
lab2651rtr(config-keychain)# key 1
lab2651r(config-keychain-key)# key-string +h@nks_4_+he_f!sh
lab2651r(config-keychain-key)# int serial 0/1
lab2651rtr(config-if)# ip authentication mode eigrp 1 md5
lab2651rtr(config-if)# ip authentication key-chain eigrp 1 EIGRP
lab2651rtr(config-if)# exit
lab2651rtr(config)# exit
lab2651rtr#


...and on the branch office router:

lab3640rtr# conf t
lab3640rtr(config)# no router ospf 2112
lab3640rtr(config)# router eigrp 42
lab3640rtr(config-router)# network 192.168.3.4 0.0.0.3
lab3640rtr(config-router)# redistribute connected
lab3640rtr(config-router)# no auto-summary
lab3640rtr(config-router)# key chain EIGRP
lab3640rtr(config-keychain)# key 1
lab3640r(config-keychain-key)# key-string +h@nks_4_+he_f!sh
lab3640r(config-keychain-key)# int serial 0/1
lab3640rtr(config-if)# ip authentication mode eigrp 1 md5
lab3640rtr(config-if)# ip authentication key-chain eigrp 1 EIGRP
lab3640rtr(config-if)# exit
lab3640rtr(config)# exit
lab3640rtr#


Hmmm...EIGRP looks a little more complex, but a lot of the commands look similar to the other routing protocols we've used. Let's discuss the commands in detail:
* First, we tell the router that we want to use EIGRP, just like we did with RIP and OSPF. However, the "42" is not an EIGRP process number, like we saw with OSPF. EIGRP uses "Autonomous Systems" and and they must match between routers that are sharing routes through EIGRP!
* Again, we tell the router what networks to advertise with the "network" statement, very similar to the "network" statements found in RIP and OSPF, but what looks sort of like a subnet mask following the network address is actually a "wildcard mask." Logically, if you convert the subnet mask to binary (in this case, 11111111.11111111.11111111.11111100), then invert the ones and zeros (00000000.00000000.00000000.00000011), then convert back to decimal, that's a "wildcard mask." Or, you can just subtract each octet of the subnet mask from 255, like a normal (i.e., lazy) person ;)
* The "redistribute connected" command is identical to the same command in OSPF.
* The "no auto-summary" command tells EIGRP not to collapse classless subnets into a single classful network address.
* From here on, configuring EIGRP becomes very different from what we've done previously. On the plus side, the authentication configuration is entirely optional -- you don't have to configure authentication if you don't want to, but if you do, here's how you do it. First, we will store the password in a "key chain" (a database of passwords). Since there can be multiple key chains, we have to tell the router which one to use. In this case, we called it, logically enough, "EIGRP." The number we use in the "key" command must match between routers sharing routes through EIGRP. Next, we configure the password to be used by the two routers to authenticate with each other, using the "key-string" command. After that, we have to apply the authentication mechanism to a specific interface, in this case, serial 0/1 on both routers. Inside the interface configuration, we set the authentication mode (authentication is for the EIGRP routing protocol, using key 1, and it will be encrypted with the MD5 algorithm. Finally, we state that we are using key 1 (again) from the EIGRP key chain.

Whew...glad we've got that configured. Make sure the settings match on both routers, or else the routers won't be able to share routes. If anything doesn't match, fix it now, then check your work:

lab2651rtr# sho ip route
<...snip...there are a lot of extra lines of output that aren't needed now...>
Gateway of last resort is 100.64.1.1 to network 0.0.0.0

     100.0.0.0/24 is subnetted, 1 subnets
C     100.64.1.0 is directly connected, FastEthernet0/1
C     192.168.1.0/24 is directly connected, FastEthernet0/0
      192.168.3.0/30 is subnetted, 1 subnets
C     192.168.3.4 is directly connected, Serial0/1
S*     0.0.0.0/0 [1/0] via 100.64.1.1


Wait...what? Where's the 192.168.2.0/24 subnet?

lab2651rtr# sho ip eigrp topology
IP-EIGRP Topology Table for AS(42)/ID(192.168.3.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
     r - reply Status, s - sia Status
P 0.0.0.0/0, 1 successors, FD is 281600
     via Rstatic (281600/0)
P 100.64.1.0/24, 1 successors, FD is 281600
     via Rconnected (281600/0)
P 192.168.1.0/24, 1 successors, FD is 28160
     via Rconnected (28160/0)
P 192.168.3.4/30, 1 successors, FD is 2169856
     via Connected, Serial0/1
lab2651rtr#


The configuration looks good, and on the branch office router, I can see routes shared by the main office router:

lab3640rtr# sho ip route
<...snip...>
Gateway of last resort is 192.168.3.5 to network 0.0.0.0

     100.0.0.0/24 is subnetted, 1 subnets
D EX     100.64.1.0 [170/2195456] via 192.168.3.5, 00:50:24, Serial0/1
D EX 192.168.1.0/24 [170/2172416] via 192.168.3.5, 00:50:24, Serial0/1
     192.168.3.0/30 is subnetted, 1 subnets
C     192.168.3.4 is directly connected, Serial0/1
D*EX 0.0.0.0/0 [170/2195456] via 192.168.3.5, 00:50:21, Serial0/1
lab3640rtr#


That tells me that whatever is wrong, it isn't an EIGRP problem -- routes from the main office router are showing up on the branch office router. You glance at your watch, and suddenly realize what the problem is. It's two hours after quitting time. Everyone at the branch office had gone home for the night, and all their PCs were shut off. With nothing connected to FA0/0 on the branch office router, the interface had gone down, and therefore EIGRP wasn't propagating any routes to the 192.168.2.0/24 subnet. You go home for the night, and check again the next morning. Sure enough, you can see the 192.168.2.0/24 subnet on the main office router's routing tables.

Lesson 7 -- Dynamic Routing with OSPF

Your boss was reading a trade magazine over the weekend, and on Monday morning, mentions to you that she had read an article about another routing protocol known as OSPF. She says that the article claimed that OSPF was a much better protocol than RIP, since it uses some more efficient metrics to calculate routes and is less "chatty" than RIP. You agree that these statements are probably true, but state that, on a network the size of the one you maintain, the differences between RIP and OSPF are probably irrelevant. Nevertheless, your boss strongly suggests that you should (no pun intended) rip RIP out of the configs and replace it with OSPF. You shrug, and agree to make the change. First, you log into the remote router, remove RIP, and configure OSPF:

lab3640rtr# conf t
lab3640rtr(config)# router ospf 2112
lab3640rtr(config-router)# router-id 192.168.3.6
lab3640rtr(config-router)# network 192.168.3.4 255.255.255.0 area 0
lab3640rtr(config-router)# redistribute connected
lab3640rtr(config-router)# exit
lab3640rtr(config)# exit
lab3640rtr#


...and on the main office router:

lab2651rtr(config)#no router rip
lab2651rtr(config)#router ospf 2112
lab2651rtr(config-router)#router-id 192.168.3.5
lab2651rtr(config-router)#network 192.168.3.4 255.255.255.0 area 0
lab2651rtr(config-router)#redistribute connected
lab2651rtr(config-router)#redistribute static
lab2651rtr(config-router)#exit
lab2651rtr(config)#exit
lab2651rtr#


Here's what we did:
* Tell the router to stop the RIP routing process.
* Tell the router to start the OSPF routing process. It is possible to run multiple OSPF processes on a single router, so when starting an OSPF process, you must supply it with a process ID. The process ID is entirely arbitrary -- it contains no particular significance, except that it must be unique for every instance of OSPF running on any given router.
* The OSPF routing process must be able to identify itself with other OSPF-enabled routers, so you must give it a router ID, in the format of an IP address. Again, this is somewhat arbitrary, but it must be unique on the OSPF area, so common practice is to assign one of the IP address on the router itself as the router ID, as it is unlikely that another router in the same OSPF area will have the same IP address (barring interconnected routers NAT'ing RFC-1918 LANs and using the same private IP address for each LAN, in which case, you should use one of the routed IP addresses on the router). The rest of the config is very similar to the RIP configuration, except that the "network..." statements are a little more complex. OSPF is a classless protocol, so you need to provide the subnet mask as well as the network of the address through which OSPF will be sending routing advertisements. Also, there's the "area 0" clause at the end of the network statement. To greatly oversimplify, keep the OSPF areas consistent between routers that should be sharing routes. For a more detailed explanation of OSPF areas, follow the Cisco.com link above.

Once again, test connectivity between hosts on the branch office network and the main office network. If things aren't working, start troubleshooting with the "sho ip route" command, and double-check the config statements in your running configuration. Another valuable tool is the "show ip ospf neighbor" command. When two routers share routes through OSPF, they create what is called a "neighbor" relationship. If you don't see the "neighbor" router in the output of the "sho ip ospf neighbor" command, then you have some troubleshooting to do. Make sure you are advertising OSPF out the correct interface(s). Make sure the OSPF areas are configured consistently. Make sure that the link between the two routers is up. Also, be patient. If you dig into more advanced OSPF configuration, you will see a number of timers that control how often OSPF sends updates to neighbor routers. It can take a minute or two for OSPF to converge, so if you don't see the neighbor relationship right away, wait a minute or two, then check again.

Lesson 6 -- Dynamic Routing with RIP and RIPv2

The branch office is now connected to the main office, and the routers can successfully communicate with each other. Unfortunately, there's a problem, however. After getting the two routers connected, you called it a night, but the next morning, the branch office manager called you to say that none of the users in the office could connect to any of the corporate servers in the main office. You gave the branch office manager your word that you'd get the problem solved right away, but first you've got to figure out what's wrong. You fire up your laptop and start pecking away at the keyboard:

me@myllt:~$ traceroute 192.168.2.32
traceroute to 192.168.2.32 (192.168.2.32), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.337 ms 2.577 ms 2.918 ms
2 100.64.1.1 (100.64.1.1) 32.245 ms 31.087 ms 32.500 ms
3 * * *
4 * * *
5 * * *
6 * * *^C
me@myllt:~$


It looks like you can reach your router like you should, but why is your router connecting your ISP's router to reach a host in the branch office? To reach the branch office, your router should be directing traffic to the T1 line, not to the Internet.

Let's take a moment here to go over a basic concept that you will need to understand if you want to be a network admin: the purpose of a router is to route (natch!) traffic appropriately. In other words, a router works very much like an old-fashioned traffic cop, directing cars through an intersection. When a car (a packet) arrives at the intersection (a network interface), the traffic cop (the router) looks at the lane position and turn signals (the destination address and routing tables), and then directs the car (the packet) towards the proper lane (outbound interface). However, routers are just electronic devices; they aren't omniscient. With an exception that I'll discuss in just a minute, routers only know how to reach networks that either are directly connected to them, or that you have explicitly told them how to reach. Therefore, the easy solution is to log in to your router and type these commands...:

lab2651rtr# conf t
lab2651rtr(config)# ip route 192.168.2.0 255.255.255.0 192.168.3.6
lab2651rtr(config)# exit
lab2651rtr#


...then try the traceroute command again:

me@myllt:~$ traceroute 192.168.2.32
traceroute to 192.168.2.32 (192.168.2.32), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.047 ms 2.453 ms 3.199 ms
2 192.168.3.6 (192.168.3.6) 2.840 ms 3.697 ms 6.029 ms
3 192.168.2.32 (192.168.2.32) 3.169 ms 4.166 ms 4.522 ms
me@myllt:~$


That's better! However, what happens if you have to add another branch office? You'll need to add another static route to and from the main office, and if the two branch offices need to communicate with each other, too, then you'll need to add two more static routes on each router. If you keep following this train of thought, you'll soon realize that continuously adding static routes for every new branch office can quickly become unmanageable.

Fortunately, there is a better solution. Routers have the ability to create routes between connected devices automatically, if you enable the feature. This is called "dynamic routing" and the standards that have been established to allow interconnected routers to do this are collectively known as "dynamic routing protocols." One of the dynamic routing protocols that is easiest to understand and configure is known as "RIP" -- "Routing Information Protocol." I won't spend much time describing how RIP works -- again, there are plenty of on-line resources that explain the idea behind RIP (and you should probably spend at least a little time reading them, if you want to pass the CCNA) -- but instead, we'll dive right into configuring it. First, remove the static routes between the main office router and the branch office router:

lab2651rtr# sho run | inc route
default-router 192.168.1.1
ip route 0.0.0.0 0.0.0.0 100.64.1.1
ip route 192.168.2.0 255.255.255.0 192.168.3.6
lab2651rtr# conf t
lab2651rtr(config)# no ip route 192.168.2.0 255.255.255.0 192.168.3.6
lab2651rtr(config)#


...and...:

lab3640rtr# sho run | inc route
default-router 192.168.2.1
ip route 0.0.0.0 0.0.0.0 192.168.3.5
lab3640rtr# conf t
lab3640rtr(config)# no ip route 0.0.0.0 0.0.0.0 192.168.3.5
lab3640rtr(config)#


If you aren't familiar with the line that begins "sho run", basically all I'm doing is telling the router to show me the current configuration ("sho run"), and then I'm telling it to filter ("|") the output by including only the lines that contain the word "route." If you would like, spend a little time playing with the command until you understand what it's doing. For example, try running "sho ip int brie | inc Serial" or "sho run | inc password" There are other filters available, too, such as "sho run | begin interface" which can really help you out when troubleshooting problems.

Back to the configuration...If you try to traceroute to the branch office at his point, the traceroute should fail because the routers no longer know how to reach the internal networks on the other router. Let's fix that problem, shall we?

lab3640rtr(config)# router rip
lab3640rtr(config-router)# version 2
lab3640rtr(config-router)# network 192.168.3.4
lab3640rtr(config-router)# redistribute connected
lab3640rtr(config-router)# exit
lab3640rtr(config)# exit
lab3640rtr#


...and on the main office router:

lab2651rtr(config)# router rip
lab2651rtr(config-router)# version 2
lab2651rtr(config-router)# network 192.168.3.4
lab2651rtr(config-router)# redistribute connected
lab2651rtr(config-router)# redistribute static
lab2651rtr(config-router)# passive-interface fa0/1
lab2651rtr(config-router)# exit
lab2651rtr(config)# exit
lab2651rtr#


This should establish routing between the two routers. Here's what the commands do:
* First, we tell the router to start the RIP routing process with the "router rip" command.
* Next, we tell the router that we want to use RIP version 2. The original version of RIP was classful, meaning that it didn't understand subnetting. Version 2 introduced classless networks into RIP, and since we are using /30 addresses on the point-to-point serial link, it would be best if we used the version of RIP that supports classless networks.
* We tell RIP that we want it to send and receive router advertisements on the network interface that hosts the 192.168.3.4 network. We don't list the LAN networks (192.168.1.0 and 192.168.2.0) because they are "network stubs." There are no other routers on the LAN networks to send or receive RIP advertisements on those networks, so there is no reason to send or receive an advertisement out the LAN interface.
* Next, we tell the router that when it sends a route advertisement, we want it to include the routes to all of the networks directly connected to one of its network interfaces ("redistribute connected").
* On the main office router, we tell RIP to redistribute static routes also (so that branch office users can reach the Internet).
* Finally, also on the main office router, we tell RIP not to send route advertisements to the ISP. They don't care about routes on our internal network, and even if they did, RIP probably wouldn't be the best choice for a number of reasons that are beyond the scope of this discussion. Just take my word for it that, as of the date that I am writing this, BGP ("Border Gateway Protocol") is the routing protocol of choice for peering with service providers. Note: this command probably isn't strictly necessary, since we are only telling the routers to advertise across the serial interface, but I am including it anyway, just to prevent a typo in the future from suddenly sending advertisements to RFC-1918 IP space to our upstream provider. They should, in theory, be filtering RFC-1918 addresses out of their route advertisements, but...

Now that RIP has been configured on the two routers, hosts from the main office and the branch office should be able to reach each other. If not, then it's time to get familiar with two new Cisco commands, "sho ip route" and "sho ip rip database." "sho ip route" does exactly that -- it shows you the routes that your router "knows" about, and "sho ip rip database" shows you what networks are stored in the RIP database, and what path you would take to reach those networks.

Lesson 5 -- WAN Connections

Thanks to the amazing job you've done on your company's network, the company is growing by leaps and bounds. The company has just opened a new branch office in another location, and you have been tasked with setting up a second router with a leased line to connect the remote office to the main office. Create a static route from the main office to the branch office so that employees' desktops and laptops at the new branch office can communicate with the desktops, laptops and servers at the main office, and also set up NAT so the branch office can reach the Internet, too. We'll tackle the project in steps, starting with configuring the serial ports between the two routers.

First, a basic config on the new router. You could type in all of the commands by hand, but...well, as a former co-worker once told me, "The best sys admins are LAZY sys admins." Don't take that wrong -- I'm not encouraging an attitude of slacking off, doing no more than what your boss requires that you do, or anything like that. Rather, I'm saying the best sys admins are the ones who look for ways of automating tedious problems. Think proactive, rather than reactive, and you'll be on the right track. In this case, rather than create a whole new configuration from scratch, just re-use and modify your config from the main office router:

lab2651rtr# copy run tftp
Address or name of remote host []? 192.168.1.32
Destination filename [lab2651rtr-confg]? lab2651rtrNatDhcp-confg
!!
1798 bytes copied in 0.361 secs (4981 bytes/sec)
lab2651rtr#


This requires that you have a TFTP server running on a host on your network. Again, most -- if not all -- *Nix operating systems will have a package to provide TFTP services. In fact, on a Linux or FreeBSD box, TFTP may already be installed and waiting to be started by Inetd or Xinetd. For Windows, a company called "Klever Group" makes a pretty good TFTP client and server called "Pumpkin." A complete discussion of installing and configuring TFTP is beyond the scope of this article, but there are plenty of resources on Google to help you with the process. Note: I said that the "lazy" route was to copy, modify and re-use your old config. Setting up a TFTP server so that you can copy the config to a PC may seem like a lot of work to be "lazy," but trust me -- you'll be using the TFTP server a lot. Getting it running now really will save you a lot of time and effort before we are done with the CCNA.

Okay, you've got your TFTP server running, and you've copied the config to a PC. Open the config file with your favorite editor, and make the following changes:
* Change the hostname on the router;
* Change all occurrences of 192.168.1.1 255.255.255.0 to 192.168.2.1 255.255.255.0;
* Remove all of the NAT configs;
* Change the default route from 100.64.1.1 to 192.168.3.5;

Once that's done, save the modified config file to your TFTP server, create a temporary IP address on your new router, connect your PC to the new router and copy the config back to your new router: lab3640rtr#copy tftp start
Address or name of remote host []?192.168.1.32
Source filename [/tftpboot/lab3640rtrDhcp-confg]?
Destination filename [startup-config]?
Accessing tftp://192.168.1.32//tftpboot/lab3640rtrDhcp-confg...
Loading /tftpboot/lab3640rtrDhcp-confg from 192.168.1.32 (via Serial0/1): !
[OK - 1436/2048 bytes]
[OK]
1436 bytes copied in 0.348 secs
lab3640rtr#


Reload the router, then once it has come back on-line, add the serial port:

lab3640rtr# conf t
lab3640rtr(config)# int serial 0/1
lab3640rtr(config-if)# description T1 to lab2651rtr
lab3640rtr(config-if)# bandwidth 1544
lab3640rtr(config-if)# ip address 192.168.3.6 255.255.255.252
lab3640rtr(config-if)# no shut
lab3640rtr(config-if)# exit
lab3640rtr(config)# exit
lab3640rtr#


...and on the 2651:

lab2651rtr# conf t
lab2651rtr(config)# int serial 0/1
lab2651rtr(config-if)# description T1 to lab3640rtr
lab2651rtr(config-if)# bandwidth 1544
lab2651rtr(config-if)# ip address 192.168.3.5 255.255.255.252
lab2651rtr(config-if)# no shut
lab2651rtr(config-if)# exit
lab2651rtr(config)# exit
lab2651rtr#


These commands should be pretty straightforward to you by now. Basically, we are using the second serial port in slot 0 on both routers, and we are setting a point-to-point link between them. Because only two hosts can exist in a point-to-point network, I have selected a subnet mask that gives us two usable IP addresses (192.168.3.4 255.255.255.252, or 192.168.3.4/30 provides four IP addresses: 192.168.3.4-7, and of those four, only .5 and .6 are usable, as .4 is the network address, and .7 is the broadcast address). The only command that might look a bit odd is the "bandwidth 1544" statement. This tells the router that this particular interface can carry up to 1.544Mbps of traffic, which the router will need to know later on. Technically, we could leave it off right now and it would make no difference, but since it will become important to include a "bandwidth" statement on serial interfaces in the fairly near future, you might as well get used to including it from the start :) One other note: on a home lab, it may not matter, but take my word for it -- in a professional work environment, be very, very careful when typing "no shut" on a Cisco router, especially when logging is enabled, as a typo can be, ahem, embarrassing (hint: what key is next to the "u" key on the keyboard?). Not that I would know from first-hand experience, of course (*cough*).

Once you have made this change to both routers, make sure the serial line is working by running the "sho ip int brie" command, then try pinging from one router to the other:

lab2651rtr# ping 192.168.3.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
lab2651rtr#


With that, we have established a WAN connection between the main office router, and the branch office router. In the next lab, we will connect the two LAN networks so that hosts on each LAN can communicate (right now, only the routers are talking to each other).

Lesson 4 -- Basic DHCP

So you have hosts talking across your network, you installed a router to bring you an Internet connection, and you successfully configured your router to provide network address translation (or more accurately, port address translation) to allow your LAN hosts to connect to the Internet, even though they are using IP addresses that are not publicly routable.

But now, you've got another problem. Your network is growing, and as new employees join the company, it is getting harder and harder for the IT staff (you) to visit every new employee's computer to assign an IP address. Wouldn't it be easier if there was a way for LAN hosts to automatically configure their own IP address?

Fortunately, there is. Cisco routers, Windows servers and most (if not all) *Nix servers can provide a service known as "DHCP" -- "Dynamic Host Configuration Protocol." DHCP is a service that listens for configuration requests, and negotiates a number of settings, such as an IP address, default gateway, and subnet mask. Here's how you set it up:

lab2651rtr# conf t
lab2651rtr(config)# ip dhcp excluded-address 192.168.1.1 192.168.1.31
lab2651rtr(config)# ip dhcp pool LANPOOL
lab2651rtr(dhcp-config)# network 192.168.1.0 255.255.255.0
lab2651rtr(dhcp-config)# dns-server 192.168.1.2
lab2651rtr(dhcp-config)# default-router 192.168.1.1
lab2651rtr(dhcp-config)# domain-name lan.example.com
lab2651rtr(dhcp-config)# lease 0 6 0
lab2651rtr(dhcp-config)# exit
lab2651rtr(config)# exit
lab2651rtr# write mem
Building configuration...
lab2651rtr#


Now, if you tell your PC's to automatically obtain an IP address, the router will negotiate an address with the hosts on your network, making your life a lot easier!

Here's how the configuration above works:
* The first line tells the DHCP server to set aside a block of addresses. 192.168.1.1, of course, is the IP address of the router itself, and the rest of the reserved IP addresses are for the servers the company will be using (with room for expansion). It is possible, of course, to automatically issue IP addresses to the servers, but most of the time, that's not a particularly good idea, because a server should always be reachable at the same address (that's not necessarily true, but dynamic DNS is well beyond the scope of this article, and it doesn't always work especially well, so I would avoid it on my server farm). However, if your servers are automatically being assigned IP addresses, they might sometimes get a different address than they had last time, which can make it difficult for your users to find the server on the network when they need a resource it provides!
* The second line defines the pool of addresses that we will be handing out to our users.
* The third line defines the network from which we will be assigning the IP addresses (all addresses we are handing out belong to the 192.168.1.0/24 network).
* The fourth line tells the DHCP clients what server IP address to use for name service resolution (DNS). Notice that the address we are using for our DNS server is one of the 31 IP addresses that we reserved earlier.
* In the fifth line, we tell our clients who their default gateway (default router) is. Notice that it's the very router that we are working from.
* In the sixth line, we define our domain name. This domain name will be assigned to any hosts that negotiate an IP address with the router.
* In the seventh line, we set the length of time for which the IP address is valid. The format is "days hours seconds", so in this case, the router will reserve the IP address for exactly four hours. Just as a quick aside, there are some points about DHCP that are worth discussing at this point, as they relate to the lease time. First, it's very important that our hosts are able to renew their IP addresses before their leases expire, because otherwise they won't be able to communicate on the network. However, no man-made device ever has 100% uptime (although Unix servers come close, lol!) so the creators of the DHCP protocol built in a mechanism to make sure that network hosts renew their lease well before they expire. In fact, a network host will attempt to renew it's lease when HALF of the lease time has elapsed. So if we set the lease time to four hours, then after two hours, our hosts will attempt to renew their leases. If the DHCP server is down, then the network admin -- you -- have two hours to fix it before anybody notices. The shorter you set the lease time, the less time you have to fix problems. However, you don't want to set your lease times too long. Hosts break, employees come and go, business partners might connect to your network for short periods of time and therefore, your DHCP server *may* be frequently assigning new IP addresses to new computers on the LAN. Since your IP pool is limited, you don't want to wait too long for a lease to expire on a host that may not even still be connected to the network, since that IP address cannot be reused until the lease expires. Consequently, setting the lease period is a tuning process. The greater the ratio between the number of IP addresses you have available and the number of hosts you actually have on the network, and the less often your network changes, the longer the lease time you can use without ill effects. On the other hand, if you have a small IP pool with a lot of hosts on your network, or if you have a lot of hosts connecting, disconnecting and reconnecting with short time spans, the quicker you will want the leases to expire. To get a better idea of what I'm talking about, find three computers to connect to your LAN, and create a DHCP pool of two IP addresses. Set all three computers to obtain an IP address automatically, and set the lease time to an absurdly small number, say five minutes. Turn on all three computers. What happens? Now turn off one of the computers that successfully obtained an IP address, and try to obtain an IP address on the one that did not successfully negotiate an address. Now what happens? Wait three minutes and try to obtain an address again. What happened this time?

There are a number of other options we can set to modify the behaviour of DHCP, but we won't need those on our network quite yet. However, in the next lesson, we'll start playing with some of those options.

Lesson 3 -- Network Address Translation

In our last lab, we set up a router to connect our company's small local area network to the Internet. However, in the first lab, we decided to use RFC-1918 addresses for our internal network. That causes a problem, unfortunately. RFC-1918 addresses are private, internal-only addresses, meaning most Internet Service Provider's routers won't route traffic to or from RFC-1918 addresses. At the ISP where I used to work, the network admins called RFC-1918 addresses "bogons" because those addresses were bogus on the Internet. So do we have to start over? Do we need to reconfigure all of our network equipment to use valid IP addresses?

Nope! There is a technology -- or more accurately, two closely related technologies that are often confused with each other -- that will allow our router to act as a "translator" between our internal network and the Internet. These technologies are often called "Network Address Translation" or "NAT," although what most people typically mean by the term is more accurately called "Port Address Translation" or "PAT." "NAT" refers to substituting a public IP address on the router for a private IP address inside the LAN -- basically, when the router receives an outbound packet, it rewrites the Source field of the IP packet with a public IP address assigned to the router's external interface. This is a one-to-one translation: if two hosts inside the LAN need to communicate with external hosts, there must be two IP addresses on the router's external interface. With "PAT," however, the router uses a combination of source port and a single, external interface to uniquely identify traffic for each internal host.

Let's set up port address translation on our company router:

lab2651rtr# conf t
lab2651rtr(config)# int fa0/0
lab2651rtr(config-if)# ip nat inside
lab2651rtr(config-if)# int fa0/1
lab2651rtr(config-if)# ip nat outside
lab2651rtr(config-if)# exit
lab2651rtr(config)# access-list 1 permit 192.168.1.0 0.0.0.255
lab2651rtr(config)# ip nat inside source list 1 interface FastEthernet0/1 overload


Essentially, what we are doing is creating a filter ("access-list 1 permit 192.168.1.0 0.0.0.255" -- we'll discuss access lists in a lot more detail later on), then using that filter to allow certain traffic (anything coming from a 192.168.1.xxx address) to be dynamically mapped to the router's external interface.

If you think about it, that's pretty cool, actually. Your computers and workstations inside your local area network can now communicate with other hosts on the Internet, but only Internet hosts that have an lready-established communication channel with your internal hosts can get back in through your router. Not only that, but a black hat on the Internet doesn't know the internal structure of your network when you are using NAT. Yeah, I'm familiar with the saying about security through obscurity. I'm not saying that you shouldn't take reasonable precautions to ensure network and PC security, but I would argue that hiding the details of your network design behind NAT can certainly be an effective layer of our security plan. Why give an attacker any more information than you have to?

However, there is a price to be paid for this feature (some would call it an ugly hack on IPv4 to handle the flaws inherent in the IPv4 addressing scheme, but meh...). First, since external hosts can only communicate with internal hosts that have already initiated a conversation with them, NAT will break services that you want to be initiated from outside your network. For example, if you build a public web server to advertise for your company, or an e-mail server that you want to be able to receive mail from other corporations, NAT will break these services. Furthermore, some protocols, for example SIP (which is commonly used in voice over IP telephony) do not work well when NAT'ted. There are work-arounds for these problems, fortunately. Servers that should have an external presence as well as an internal presence can be placed in a DMZ or you can configure additional external IP addresses on your router that map statically to the internal IP address of your servers.

At this point, your hosts should be talking on the Internet and to each other. That makes this a good point to stop for the night again. We'll pick up tomorrow with a tool to make it easier for you to assign IP addresses to hosts on your network.

Breaking Into Your Catalyst 2924XL Switch

DISCLAIMER: a lot of things in tech can be used for good or for evil. I am creating this document in the hopes that it helps some hapless admin regain connectivity to a Cisco device to which they legitimately have been granted access. This information can also be abused, however, and if you attempt to use the information I provide here for illicit purposes, I accept no responsibility for the consequences of YOUR actions. Use these techniques at your own peril!

I picked up two well-used Cisco Catalyst 2924XL switches to use in my home Cisco lab while working on my CCNA certification. Unfortunately, the console ports didn't seem to respond to my terminal program (Minicom) on my Linux laptops. Since there are two switches having the exact same problem, I doubt that it's a hardware failure; it seems like I must be doing something wrong. However, I have no problem accessing Cisco routers through the console or aux ports, nor do I have any problem accessing Foundry/Brocade switches, ImageStream routers -- well, pretty much any other network device that I have ever used -- so if I am doing something wrong, I have no idea what it might be. Usually a baud setting will still display text on the terminal, but it looks like gibberish. I, however, am getting an absolutely blank screen. Edit: I found an interesting document on Cisco's web site discussing how various configuration registers affect, among other things, the console port. I'll be doing some investigation later, and will post the results here. I now return you to your regularly scheduled blog :)

All is not lost, however. Cisco includes an incredibly useful feature known as "Cisco Discovery Protocol," or "CDP." If you are lucky, you will find that your switch has CDP enabled. If you have another Cisco device handy that you can manage, either through a console port or telnet session, run an Ethernet cable from the the 2924 switch to the other Cisco device. Make sure that CDP is enabled on the other Cisco device, then login. Wait a minute or two for the devices to begin communicating with each other. If the switch is running spanning tree, it will take a minute, more or less, to enable the port to the other Cisco device, and CDP, by default, sends updates once every 60 seconds, so be patient :) At the "Privileged Exec" prompt, type the following command:

Router# show cdp neighbor

If you are lucky (again), you will have output that lists, among other things, the IP address of the switch. If the switch has been configured previously AND you think you know the telnet password, you can attempt to telnet to the IP address that you found through CDP (you can telnet directly from the other Cisco device, if you want). If the telnet password has not been set, you will see a reply telling you that a password is required, but none has been set. In that case, you can try to configure the switch through its web interface, after connecting a laptop or desktop to an unused switch interface port and setting the IP address of the laptop to match the subnet of the switch.

If CDP was not enabled, things get a lot more difficult. You can use tcpdump and/or wireshark (two packet sniffing tools available for Linux, and I believe OS-X and Windows as well) from a PC connected to the switch's network interface to capture traffic from the switch. On my E-Bay 2924, the switch was broadcasting CDP messages, but had no IP interface configured. However, with tcpdump, I noticed it was also broadcasting DHCP requests. I configured my 2651 router to serve DHCP, captured the DHCP negotiation (and therefore, the IP address that the 2651 offered to the switch) and was able to configure a telnet password through the web interface (painful, but it got me access to the switch).

Lesson 2: Routing

Great job!

Your LAN has been a phenomenal success, and now the CEO is asking you to expand upon the network that you built in Lab #1. After all, this is the 21st Century, and employees expect to have Internet access. Think about it...isn't there more than just a grain of truth in this old joke:

Admit it -- most likely, that's how you found this page, isn't it? :) Anyway...your job is to set up a router to connect your fledgling network to the Internet. You will continue to use the 192.168.1.0/24 network for the LAN, and your ISP has assigned the IP address 100.64.1.22/24 for the outside interface of the router. Set up a basic config on the router (hostname, console, aux and telnet/ssh access), and create a default route to the Internet from your internal network.

Start by connecting FastEthernet0/0 on the LAN switch from Lesson 1 to FastEthernet0/0 on the router (I'm using a 2651 router) with a straight-through Ethernet cable. How can you tell if it's a straight-through or cross-over Ethernet cable? Well, if you hold the ends of the cable in your hand with the clip facing your palm, the wires should be orange-white, orange, green-white, blue, blue-white, green, brown-white, brown from left to right on both cables -- if one end starts with orange-white, orange...and the other end starts with green-white, green...then you've got a cross-over cable, and it won't work. Now connect a laptop or desktop computer to another port on the LAN switch with a second straight-through cable, then connect a console cable to the router and to the serial port on your PC, just like we did in Lesson 1. Once you've got a console connection to the router, type the following list of commands to program the router:

Router# conf t
Router(config)# hostname lab2651rtr
lab2651rtr(config)# enable secret mysecretpassword
lab2651rtr(config)# username root password mysecretpassword
lab2651rtr(config)# ip subnet zero
lab2651rtr(config)# no ip domain-lookup
lab2651rtr(config)# ip domain-name example.com
lab2651rtr(config)# interface FastEthernet0/0
lab2651rtr(config-if)# description LAN
lab2651rtr(config-if)# ip address 192.168.1.1 255.255.255.0
lab2651rtr(config-if)# speed 100
lab2651rtr(config-if)# full-duplex
lab2651rtr(config-if)# interface Serial0/0
lab2651rtr(config-if)# shutdown
lab2651rtr(config-if)# interface FastEthernet0/1
lab2651rtr(config-if)# description Internet
lab2651rtr(config-if)# ip address 100.64.1.22 255.255.255.0
lab2651rtr(config-if)# speed 10
lab2651rtr(config-if)# half-duplex
lab2651rtr(config-if)# interface Serial0/1
lab2651rtr(config-if)# shutdown
lab2651rtr(config-if)# exit
lab2651rtr(config)# ip classless
lab2651rtr(config)# ip route 0.0.0.0 0.0.0.0 100.64.1.1
lab2651rtr(config)# banner motd ~
Enter TEXT message. End with the character '~'.
########################################
# WARNING!!! Unauthorized use is       #
# prohibited, etc., etc. Insert dire   #
# warnings here for any who would      #
# attempt to gain access beyond their  #
# authorized privileges, etc., etc.    #
########################################
~
lab2651rtr(config)# line con 0
lab2651rtr(config-line)# exec-timeout 30 0
lab2651rtr(config-line)# password mysecretpassword
lab2651rtr(config-line)# logging synchronous
lab2651rtr(config-line)# line 33 48
lab2651rtr(config-line)# flush-at-activation
lab2651rtr(config-line)# line aux 0
lab2651rtr(config-line)# password mysecretpassword
lab2651rtr(config-line)# line vty 0 4
lab2651rtr(config-line)# password mysecretpassword
lab2651rtr(config-line)# login local
lab2651rtr(config-line)# transport input telnet
lab2651rtr(config-line)# exit lab2651rtr(config)# exit lab2651rtr#

That's a lot of typing. Make sure that you typed everything correctly, then make sure you can still access the router through the console port and through telnet. If everything is working properly, then enter one more command:

lab2651rtr# write mem

IMPORTANT!!! Do NOT run the "write mem" command until you are SURE that you can still get access to the router! If you botched a config, you can always power the router off to restore it to it's previous state, but once you have run the "write mem" command, rebooting the router will not restore the old config!

A lot of what was entered above may look like gibberish at first. That's okay. Trust me -- as you start to use the Cisco command-line interface, you'll get used to the commands, and they will start to make more sense. For now, there are a couple of things that I want to point out. I started the config by setting the hostname and domain name. These help you to identify the router (and the domain name is required if you want to set up SSH access to the router, which I will discuss later). Next, I set the "enable secret" password, and created a user account and password for telnet access. This can be a little confusing, but keep in mind that creating the user "root" and setting the user's password allows you to telnet (or SSH) to the router, while the "enable secret" password provides the user with permission to enter the "privileged exec" mode. Farther down in the config, I created passwords for all of the lines (console, aux and VTY) which allow management access to the router.

After setting the root user's password and the "enable secret" password, I configured interface "FastEthernet0/0" The "description" line is optional, but helps the you to make sure you are working with the correct interface when troubleshooting or configuring the router. Next, we set the IP address of the interface to 192.168.1.1, and set the subnet mask to 255.255.255.0 -- basically, just another way of saying that this is a /24 subnet. A full discussion of subnet masks, classless addressing and such is a bit beyond the scope of this lesson, which is already growing long enough, but for now, let's just accept that this a way of specifying that we can address up to 254 hosts on the network we just created. Google "CIDR" if you want more information ;) Also, in the interface config, I set speed and duplex for the network interfaces. Originally, the Ethernet specification for twisted pair (CAT-3 and later, CAT-5 and CAT-6 cable) only allowed for speeds of 10Mbps and half-duplex (only one host on a wire can transmit at a time). Later, the Ethernet spec was expanded to 100Mbps (FastEthernet) and full-duplex operation (both hosts on a wire can send and receive at the same time), and now you can find network interfaces that support speeds of up to 10Gbps. I set the interface that is connected to the LAN switch to operate at 100Mbps, full-duplex and the interface that is connected to the ISP router (a 3640 router, in my home lab network) to operate at 10Mbps and half-duplex, since that is what the unused port on my 3640 would support.

After setting the network interfaces, I included the line "ip route 0.0.0.0 0.0.0.0 100.64.1.1." In this line, I am telling the router that all traffic destined for an IP address that does not exist in its routing table should be forwarded to 100.64.1.1 (the ISP router). This is known as a "default gateway" or "gateway of last resort." This is common on a LAN network -- the only way to reach anything not on the local LAN is through the ISP's routers, so anything that isn't local to the LAN router is forwarded to the ISP's routers.

At this point, you may be tempted to try to ping the ISP router from your laptop, but if you do, you will find that the ping request times out. This is because, even though you have a route to the ISP router, the ISP router doesn't know how to reach the network inside your LAN -- it's a private network, and you have only statically configured a route to the Internet, so your traffic will make it outbound, but not back inbound. But don't despair -- there's a solution, called "Network Address Translation" or "NAT", and in our next lab, we will show you how to set up your router to NAT your private network so that you can actually talk to other hosts on the Internet.

Extra Credit: If you just can't wait until the next lab, you can always create a static route to 192.168.1.0/24 on the ISP router. Assuming you are on a Cisco router, log in and run these commands:

ISP# conf t
ISP(config)# ip route 192.168.1.0 0.0.0.255 100.64.1.22
ISP(config)# exit


...then try pinging to the ISP router again. This should work. If not, try to figure out why.

Lesson 1 -- Building a LAN

Congratulations!

You have just taken a job with with a new company! Your company is a brand new start-up, and they have absolutely nothing in the way of Information Technology. You've been hired to build their corporate network from the ground up. They have several server and desktop PCs -- running Linux, of course, with maybe a few FreeBSD hosts thrown in for good measure ;) -- and your first job is to get them connected. You have a shoe-string budget, so you went on E-Bay and found an old Cisco Catalyst 2924XL switch for $20 (plus shipping). You'll have to build a local area network so that the servers and desktops can communicate with each other. Ready? Cool -- let's get started!

We'll start with selecting an IP addressing scheme. TCP/IP, often called IPv4, isn't the only choice, but it's by far the most common choice, so for now, we'll stick with it. We've already stated that this is a small company with just a handful of hosts on the network, so we don't need a lot of addresses, and we only need one subnet. But what IP address do we use? We can't use just any address, since at some point, we'll want to connect to the Internet. If we pick a range of IP addresses that are already in use, we'll cause ourselves all kinds of problems. Fortunately, this is not a new problem, and the answer is defined in an Internet standard known as RFC-1918. The linked document is somewhat technical, so if you don't want to get that intense quite yet, then let's just say that RFC-1918 defines three groups of IP addresses that you are free to use on internal networks, without fear of colliding with others' IP addresses.

For now, we want to keep things simple, so we will use the subnet 192.168.1.0/24 (IP addresses in the range of 192.168.1.1 through 192.168.1.254) for our network. We'll reserve 192.168.1.1 -- you'll see why in the next lesson -- and we will assign the next few addresses in our network to our servers. We have a file server at 192.168.1.2, a DNS server on 192.168.1.3 (and a backup DNS server on 192.168.1.4), and a web server at 192.168.1.5. Our LAN switch will have the IP address 192.168.1.254. We will statically (manually) assign IP addresses to all of the hosts in our network.

Once we have reserved IP addresses to use on our network, we'll need to configure our LAN switch to connect all of these devices. But...how do you access the switch to put a configuration on it before it has been added to our network? Again, this is a problem that has already been solved. Cisco -- and pretty much every other network vendor that I've worked with -- has included a serial port on the chassis of the switch for management access. On the 2924, this port is labelled "CON" (short for "console"), and you can access it through a terminal program like Minicom on Linux machines, or Hyperterm on a Windows PC. Configuring your PC's terminal program is beyond the scope of this tutorial (read that as, "it's boring, and there are a lot of options so this document would become quite large without providing information that is easily obtained from Google" LOL), so I am going to assume that you already know how to configure your terminal emulator on your particular OS. If you don't, spend some quality time with Google; I'll wait here until you're done :)

Are you back yet? Good! You've got your terminal set for 9600 baud, eight bits, no parity bits and one stop bit (often abbreviated, "9600-8N1"), right? Great! Press the "Enter" key on your keyboard a few times, and you should see something on your screen kind of like this:

Scratch that. My E-Bay 2924 arrived yesterday, and I now have two 2924XL switches that don't respond on the console port. That makes me think I'm doing something wrong, but since the above instructions work on every Cisco router, Brocade/Foundry switch and ImageStream router that I've ever used (as well as a multitude of other network devices), I can't imagine what I might be missing on the Catalyst switches, In any case, the bottom line is that right now, I can't describe setting up the initial settings via console. If yours works by following the above instructions, awesome. If not, here are a couple of things that I did to gain management access in the hopes that they help you, but be forewarned -- they are slightly advanced topics, especially for Lesson 1. For now, I'm just going to assume that you've got management access to the switch, but I promise to update this post as soon as I can figure this problem out. Sorry :(
Switch>
Notice the "greater-than" symbol? That means that you are in "User mode," a Cisco term that basically means "you are logged in, but can't really do anything useful." If you want to make changes to the switch's configuration -- and we do -- you'll need to enter "Privileged Exec mode." Type "en" (short for "enable" -- which you can also type), then press enter and you will see the prompt change to this:
Switch#
To return to "User mode," just type "disable" and press enter. Pretty simple, no?

Let's actually make some changes to the switch configuration now. I'm going to list some commands below; go ahead and enter them on your switch or simulator, and I'll explain what each command does in just a minute. I promise not to tell you to do anything that will damage your switch (at least, not intentionally), but if you are working on real equipment, PLEASE make sure it is not a production switch, and that it is in an isolated lab environment! I accept no responsibility if you break your corporate network because you are practising on a live, production network!

Router# conf t
Router(config)# service password-encryption
Router(config)# hostname lab2924b
lab2924b(config)# enable secret mysecretpassword
lab2924b(config)# username root password mysecretpassword
lab2924b(config)# ip subnet-zero
lab2924b(config)# no ip domain-lookup
lab2924b(config)# ip domain-name example.com
lab2924b(config)# interface VLAN1
lab2924b(config-if)# ip address 192.168.1.253 255.255.255.0
lab2924b(config-if)# exit
lab2924b(config)# ip default-gateway 192.168.1.1
lab2924b(config)# banner motd ~
########################################
# Warning!!! Unauthorised access is    #
# prohibited, etc., etc. Attempting    #
# to gain access in excess of allowed  #
# clearance <insert dire warning here> #
# etc., etc.                           #
########################################
~
lab2924b(config)# line con 0
lab2924b(config-line)# exec-timeout 30 0
lab2924b(config-line)# password mysecretpassword
lab2924b(config-line)# logging synchronous
lab2924b(config-line)# login
lab2924b(config-line)# line vty 0 4
lab2924b(config-line)# password mysecretpassword
lab2924b(config-line)# login local
lab2924b(config-line)# exit
lab2924b(config)# exit lab2924b#


Don't worry if that looks a little overwhelming -- it gets better with practice :) Basically, we set up a number of options on the switch to secure it against unauthorised access, to make it easy to manage and to help us make sure we were managing the switch we expected to be managing. (As an aside, I once watched, horrified, as a co-worker accidentally reformatted the hard drive on a server we had just finished installing and configuring. He was SSH'd into the both the old server and the new server at the same time, and thought he was in the terminal window for the old server when he was actually in the terminal window for the new server. Amazingly, we were able to rebuild the server in a little over an hour's time -- and thus, we were able to catch our flight back home that afternoon -- but it was a great object lesson in using meaningful host names, and always making sure the host name on your terminal session matches the host name you expect to see before overwriting/erasing data or changing configs). The "service password-encryption" command rewrites all of the passwords in the config file to an encrypted format so that someone looking over your shoulder can't discover your password. By default, Cisco's IOS will assume that any word you type on the command line that it doesn't recognize as a legitimate command is a hostname, and therefore, it will try to use DNS to resolve the "host name" into an IP address, which can be a real pain. The "no ip domain-lookup" command tells the IOS not to do that (IMHO, it ought to be the default behaviour on Cisco equipment). The "banner motd..." command tells the switch to display a login message when someone accesses the console or telnet virtual terminal lines. You can put whatever message you want, and you don't have to use a squiggle as the delimiter; I just use it because I don't think I am likely to use a squiggle in a login message, so it's convenient. All of the other commands should be pretty self-explanatory, but if not, then you absolutely should spend some time looking them on Cisco's web site. Better yet, after entering these commands, return to "Privileged Exec" mode, and run the "write mem" command to save the config to permanent storage (flash), then spend some time enabling and disabling the commands and see what happens! If you lose access to the switch, just unplug it, count to five, then plug it back in. In one or two minutes, the switch will reboot into the saved configuration, allowing you to telnet in again.

Also, connect two computers, a computer and a router, or whatever you've got to the switch, and see if you can ping across from one computer or router to the other. As long as both hosts are on the same subnet (i.e., 192.168.1.xxx, where "xxx" is a number between 1 and 252 -- this switch is .253, remember?) they should be able to reach each other. If not, use the "show ip interface brief" or "show interface" commands to figure out why not. If the switch had already been configured, then you might see output like this...:

lab2924b# show ip interface brief
Interface       IP-Address    OK? Method Status                Protocol
VLAN1           192.168.1.253 YES manual up                    up
FastEthernet0/1 unassigned    YES unset  up                    up
FastEthernet0/2 unassigned    YES unset  administratively down down


If you notice, VLAN1 and FastEthernet0/1 show Status is up and Protocol is up, but FastEthernet0/2 is "administratively down." That means the administrator (you) has turned off that Ethernet port on the switch. To fix, type:

lab2924b# conf t
lab2924b(config)# int fa0/2
lab2924b(config-if)# no shut
lab2924b(config-if)# exit
lab2924b(config)# exit
lab2924b# write mem


I did two things here: first, I told the switch that I want to enable ("no shutdown") the FastEthernet0/2 port, and second, you'll notice that I didn't type all of the commands out in full ("conf t" rather than "configure terminal", "int fa0/2" rather than "interface fastethernet0/2", etc.). The Cisco IOS is smart enough to understand what you mean as long as you type enough characters to positively identify the command you want. For example, on a router with an ISDN Basic Rate Interface port, you can't type "sho ip int bri" instead of "sho int brief" because there is an interface bri0 on the router. You can, however, type "sh ip int brie", as that provides enough characters for the router to differentiate between the bri0 interface and the brief output of the "sho ip int" command.

For a "simple" lesson, we've covered a lot of material here, so I'm going to knock off for the night. We'll pick up later in Lesson 2 where we start playing with a Cisco router.

Hello!

Greetings!

I'm the Alaska Network Geek. I've been employed in I.T. in the telecommunications industry since 1999, working both on corporate networks as well as service provider networks. What's kind of funny is that, despite well over a decade in the industry, I'm now working on my Cisco Certified Network Associate certification. I earned a competing vendor's comparable certification (Brocade Certified Network Engineer) last year, but somehow seemed to never (yet) earn the CCNA. However, change is in the air, and as a result, I've decided it's time to earn the Cisco certification.

When I first looked at earning the CCNA certification, I was somewhat dismayed by the material that was available to help study. IMHO, the best way to learn a technology is to start playing with it. Once you can make the equipment sing and dance, so to speak, a certification test is easy -- or at least, that's been my experience. To that end, I've decided to create this blog to approach the CCNA from a different tack than I've seen elsewhere on-line.

When I was in seventh and eighth grade, I was fortunate enough to have science classes that took a more hands-on approach than any class I had ever taken. The class lecture was maybe five or ten minutes; after that, it was all lab. Those two classes did more to kindle my interest in science -- or learning in general, for that matter -- than the rest of my primary and secondary school career. And that's the approach I intend to take on this blog. I'll be learning the concepts covered in the CCNA exam through labs that emulate real-world scenarios. I have set up a small lab consisting of various Cisco routers and switches that I've managed to scrounge, and I'll be building the networks that I describe in each post. That's the way I learn best, and hopefully, you will pick up a thing or two as well :)

So...enough procrastinating. Let's get started on that CCNA!