Yu Cheng (Jade) ICS 351 Lab Report 3 part 2 October 4, 2008 [Exercise 5] 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 eh0 10.0.1.10/24` on PC2: `ifconfig eh0 10.0.2.10/24` on PC3: `ifconfig eh0 10.0.3.10/24` on PC4: `ifconfig eh0 10.0.4.10/24` We used the following commands to configure the IP addresses and interfaces on the routers: on PC1: `minicom` username: cisco password: cisco yourname# configure t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# interface FastEthernet0/0 yourname(config-if)# ip address 10.0.1.1 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# ip address 10.0.2.1 255.255.255.0 yourname(config-if)# no shutdown yourname(config)# interface FastEthernet0/0 yourname(config-if)# ip address 10.0.3.1 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# ip address 10.0.2.2 255.255.255.0 yourname(config-if)# no shutdown yourname(config)# interface FastEthernet0/0 yourname(config-if)# ip address 10.0.3.3 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# ip address 10.0.4.3 255.255.255.0 yourname(config-if)# no shutdown We used the ping commands to make sure the set up was all correct. The ping commands were all successful. The commands were: on PC1: `ping -c 2 10.0.1.1` on PC2: `ping -c 2 10.0.2.1` on PC2: `ping -c 2 10.0.2.2` on PC3: `ping -c 2 10.0.3.2` on PC3: `ping -c 2 10.0.3.3` on PC4: `ping -c 2 10.0.4.3` We deleted all the routing table entries of the PCs using the command on PC#: `route del default`. We deleted all the ARP cache entries of the PCs using the command on PC#: `arp -d`. We deleted the routing cache using the command: on PC#: `echo "1" > /proc/sys/net/ipv4/route/flush`. We confirmed the deletion using the commands: on PC#: `netstat -r` on PC#: `arp -a` on PC#: `route -C` We also deleted all the routing table entries of the routers using the command: yourname(config)# no ip routing` and `ip routing. We deleted the routing cache on the routers using the command: yourname# clear arp-cache We confirmed the deletion using the commands: yourname# show ip route yourname# show ip cache We built a new static routing entry on Router1 in such a way that Router1 would direct the packets with a destination of network 10.0.3.0 through Router2, 10.0.2.2. We used the command: yourname(config)# ip route 10.0.3.0 255.255.255.0 10.0.2.2 We set up the routing table of PC2 in such a way that PC2 will route the packets to the destination of PC3 through Router1, 10.0.2.1, instead of using a more direct way by going through Router2, 10.0.2.2. We used command: on PC2: `add -net 10.0.3.0/24 gw 10.0.2.1` We saved the contents of the routing table and the routing cache of Router1, Router2, and PC2 as ex5-4.txt. 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/1 S 10.0.3.0 [1/0] via 10.0.2.2 C 10.0.1.0 is directly connected, FastEthernet0/0 IP routing cache 0 entries, 0 bytes 10.0.0.0/24 is subnetted, 2 subnets C 10.0.2.0 is directly connected, FastEthernet0/1 C 10.0.3.0 is directly connected, FastEthernet0/0 IP routing cache 0 entries, 0 bytes We didn't save the routing table from PC2. The routing table below is my guess. [root@PC2 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.0.3.0 10.0.2.1 255.255.255.0 UG 0 0 0 eth0 We used wireshark to capture the network traffic while issuing a ping from PC2 to PC3 using the command `ping -c 5 10.0.3.10`. We lost the data of this section. I think the routing cache before the ping would be empty, and right after the ping, it would look like: [root@PC2 ~]# route -C Kernel IP routing cache Source Destination Gateway Flags Metric Ref Use Iface PC2 PC2 PC2 l 0 0 5 lo 10.0.2.10 10.0.3.10 10.0.2.2 l 0 0 2 lo This content would be different from the corrsponding entry in PC2's routing table: Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.3.0 10.0.2.1 255.255.255.0 UG 0 0 0 eth0 After some minutes, the routing cache entry would be deleted. Question 1: The contents of the routing table were the same before and after the ICMP route redirect message. The contents of the routing cache were different immediately after the ICMP route redirext message. A new entry was added in the routing cache with a source "10.0.2.10", a destination "10.0.3.10", and a gateway "10.0.2.2". Question 2: The new entry added after the ICMP redirecting message was removed. Question 3: If there is a more direct path to send packets from the source host to the destination host, the router that's sitting in between would send out an ICMP route redirect message to the source host. This message would inform the source host to route through another router, which would provide a more direct path to that certain destination host. This is done by the router at the same time when it correctly sends out the already received packets to the next hop, and from then on, the packets from this source host to this destination host would not go through this router until the routing cache entry was expired and deleted. In this example, PC2 sent packets with a destination of PC3 to Router1 because Router1 was configured as the gateway to the network 10.0.3.0 from PC2. Router1 directed the packets to Router2 because Router2 was configured as the gateway to network 10.0.3.0 from Router1. At the same time, Router1 sent an ICMP redirect message to PC2 informing that going through Router2 wass a more direct way to reach PC3, network 10.0.3.0. PC2, therefore, added this information to its routing cache. A few minutes later, while there was no network traffic from PC2 to PC3, this routing cache entry was deleted. [Exercise 6] We added Router4 in this picture. We configured Router4 using the commands: yourname(config)# interface FastEthernet0/0 yourname(config-if)# ip address 10.0.4.4 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# ip address 10.0.2.4 255.255.255.0 yourname(config-if)# no shutdown We displayed the routing table of Router4 using the command: yourname# show ip route 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/1 C 10.0.4.0 is directly connected, FastEthernet0/0 We used a seriers of commands to configure Router2, Router3, and Router4 so that an ICMP echo request message generated by a ping from PC4 to PC1 created an infinite loop. The commands were: on Router4: `yourname# ip route 10.0.1.0 255.255.255.0 10.0.2.2` on Router2: `yourname# ip route 10.0.1.0 255.255.255.0 10.0.3.3` on Router3: `yourname# ip route 10.0.1.0 255.255.255.0 10.0.4.4` on PC4: `route add -net 10.0.1.0/24 gw 10.0.4.4` We issued a traceroute `traceroute 10.0.1.10` to verify that a loop existed. We observed a loop with Router3, Router4, and Router2. Router2 didn't have a record in PC4, so when the hop wass Router2 the traceroute message showed like "* * *". We captured the network taffic while issuing a ping command from PC4 to PC1. I think we lost the wireshark data. We did observe the ICMP echo request message was looping and didn't receive any response. We saved the routing tables of Router2, Router3, and Router4 as ex6-5-routingtables.txt. 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/1 C 10.0.3.0 is directly connected, FastEthernet0/0 S 10.0.1.0 [1/0] via 10.0.3.3 10.0.0.0/24 is subnetted, 3 subnets C 10.0.3.0 is directly connected, FastEthernet0/0 S 10.0.1.0 [1/0] via 10.0.4.4 C 10.0.4.0 is directly connected, FastEthernet0/1 10.0.0.0/24 is subnetted, 4 subnets C 10.0.2.0 is directly connected, FastEthernet0/1 S 10.0.3.0 [1/0] via 10.0.2.2 S 10.0.1.0 [1/0] via 10.0.2.2 C 10.0.4.0 is directly connected, FastEthernet0/0 We saved two ICMP echo request messages captured on PC4 as ex6-5-1.txt and ex6-5-2.txt. We observed 10 ICMP request messages. The default TTL duration was 30 hops. The loop consisted of 3 hops. So each of them would send out 10 ICMP request messages. The number of total hops that the message went through was 30. Each ICMP request message had a "Time to live: #" tag indicating how many hops more this message was able to travel. When this number reached 0, the message expired and dropped. Question 1: No, the ICMP packets that we saved were different. They had different "NO.", different "Time", and different "Time to live: #" values. Question 2: The default TTL was 30. We didn't change it, so the messages could go through a maximum number of 30 hops. After that, the messages would expire and drop. That's why packets wouldn't loop forever. [Excercise 7] We connected the ethernet interfaces of the PCs and the router. We used the following commands to configure the IP addresses and the interfaces on the PCs: on PC1: `ifconfig eh0 10.0.1.10/24` on PC2: `ifconfig eh0 10.0.2.10/24` on PC3: `ifconfig eh0 10.0.2.137/29` on PC4: `ifconfig eh0 10.0.2.139/24` We used the following commands to configure the IP addresses and interfaces on the router: on PC1: `minicom` username: cisco password: cisco yourname# configure t yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# interface FastEthernet0/0 yourname(config-if)# ip address 10.0.1.1 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# ip address 10.0.2.138 255.255.255.0 yourname(config-if)# no shutdown We used the following commands to add Router1 as the default gateway on all the PCs: on PC1: `route add default gw 10.0.1.1` on PC2: `route add default gw 10.0.2.138` on PC3: `route add default gw 10.0.2.138` on PC4: `route add default gw 10.0.2.138` We cleared the ARP tables on all the hosts using the command `arp -d`. We verified the deletion `ar -a`. We saved the ARP tables, routing tables, and routing cache for each host as ex7-3-cPC1.txt, ex7-3-cPC3.txt, and ex7-3-cPC4.txt. [root@PC1 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.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 0.0.0.0 10.0.1.1 0.0.0.0 UG 0 0 0 eth0 [root@PC3 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.2.136 0.0.0.0 255.255.255.248 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 0.0.0.0 10.0.2.138 0.0.0.0 UG 0 0 0 eth0 [root@PC4 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.2.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 0.0.0.0 10.0.2.138 0.0.0.0 UG 0 0 0 eth0 The ARP tables and the routing cache were empty initialy. We didn't save any information from PC2. I think the routing cache and ARP table would have been empty. The routing table would have looked like: [root@PC2 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.2.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 0.0.0.0 10.0.2.138 0.0.0.0 UG 0 0 0 eth0 -------------------------------------PART 1------------------------------------- We issued a ping command from PC1 to PC2 and PC3: on PC1: `ping -c 2 10.0.2.10` on PC1: `ping -c 2 10.0.2.137` From PC1's prespective, these packets were sent to another network 10.0.2.0. They were sent to the default gateway, 10.0.1.1. From Router1's prespective, both of those IP addresses were directly reachable. So, packets were sent to their final destinations. PC1 IP address: 10.0.1.10 => 00001010,00000000,00000001,00001010 PC1's Newmask: 255.255.255.0 => 11111111,11111111,11111111,00000000 --------------------------------------- PC1's Network: => 00001010,00000000,00000001,00000000 => 10.0.1.0 PC2 IP address: 10.0.2.10 => 00001010,00000000,00000010,00001010 PC1's Newmask: 255.255.255.0 => 11111111,11111111,11111111,00000000 --------------------------------------- PC2's Network: => 00001010,00000000,00000010,00000000 => 10.0.2.0 PC3 IP address: 10.0.2.137 => 00001010,00000000,00000010,10001001 PC1's Newmask: 255.255.255.0 => 11111111,11111111,11111111,00000000 --------------------------------------- PC3's Network: => 00001010,00000000,00000010,00000000 => 10.0.2.0 We saved PC1's routing cache after the ping commands as ex7-3-cPC1.txt. (I believe we mis-configured PC1's IP address to 10.0.1.11. I changed it back in the contents below.) [root@PC1 ~]# route -C Kernel IP routing cache Source Destination Gateway Flags Metric Ref Use Iface PC1 PC1 PC1 l 0 0 5 lo 10.0.2.137 10.0.1.10 10.0.1.10 l 0 0 2 lo PC1 PC1 PC1 l 0 0 3 lo PC1 PC1 PC1 l 0 0 1 lo 10.0.1.10 10.0.2.10 10.0.1.1 0 0 1 eth0 10.0.2.10 10.0.1.10 10.0.1.10 l 0 0 2 lo 10.0.1.10 10.0.2.10 10.0.1.1 0 0 5 eth0 There were four components of the network traffic of the ping commands. We should have observed information for all four of them in the routing cache. When the destination was PC1 itself, PC1's IP address, 10.0.1.10, was assigned as the gateway. When the destintion was PC2, PC1's default gateway, 10.0.1.1, was assigned as the gateway. I think there should have been another entry with a destination of PC3, 10.0.2.137, and gateway, 10.0.1.1. When new network traffic occured, PC1 would look at the routing cache first and try to find an exact match in its routing cache table. If it failed to find any match in the routing cache table, it would go look for the entries in the un-cached routing table. -------------------------------------PART 2------------------------------------- We issued a ping command from PC3 to PC4: on PC3: `ping -c 2 10.0.2.139` From PC3's prespective, these packets were sent to the same network, 10.0.2.138. PC3 IP address: 10.0.2.137 => 00001010,00000000,00000001,10001001 PC3's Newmask: 255.255.255.248 => 11111111,11111111,11111111,11111000 --------------------------------------- PC3's Network: => 00001010,00000000,00000001,10001000 => 10.0.1.138 PC4 IP address: 10.0.2.139 => 00001010,00000000,00000010,10001011 PC3's Newmask: 255.255.255.248 => 11111111,11111111,11111111,11111000 --------------------------------------- PC4's Network: => 00001010,00000000,00000010,10001000 => 10.0.2.138 So the router was not involved. The routing cache contained only the information for PC3 and PC4. We saved the routing cache on PC3 after the ping command as ex7-4-e.txt. [root@PC3 ~]# route -C Kernel IP routing cache Source Destination Gateway Flags Metric Ref Use Iface 10.0.2.139 10.0.2.137 10.0.2.137 il 0 0 3 lo 10.0.2.137 10.0.2.139 10.0.2.139 0 0 3 eth0 10.0.2.137 10.0.2.139 10.0.2.139 0 0 0 eth0 PC3 PC3 PC3 l 0 0 3 lo 10.0.2.137 10.0.2.139 10.0.2.139 0 0 0 eth0 From the routing cache, we observed two IP addresses. When the destination was PC3 itself, its own IP address, 10.0.2.137, was assignmed as the gateway. When the destination was PC4, PC4's IP address was assignmened as the gateway because it was a direct connection between these two PCs. -------------------------------------PART 3------------------------------------- We issued a ping command from PC3 to PC2: on PC3: `ping -c 2 10.0.2.10` From PC3's prespective, these packets were sent to a different network, 10.0.2.8. PC3 IP address: 10.0.2.137 => 00001010,00000000,00000001,10001001 PC3's Newmask: 255.255.255.248 => 11111111,11111111,11111111,11111000 --------------------------------------- PC3's Network: => 00001010,00000000,00000001,10001000 => 10.0.1.138 PC2 IP address: 10.0.2.10 => 00001010,00000000,00000010,00001010 PC3's Newmask: 255.255.255.248 => 11111111,11111111,11111111,11111000 --------------------------------------- PC2's Network: => 00001010,00000000,00000010,00001000 => 10.0.2.8 Therefore, the packets would be sent from PC3 to its default gateway, 10.0.2.138. At Router1, PC2's IP address was resolved as 10.0.2.0 and sent to the final destination. We saved the routing cache on PC3 after the ping command as ex7-5-PC3.txt. [root@PC3 ~]# route -C Kernel IP routing cache Source Destination Gateway Flags Metric Ref Use Iface 10.0.2.139 10.0.2.137 10.0.2.137 il 0 0 3 lo 10.0.2.137 10.0.2.139 10.0.2.139 0 0 3 eth0 PC3 PC3 PC3 l 0 0 11 lo 10.0.2.138 10.0.2.137 10.0.2.137 il 0 0 2 lo 10.0.2.137 10.0.2.10 10.0.2.138 0 0 3 eth0 10.0.2.137 10.0.2.10 10.0.2.138 0 0 0 eth0 PC3 PC3 PC3 l 0 0 3 lo 10.0.2.10 10.0.2.137 10.0.2.137 l 0 0 3 lo 10.0.2.137 10.0.2.139 10.0.2.139 0 0 0 eth0 Apparently, this routing table contained the information from the previous part. When the destination was PC3 itself, its own IP address, 10.0.2.137, was assigned as the gateway. When the destination was PC4, PC4's IP address was assigned as the gateway because it was a direct connection between the two PCs. When the destination was PC2, 10.0.2.10, Router1 10.0.2.138 was assigned as the gateway. Question 1: Most of the phenomena were explained as above. On the captured wireshark traffic on PC1, at first there were two ICMP requests followed by one ICMP reply. After the connection was made, one replay came after one request. It's unclear to me why. We didn't observe any ICMP packets on PC4. We must have forgotten to run the caputure on PC4 in permiscuous mode. That would have revealed to us whether or not the first request made it past Router1. Question 2: If PC3 had no default entry: - PC1's ping to PC2 would have still gone through because Router1 eth1 and PC3 were in a direct connection. - PC1's ping to PC3 would also have gone through because Router1 eth1 and PC3 were in a direct connection. - PC3's ping to PC4 would also have gone through because they were within the same network. Packets would go directly from PC3 to PC4. - PC3's ping to PC2, however, wouldn't have gone through because they were not in the same network. PC3 had to send the packets to its default gateway first. If there were no default gateway existing, PC3 couldn't have sent any packets to PC2.