Job Opportunity - Network Specialist

Date Posted:
4/22/2009
Location:
Forest View Educational Center
Date Available:
07/01/2009 or sooner

GENERAL RESPONSIBILITIES:

The Network Specialist assists the Network Operations Manager in implementing the overall data connectivity requirements for the district. The Network Specialist maintains and upgrades the District 214 local and wide area networking facility at Forest View Educational Center and the six high schools. The Network Specialist works closely with other district technology staff in maintaining the network services throughout the district. The position requires the ability to be on 24 hour call and the availability to work evenings and weekends as needed.

QUALIFICATIONS:

The Network Specialist is a specialized position requiring a combination of these qualifications:

CCNA (Cisco Certified Network Associate) and MCSE (Microsoft Certified Systems Engineer) or ACSA (Apple Certified System Administrator) or equivalent demonstrated experiences. Must have knowledge of data communication protocols (TCP/IP, IPX, AppleTalk, SNMP, IGRP, EIGRP, RIP, OSPF).

http://www.generalasp.com/D214/onlineapp/jobpostings/view.asp?category=SUPERVISORY+%2D+NETWORK+SPECIALIST

Cisco Router/PIX Emulator

I have been hearing so much about Dynamips lately that I think I must take some time to do some experimenting with it. I just received an email from a COD friend and Alumni, Gonzalo Escarra, a Sr. Technical Support Analyst for Aqueity, and he writes:

“As I'm studying for my CCNP now, I found this new Cisco emulator based on Dynamips and PEMU called GNS3 (http://www.gns3.net/). It's a GUI for building a lab using Routers and PIX's, and it works flawlessly on Windows. The only thing you'll need are the IOS images to run, as the software uses original Cisco images to emulate (meaning you get the exact same functionality in a lab environment).
Figured you might be interested to pass this along to your students in case they need some extra practice outside of lab time. It is VERY useful at least for me.”

Maybe we should form a Dynamips workgroup and figure this out together. Let me know via email if you would be interested. Gonzalo has volunteered to give us some support just in case we run into problems.

Thank you Gonzalo!

RIPv2 Next Hop Address

Remember on the RIPv2 PowerPoint slide (as shown) we were seeing on the debug ip rip a 0.0.0.0 address and couldn't explain why. Steven Zinkie jumped right in on this and reported back with the answer. He found the following explaination in our book..

1) Like RIPv1, RIPv2 is encapsulated in a User Datagram Protocol (UDP) segment using port 520 and can carry 25 routes per update.

2) The first significant extension in the RIPv2 message format is the subnet mask field (32 bit mask) to be included in the RIP route entry.

3) The second significant extension of RIPv2 is the addition of the next-hop address. The next-hop address is used to identify a better next-hop address – if one exists. If the field is set to 0.0.0.0, the address of the sending router is the best next-hop address.

Thanks Steven - mystery solved!

RIP Default Routes: default-information originate vs. redistribute static

I told my students that the default-information originate command was similiar to the redistribute static command. A student asked me how exactly do they differ. To answer that question I have set up a scenario using three routers, as depicted above, to give studens a visual of how they both work and differ.

I set up Router3 as the ISP and configured two static routes pointing to 10.1.1.0/30 and 192.168.1.0/24. I set up Router2 as the edge router of my network. In Router2 I had two static routers pointing to virtual networks (network 1.0.0.0 and network 2.0.0.0) and a default static route (0.0.0.0).

First I configured Router2 to propagate the default route to Router1 using the default-information originate command. As a result, the default static route was propagated correctly to Router1 as shown below (see Router2’s configuration file, routing table and Rotuer1’s routing table). Notice that the default static was the only static route that RIP advertised to Router1. Note, I have removed some unrelated lines of commands from the configuration files, to simplify.

R2#show run
service password-encryption
hostname R2
enable secret 5 $1$uEh1$AsHH04FVVwwziW4XdTJHn0
interface Loopback1
ip address 1.1.1.1 255.255.255.255
interface Loopback2
ip address 2.2.2.2 255.255.255.255
interface Serial0/0
ip address 10.1.1.2 255.255.255.252
interface Serial0/1
ip address 172.16.2.2 255.255.255.252
router rip
network 10.0.0.0
default-information originate
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/1
ip route 129.5.0.0 255.255.0.0 Loopback1
ip route 129.6.0.0 255.255.0.0 Loopback2
line con 0
password 7 00071A150754
login
line vty 0 4
password 7 05080F1C2243
login
end
R2#

R2#show ip route
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback2
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.2.0 is directly connected, Serial0/1
S 129.5.0.0/16 is directly connected, Loopback1
S 129.6.0.0/16 is directly connected, Loopback2 10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial0/0
R 192.168.1.0/24 [120/1] via 10.1.1.1, 00:00:09, Serial0/0
S* 0.0.0.0/0 is directly connected, Serial0/1

R2 is the edge router which contains two static routes and a default static route. The default static route has been propagated to the inside (R1) using the default-information originate command.

R1#show ip route
Gateway of last resort is 10.1.1.2 to network 0.0.0.0

10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial0/2/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 10.1.1.2, 00:00:13, Serial0/2/0R1#

Next, I configured Router2 to propagate the default route to Router1 using the redistribute static command. As a result, not only the default static route was propagated Router1, but ALL three of the static routes were advertized to Router1! See Router1’s routing table after modifying R2’s configuration file to use the redistribute static command in place of the default-information originate command:

R1#show ip route
Gateway of last resort is 10.1.1.2 to network 0.0.0.0

R 129.5.0.0/16 [120/1] via 10.1.1.2, 00:00:04, Serial0/2/0
R 129.6.0.0/16 [120/1] via 10.1.1.2, 00:00:04, Serial0/2/0 10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial0/2/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 10.1.1.2, 00:00:04, Serial0/2/0

R1#

As you can see, since R2 had more that one static route, they were all advertised through RIP using the redistribute static command. Therefore, in order to use the redistribute static command, we need to do some additional configuration to Router2. In Router2, we would have to use a distribute-list command or a route map (both to be studied in your CCNP1 class) to permit only the default static route to be propagated by RIP. Following is an example of the extra configuration needed in Router2 as well as the resulting Router1 routing table.

R2#show run
service password-encryption
hostname R2
enable secret 5 $1$uEh1$AsHH04FVVwwziW4XdTJHn0
interface Loopback1
ip address 1.1.1.1 255.255.255.255
interface Loopback2
ip address 2.2.2.2 255.255.255.255
interface Serial0/0
ip address 10.1.1.2 255.255.255.252
interface Serial0/1
ip address 172.16.2.2 255.255.255.252
router rip
redistribute static
network 10.0.0.0
distribute-list 10 out staticip classless
ip route 0.0.0.0 0.0.0.0 Serial0/1
ip route 129.5.0.0 255.255.0.0 Loopback1
ip route 129.6.0.0 255.255.0.0 Loopback2
access-list 10 permit 0.0.0.0
line con 0
password 7 00071A150754
login
line vty 0 4
password 7 05080F1C2243
login
end

R1#show ip route
Gateway of last resort is 10.1.1.2 to network 0.0.0.0
10.0.0.0/30 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Serial0/2/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 10.1.1.2, 00:00:02, Serial0/2/0R1#

RIPv1 Classful Behavior with Multiple Subnet Masks

There was some confusion this week on how RIPv1 would handle a subnet with multiple masks. As a result of the discussion, I decided to test it out. I configured three routers, RouterA, RouterB, and RouterC, as shown.

RouterA, RouterB, and RouterC could all communicate using a mask of 255.255.255.252 (/30). RouterA’s routing table included both the serial links with the 255.255.255.252 mask (networks 172.16.9.0, 172.16.9.4, and 172.16.9.8) and the Fast Ethernet link (172.16.1.0)configured with a mask of 255.255.255.0 (/24). RouterB and RouterC's routing table did not include the FastEthernet route to 172.16.1.0/24.

I am including the routing tables and debug ip rip output for your review. Notice that RouterA did not include network 172.16.1.0 (which had been configured on the FastEthernet0/0 interface with a mask of 255.255.255.0) in the update send out its egress interface to RouterB and RouterC:

02:38:21: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (172.16.1.1)
02:38:21: RIP: build update entries - suppressing null update

RouterA#show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
R 172.16.9.4/30 [120/1] via 172.16.9.2, 00:00:12, Serial0/0
[120/1] via 172.16.9.10, 00:00:16, Serial0/1
C 172.16.9.0/30 is directly connected, Serial0/0
C 172.16.1.0/24 is directly connected, FastEthernet0/0
C 172.16.9.8/30 is directly connected, Serial0/1

RouterB#show ip route
172.16.0.0/30 is subnetted, 3 subnets
C 172.16.9.4 is directly connected, Serial0/2/1
C 172.16.9.0 is directly connected, Serial0/2/0
R 172.16.9.8 [120/1] via 172.16.9.6, 00:00:22, Serial0/2/1
[120/1] via 172.16.9.1, 00:00:00, Serial0/2/0

RouterC#show ip route
172.16.0.0/30 is subnetted, 3 subnets
C 172.16.9.4 is directly connected, Serial0/2/1
R 172.16.9.0 [120/1] via 172.16.9.9, 00:00:09, Serial0/2/0
[120/1] via 172.16.9.5, 00:00:16, Serial0/2/1
C 172.16.9.8 is directly connected, Serial0/2/0

RouterA#debug ip rip
03:31:04: RIP: received v1 update from 172.16.9.2 on Serial0/0
03:31:04: 172.16.9.4 in 1 hops
03:31:05: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0 (172.16.
1.1)
03:31:05: RIP: build update entries - suppressing null update
03:31:05: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (172.16.9.1)
03:31:05: RIP: build update entries
03:31:05: subnet 172.16.9.8 metric 1
03:31:05: RIP: sending v1 update to 255.255.255.255 via Serial0/1 (172.16.9.9)
03:31:05: RIP: build update entries
03:31:05: subnet 172.16.9.0 metric 1
03:31:16: RIP: received v1 update from 172.16.9.10 on Serial0/1
03:31:16: 172.16.9.4 in 1 hops

RouterB#debug ip rip
RIP protocol debugging is on
*Apr 20 04:15:35.767: RIP: sending v1 update to 255.255.255.255 via Serial0/2/0
(172.16.9.2)
*Apr 20 04:15:35.767: RIP: build update entries
*Apr 20 04:15:35.767: subnet 172.16.9.4 metric 1
*Apr 20 04:15:38.755: RIP: received v1 update from 172.16.9.6 on Serial0/2/1
*Apr 20 04:15:38.755: 172.16.9.8 in 1 hops
*Apr 20 04:15:39.899: RIP: sending v1 update to 255.255.255.255 via Serial0/2/1
(172.16.9.5)
*Apr 20 04:15:39.899: RIP: build update entries
*Apr 20 04:15:39.899: subnet 172.16.9.0 metric 1
*Apr 20 04:15:40.067: RIP: received v1 update from 172.16.9.1 on Serial0/2/0
*Apr 20 04:15:40.067: 172.16.9.8 in 1 hops

RouterC#debug ip rip
*Apr 20 04:22:26.219: RIP: sending v1 update to 255.255.255.255 via Serial0/2/1
(172.16.9.6)
*Apr 20 04:22:26.219: RIP: build update entries
*Apr 20 04:22:26.219: subnet 172.16.9.8 metric 1
*Apr 20 04:22:28.267: RIP: received v1 update from 172.16.9.9 on Serial0/2/0
*Apr 20 04:22:28.267: 172.16.9.0 in 1 hops
*Apr 20 04:22:31.123: RIP: sending v1 update to 255.255.255.255 via Serial0/2/0
(172.16.9.10)
*Apr 20 04:22:31.123: RIP: build update entries
*Apr 20 04:22:31.123: subnet 172.16.9.4 metric 1
*Apr 20 04:22:32.891: RIP: received v1 update from 172.16.9.5 on Serial0/2/1
*Apr 20 04:22:32.895: 172.16.9.0 in 1 hops

RIPv1 Holddown

Several of you wanted a more in depth understanding of one of the primary activities of convergence - holddown. As you will remember from our class discussion, convergence involves four primary activities: update, invalid, holddown, and flush. These are the timers that a Cisco router uses to control the way RIP reacts to changes in its routing table.

The following discussion of Cisco’s implementation of RIP holddown comes from Robert Wright’s book, IP Routing Primer, ISBN 1-57870-108-2. I have found his discussion on holddowns to be most helpful. According to Wright, a router puts a route into holddown under one of three conditions.
1) The router that was advertising the route stops advertising it for 180 seconds (invalid period).
2) The router that advertised the original route sends a new advertisement for the same route with a metric greater than the metric stored in the routing table. This usually indicates that there is a routing loop, which causes the route to be immediately deleted and put into holddown instead of being forced to wait for the invalid timer to fire.
3) The router that was advertising the route sends a new advertisement for the route with an unreachable metric, otherwise known as poisoning the route.

Cisco’s RIP holddown, 180 seconds by default, refers to routes that have been marked as invalid but are not yet capable of being replaced with a new route of a higher metric. Holddowns prevent routes from changing too rapidly by allowing time for either the downed route to come back up or the network to stabilize before accepting a route to the same destination with a worse metric. The idea of the holddown period is that if the path you are using to reach a particular network goes down, you wait for some time before switching to another path. During the time a router has that route in holddown, it continues to forward any packets it receives (updates and user traffic) that are destined for that particular network with a cost of infinity.

According to Wright, one of the reasons for having routing protocols behave this way is based on the assumption that temporary packet loss due to using routes to networks that might not be viable is better than immediately accepting a less desirable route to the destination network. In a discussion on route flapping due to congestion on a link between two routers, RouterA and RouterB, he gives us a pretty good understanding of the reasoning behind holddown. When RouterB stops advertising 168.71.8.0 (a LAN directly connected to RouterB) to RouterA (RouterA and RouterB are connected via a serial link) for 180 seconds (the invalid timer expires), RouterA puts route 168.71.8.0 in holddown.

By allowing these packets to be dropped instead of sending them via the less desirable path, through RouterC, RouterA and RouterB are giving the hosts off of RouterA and RouterB a chance to react to the dropped packets by sending fewer packets at a time – perhaps even sending smaller packets. This, as he tells us, would require that either the applications in use or their underlying protocols keep track of packet loss and to respnd accordingly.

If RouterA immediately accepted the less desirable route, through RouterC, as soon as the invalid timer expired for the downed route 168.71.8.0 on RouterA and forwarded all traffic to 168.71.8.0 over it, and congestion on the more desirable, original path would cease to be a problem.

The routing updates that had been getting dropped due to congestion would start arriving again, and RouterA would immediately go back to using its link to RouterB to reach 168.71.8.0. At this point, the problem would start all over again (route flapping which is when a route continuously switches between two different next hop routers).

If the traffic pattern that caused this problem is more than just an anomaly, it will be necessary to either increase the speed of the link between RouterA and RouterB or permanently configure the hosts to send fewer packets at a time (and possibly smaller packets as well) to prevent it from happening again.

RIPv1 Broadcasts

This week in one of my CCNA Routing classes, while discussing the operation of Distance Vector routing protocols, there was some good discussion (and debate) going on as to how RIP broadcast would be handled by each host on the local LAN network. Some students were of the impression that the frame would not be processed at all if the host device wasn’t running RIP. Others thought it would be processed and discarded at layer 2; some thought it would be discarded at layer 3; others were not sure what layer would actually discard the update if RIP protocol wasn’t running on the device.

I want to share with you an explanation of what happens to that RIP update when it reaches the host device. It comes from, Chapter 12, Broadcasting and Multicasting, http://www.uic.rsu.ru/doc/inet/tcp_stevens/broadcas.htm.

In the document, the author explains to us that the interface card sees every frame that passes by on the cable and makes a decision whether to receive the frame and pass it to the device driver of that host machine. There are exceptions (promiscuous mode), but normally the interface card passes to the device driver only frames addressed specifically to the host device, multicast frames destined for a particular group on that host device, or broadcast frames meant for everyone on the cable.

Once that decision is made (filtering decision) and the interface card of that device decides to keep the frame, it is passed to the device driver where the frame checksum calculation is performed to check the frame for errors. If no frame errors are detected, the frame undergoes additional filtering by the device driver. One of the first things to be checked is the protocol field in the frame header. Because this frame is carrying an IP payload (RIP uses IP), the frame is passed to layer 3. IP performs more filtering, based off of the source and destination IP addresses, and, because it is a UDP datagram, passes it to the Transport Layer, UDP protocol for additional processing.

You guessed it, more filtering at layer 4! Now the port numbers are checked. If no process is currently using the destination port number (port 520 for RIP), the datagram will be discarded and an ICMP port unreachable message will be generated. If the UDP datagram has a checksum error, UDP will discard it with no message returned to the sender.

As the author will tell you, the problem with broadcasting RIP v1 updates is that there is considerable overhead for each of these hosts. All hosts must process the broadcast all the way up to layer 4 of the stack, regardless if they are running RIP v1 or not.