Yu Cheng (Jade) ICS 351 Lab Report 4 part 2 October 19, 2008 [Exercise 3A] We connected the ethernet interfaces of the PCs and the routers. We used the following commands to configure the IP addresses and the interfaces on the PCs: on PC1: `ifconfig eth0 10.0.1.10/24` on PC2: `ifconfig eth0 10.0.2.10/24` on PC3: `ifconfig eth0 10.0.3.10/24` on PC4: `ifconfig eth0 10.0.4.10/24` We used the following commands to turn on the RIP protocol and configure the IP addresses and interfaces on the routers: on PC1: `minicom` username: cisco password: cisco yourname# config t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# router rip yourname(config-router)# version 2 yourname(config-router)# network 10.0.0.0 yourname(config-router)# interface FastEthernet0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.1.1 255.255.255.0 yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.2.1 255.255.255.0 yourname(config-if)# end yourname# clear ip route * yourname(config)# router rip yourname(config-router)# version 2 yourname(config-router)# network 10.0.0.0 yourname(config-router)# interface FastEthernet0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.2.2 255.255.255.0 yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.3.2 255.255.255.0 yourname(config-if)# end yourname# clear ip route * yourname(config)# router rip yourname(config-router)# version 2 yourname(config-router)# network 10.0.0.0 yourname(config-router)# interface FastEthernet0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.3.3 255.255.255.0 yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.4.3 255.255.255.0 yourname(config-if)# end yourname# clear ip route * We used command `show ip route` to display the routing tables on every router to ensure the configuration was correct. We observed four entries in each routing table. Since the RIP routing protocol was turned on, the routers exchanged routing information with their directly-connected neighbours. When the routing tables stablized, each router had information about all networks in the system. We issued commands to start the zebra and the ripd processes on all four PCs. We also connected to the ripd processes via Telnet. The commands we used were: on PC#: `/etc/rc.d/init.d/zebra start` on PC#: `/etc/rc.d/init.d/ripd start` on PC#: `telnet localhost 2602` After entering the password, the prompt symbol became "ripd#". In order to configure the hosts and set them to run RIP in passive mode, we used commands: on PC#: ripd# `config t` on PC#: ripd(config)# `router rip` on PC#: ripd(config-router)# `version 2` on PC#: ripd(config-router)# `network 10.0.0.0/8` on PC#: ripd(config-router)# `passive-interface eth0` on PC#: ripd(config-router)# `end` We used command `netstat -rn` to display the routing tables on all four PCs. We saved the output of this command on each PC as ex3a2pc1.txt, ex3a2pc2.txt, ex3a2pc3.txt, and ex3a2pc4.txt. Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.2.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 10.0.2.2 255.255.255.0 UG 0 0 0 eth0 10.0.1.0 10.0.2.1 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.3.0 10.0.2.2 255.255.255.0 UG 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 10.0.3.3 255.255.255.0 UG 0 0 0 eth0 10.0.1.0 10.0.3.2 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 10.0.3.2 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.1.0 10.0.4.3 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 10.0.4.3 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.4.3 255.255.255.0 UG 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 We connected Router4 with network 10.0.4.0 and 10.0.2.0. We used the following commands to configure Router4's ip addresses on two of its interfaces. We also configured Router4 to run RIP. on PC1: `minicom` username: cisco password: cisco yourname# config t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# router rip yourname(config-router)# version 2 yourname(config-router)# network 10.0.0.0 yourname(config-router)# interface FastEthernet0/0 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.4.4 255.255.255.0 yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# no shutdown yourname(config-if)# ip address 10.0.2.4 255.255.255.0 yourname(config-if)# end yourname# clear ip route * We used the command `netstat -rn` to display the routing tables on the PCs. We observed differences comparing to the routing tables before connecting Router4. We saved the converged routing tables for all PCs as ex3a5pc1.txt, ex3a5pc2.txt, and ex3a5pc3.txt. Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.2.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.1.1 255.255.255.0 UG 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 10.0.2.4 255.255.255.0 UG 0 0 0 eth0 10.0.1.0 10.0.2.1 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.3.0 10.0.2.2 255.255.255.0 UG 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 10.0.3.3 255.255.255.0 UG 0 0 0 eth0 10.0.1.0 10.0.3.2 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 10.0.3.2 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.0.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.1.0 10.0.4.4 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 10.0.4.4 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.4.3 255.255.255.0 UG 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 From the routing table comparson, PC2 and PC4 updated their routing tables. PC2 changed to use Router4, gateway 10.0.2.4, for packets with a destination of network 10.0.4.0. PC4 also changed to use Router4, gateway 10.0.4.4, for packets with a destination of network 10.0.2.0 or network 10.0.1.0. The communication between PC2 and PC4 changed to go through Router4 instead of using Router3 plus Router2. The communication between PC1 and PC4 changed to use Router4 plus Router1 instead of using Router3 plus Router2 plus Router1. It took very little time for the system to update its routing tables. We oberserved differences almost instantaneously. RIP routers maintain only the best route (the route with the lowest metric value) to a destination. After updating its routing table, the router immediately begins transmitting routing updates to inform other network routers of the change. These updates are sent independently of the regularly scheduled updates that RIP routers send. [Exercise 3B] We issued a ping command from PC4 to PC1 `ping 10.0.1.10` with no time limitation. Then, we disconnected the ethernet cable connected to interface eth0/0 on Router4. We observed the "Destination Host Unreachable" messages. A couple of minutes later, the ping command was successful again. We started to observe ICMP echo reply messages again "icmp_seq=# ttl=61 time=#.# ms" at PC4. This indicated that an alternate path had been found between PC4 and PC1. We stopped the ping command with Ctrl-C and saved the ping messages and the ping statistics as ex3b4pingpc4.txt. -------------------------- 10.0.1.10 ping statistics --------------------------- 229 packets transmitted, 26 received, +117 errors, 88% packet loss, time 228973ms rtt min/avg/max/mdev = 0.537/0.760/2.144/0.388 ms, pipe 4 -------------------------------------------------------------------------------- There were 229 packets transmitted and 26 received. So there were 203 packets lost. The time interval of each packet was 1 sec. So it took 3 min 26 sec to reestablish the connection. So RIP took 3 min 26 sec to update the routing tables. [Exercise 4A] We used a ethernet cable to connect the eth1 of PC3 to the switch that was connected to PC1. We used command `ifconfig eth1 10.0.1.11/24` to configure the eth1 on PC3. We issued commands to start the zebra and the ripd processes on PC3. We also enabled the IP forwarding on PC3. We then connected to the ripd processes via Telnet. The commands we used were: on PC3: `/etc/rc.d/init.d/zebra restart` on PC3: `/etc/rc.d/init.d/ripd restart` on PC3: `echo "1" > /proc/sys/net/ipv4/ip_forward` on PC3: `telnet localhost 2602` We issued the following commands to enable RIP on both interfaces of PC3. Since PC3 was set up as an IP router, the interfaces were enabled in the active mode. on PC3: `enable` on PC3: ripd# `config t` on PC3: ripd(config)# `router rip` on PC3: ripd(config-router)# `version 2` on PC3: ripd(config-router)# `network 10.0.0.0/8` on PC3: ripd(config-router)# `no passive-interface eth0` on PC3: ripd(config-router)# `no passive-interface eth1` on PC3: ripd(config-router)# `redistribute connected` on PC3: ripd(config-router)# `end` We started wireshark on both interfaces of PC3. We set a display filter, rip. Then we issued command `netstat -rn` on PC1 and PC4 to observe the changes of the routing tables. We observed that PC1 changed to use PC3, gateway 10.0.1.11, to get to network 10.0.3.0 instead of using Router 1 as the gateway the get to network 10.0.3.0. PC4 also changed to go through Router3 plus PC3 to get to network 10.0.1.0 instead of using Router3 plus Router2 plus Router1 to get to network 10.0.1.0. [Exercise 4B] We used the following command to configure the routers. We set the hold-down timer to 0 and disabled the triggered updates on all routers. on PC1: `minicom` username: cisco password: cisco yourname# config t yourname(config)# ip routing yourname(config)# router rip yourname(config-router)# version 2 yourname(config-router)# network 10.0.0.0 yourname(config-router)# timers basic 30 180 0 240 yourname(config-router)# flash-update-threshold 30 yourname(config-if)# end yourname# clear ip route * We also used the following commands to make Router1 unattractive by increasing the cost metric of both interfaces at Router1 from 1 to 10. yourname# config t yourname(config)# router rip yourname(config-router)# offset-list 0 out 10 eth0/0 yourname(config-router)# offset-list 0 out 10 eth0/1 yourname(config-if)# end yourname# clear ip route * We confirmed the configuration by issuing a traceroute from PC1 to PC4. We observed that all packets from PC1, network 10.0.1.0, went through PC3 instead of Router1. We started wireshark on PC3 interface eth0. We set the display filter to be rip. Then we issued a ping command from PC2 to PC1, `ping 10.0.1.10`, with no time limitation. We also enabled the debugging mode of RIP on Router3. This was done to have Router3 display all received RIP packets. We used command `debug ip rip` on Router3. Then, we disabled the connection between PC3 interface eth1 and network 10.0.1.0 using command `ifconfig eth1 down` on PC3. We obsvered the "Destination Host Unreachable" messages and "Network is unreachable" messages. After several minutes, we started to observe ICMP echo replay packets "icmp_seq=# ttl=61 time=#.# ms" again. We calculated the time for RIP to reestablish the routing tables. The time was 2 min 49 sec. We saved the debug messages on Router3 as ex4b9debug.txt. We also saved the RIP packets that explained the count-to-infinity problem as ex4b10pc3.txt. We saved all packets with detailed information. I cleaned it up and saved the six packets that explained the problem as ex4b10wireshark.txt. No. Time Source Destination Protocol Info 66 58.801925 10.0.3.10 224.0.0.9 RIPv2 Response : (sniped) : Routing Information Protocol Command: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: 10.0.1.0, Metric: 1 Address Family: IP (2) Route Tag: 0 IP Address: 10.0.1.0 (10.0.1.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 1 IP Address: 192.168.122.0, Metric: 1 Address Family: IP (2) Route Tag: 0 IP Address: 192.168.122.0 (192.168.122.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 1 No. Time Source Destination Protocol Info 130 85.561005 10.0.3.10 224.0.0.9 RIPv2 Response : (sniped) : Routing Information Protocol Command: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: 10.0.1.0, Metric: 16 Address Family: IP (2) Route Tag: 0 IP Address: 10.0.1.0 (10.0.1.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 16 No. Time Source Destination Protocol Info 131 87.560575 10.0.3.3 224.0.0.9 RIPv2 Response : (sniped) : Routing Information Protocol Command: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: 10.0.1.0, Metric: 16 Address Family: IP (2) Route Tag: 0 IP Address: 10.0.1.0 (10.0.1.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 16 No. Time Source Destination Protocol Info 132 87.561441 10.0.3.2 224.0.0.9 RIPv2 Response : (sniped) : Routing Information Protocol Command: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: 10.0.1.0, Metric: 16 Address Family: IP (2) Route Tag: 0 IP Address: 10.0.1.0 (10.0.1.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 16 No. Time Source Destination Protocol Info 133 89.802881 10.0.3.10 224.0.0.9 RIPv2 Response : (sniped) : Routing Information Protocol Command: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: 10.0.1.0, Metric: 16 Address Family: IP (2) Route Tag: 0 IP Address: 10.0.1.0 (10.0.1.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 16 IP Address: 192.168.122.0, Metric: 1 Address Family: IP (2) Route Tag: 0 IP Address: 192.168.122.0 (192.168.122.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 1 No. Time Source Destination Protocol Info 135 90.717042 10.0.3.2 224.0.0.9 RIPv2 Response : (sniped) : Routing Information Protocol Command: Response (2) Version: RIPv2 (2) Routing Domain: 0 IP Address: 10.0.1.0, Metric: 12 Address Family: IP (2) Route Tag: 0 IP Address: 10.0.1.0 (10.0.1.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 0.0.0.0 (0.0.0.0) Metric: 12 From looking at the "Routing Information Protocol" section of these six packets, we observed that the "Metric" value of network 10.0.1.0 started from 1, and it changed to 16. At the end, it changed again from 16 to 12. PC3 was directly connected to network 10.0.1.0 at first, so the metric was 1 because there was one hop. Then the connection of PC3 interface 1 was disconnected from network 10.0.1.10. The metric therefore was changed to 16, which is the infinity metric for RIP protocol. When the routing table stabalized, PC3 had to change to go through Router1 in order to reach network 10.0.1.0. Router1 had a metric 10. This information was passed to PC3 as 10+1. The one was added because Router1 was one hop away from PC3. Also, the inner hop needed to be counted, so the metirc to reach network 10.0.1.0 changed to 10+1+1=12. This is the final stablized routing entry for network 10.0.1.0. [Exercise 4C] We changed the configurations of the routers to enable the triggered updates and then set the hold-down timer to a non-zero value. We used commands: yourname# config t yourname(config)# ip routing yourname(config)# router rip yourname(config-router)# version 2 yourname(config-router)# network 10.0.0.0 yourname(config-router)# timers basic 30 180 60 240 yourname(config-router)# flash-update-threshold 0 yourname(config-if)# end We used command `show ip protocols` to have a look at the RIP timers. It was correctly set to 60. We also used traceroute from PC1 to PC4 to confirm that PC3's interface 1 was up. We observed that the packets from PC1 went through PC3 to reach the network 10.0.4.0. Then, we repeated the previous exercise with this new setup. We saved the debug messages ex4cdebugpc1.txt. We still waited for about 3 minutes for the connection of PC3 to network 10.0.1.0 to reestablish.