Yu Cheng (Jade) ICS 351 Lab Report 3 part 1 September 28 [Exercise 1A] 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 PC1: `ifconfig eh0 10.0.1.11/24` on PC2: `ifconfig eh0 10.0.1.21/24` on PC2: `ifconfig eh1 10.0.2.22/24` on PC4: `ifconfig eh0 10.0.3.41/24` We started wireshark on PC1. We issued the following ping commands: on PC1: `ping -c 5 10.0.1.21` on PC1: `ping -c 5 10.0.2.1` on PC1: `ping -c 5 10.0.3.41` We saved the output of the ping commands as file ex1a_ping.txt. We saved the wireshark traffic during issuing ping commands as file ex1a_wireshark.txt. Question 1: The output of `ping -c 5 10.0.1.21` command was: PING 10.0.1.21 (10.0.1.21) 56(84) bytes of data. 64 bytes from 10.0.1.21: icmp_seq=1 ttl=64 time=0.878 ms 64 bytes from 10.0.1.21: icmp_seq=2 ttl=64 time=0.333 ms 64 bytes from 10.0.1.21: icmp_seq=3 ttl=64 time=0.330 ms 64 bytes from 10.0.1.21: icmp_seq=4 ttl=64 time=0.332 ms 64 bytes from 10.0.1.21: icmp_seq=5 ttl=64 time=0.340 ms The output of commands `ping -c 5 10.0.2.1` and `ping -c 5 10.0.3.41` were "connect: Network is unreachable" messages. Question 2: ARP and ICMP packets were captured while issuing command `ping -c 5 10.0.1.21`. No packets were captured while pinging the router or PC4. Question 3: I observed ARP and ICMP packets while pinging PC2 on its eh0 interface from PC1. They were ARP request and reply, and ICMP echo (ping) replies. Question 4: The router and PC4 were not reachable because they were not on the same network as PC1. PC1 IP address 10.0.1.11 => 00001010,00000000,00000001,00001011 Newmask: 255.255.255.0 => 11111111,11111111,11111111,00000000 --------------------------------------- Network => 00001010,00000000,00000001,00000000 => 10.0.1.0 Router IP address 10.0.2.1 => 00001010,00000000,00000010,00000001 Newmask: 255.255.255.0 => 11111111,11111111,11111111,00000000 --------------------------------------- Network => 00001010,00000000,00000010,00000000 => 10.0.2.0 PC4 IP address 10.0.3.14 => 00001010,00000000,00000011,00001011 Newmask: 255.255.255.0 => 11111111,11111111,11111111,00000000 --------------------------------------- Network => 00001010,00000000,00000011,00000000 => 10.0.3.0 [Exercise 1B] We changed the contents of file /proc/sys/net/ipv4/ip-forward using command: on PC1: `echo "1" > /proc/sys/net/ipv4/ip-forward` To make sure it worked. We ran command: on PC1: `cat /proc/sys/net/ipv4/ip-forward` The output was a single number "1". [Exercise 1C] We configured the routing table entries of PC1 and PC4 using the following commands: on PC1: `route add -net 10.0.2.0/24 gw 10.0.1.21` on PC1: `route add -net 10.0.3.0/24 gw 10.0.1.21` on PC4: `route add -net 10.0.2.0/24 gw 10.0.3.1` on PC4: `route add -net 10.0.1.0/24 gw 10.0.3.1` We also configured the routing table entries of the IP router PC2 using command: on PC2: `route add -net 10.0.3.0/24 gw 10.0.2.1` We displayed the routing table of PC1, PC2, and PC4 with command 'netstat -r'. We saved the output as file ex1c_PC1.txt and ex1c_PC4.txt. For some reason, we didn't save the routing table from PC2. [Exercise 2C] PC1 and the router were connected with a console cable from the console port of the router to the serial port of PC1. We issued command `minicom` on PC1 to start the router configuration. We skipped the steps of selecting the serial port and switching from user EXEC mode to privileged mode. We directly entered privileged mode using the username, cisco, and the password, cisco. From privileged mode we issued commands: yourname# configure terminal yourname(config)# no ip routing yourname(config)# ip routing yourname(config)# interface FastEthernet0/0 yourname(config-if)# ip address 10.0.2.1 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# interface FastEthernet0/1 yourname(config-if)# ip address 10.0.3.1 255.255.255.0 yourname(config-if)# no shutdown yourname(config-if)# end We issued the following command to check the changes made. yourname# show interfaces yourname# show running config The output includes information such as: interface FastEthernet0/0 ip address 10.0.2.1 255.255.255.0 interface FastEthernet0/1 ip address 10.0.3.1 255.255.255.0 Therefore we know that the configuration for the router interfaces was correct. [Exercise 2D] We displayed the contents of the routing table with command `show ip route`. We saved the output in file ex2d.txt. 10.0.0.0/24 is subnetted, 2 subnets C 10.0.2.0 is directly connected, FastEthernet0/0 C 10.0.3.0 is directly connected, FastEthernet0/1 Then we added routing entries to Router1 using commands: yourname# configure terminal yourname(config)# ip route 10.0.1.0 255.255.255.0 10.0.2.22 yourname(config)# ip route 10.0.2.0 255.255.255.0 10.0.2.22 yourname(config)# ip route 10.0.3.0 255.255.255.0 10.0.3.41 yourname(config)# exit yourname# show ip route We saved the output of the last command in the same file, ex2d.txt. 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/0 C 10.0.3.0 is directly connected, FastEthernet0/1 S 10.0.1.0 [1/0] via 10.0.2.22 Apparently, we didn't need to add network 10.0.2.0 and network 10.0.3.0. They were already within the same networks of the router's two interfaces. Question 1: The fields of the router's routing table changed by one item. We added one entry to the routing table. We told the router how to route the packets from network 10.0.1.0. [Excercise 3A] In order to test the network configuration, we issued a series of ping commands: on PC1: `ping -c 2 10.0.1.21` on PC1: `ping -c 2 10.0.2.1` on PC1: `ping -c 2 10.0.3.41` on PC2: `ping -c 2 10.0.2.1` on PC2: `ping -c 2 10.0.3.41` on PC4: `ping -c 2 10.0.2.1` There was no unreachable host or router. [Excercise 3B] We executed a traceroute command: on PC1: `traceroute 10.0.3.41` We saved the traceroute output in ex3b_PC1.txt. [root@PC1 ~]# traceroute 10.0.3.41 traceroute to 10.0.3.41 (10.0.3.41), 30 hops max, 40 byte packets 1 10.0.1.21 (10.0.1.21) 0.358 ms 0.208 ms 0.174 ms 2 10.0.2.1 (10.0.2.1) 1.026 ms 1.150 ms 1.130 ms 3 10.0.3.41 (10.0.3.41) 0.560 ms 0.422 ms 0.407 ms In Excercise 1C, we set up: on PC1: `route add -net 10.0.3.0/24 gw 10.0.1.21` on PC2: `route add -net 10.0.3.0/24 gw 10.0.2.1` So when trying to send packets to PC4 from PC1, packets would go through eth0 on PC2 with an IP address, 10.0.1.21. Then, they would go through eth0 on the router with an IP address, 10.0.2.1. Then, they would arrive at PC4. This process is shown in the traceroute output. We also saved the wireshark traffic while executing traceroute. We saved it as file ex3b-wireshark.txt. Commands to display the routing tables were issued on all three PCs and the router. We saved the output as ex3b_PC1.txt, ex3b_PC2.txt, and ex3b_PC4.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 10.0.2.0 10.0.1.21 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.1.21 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 [root@PC2 ~]# 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 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.0.3.0 10.0.2.1 255.255.255.0 UG 0 0 0 eth1 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 [root@PC4 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 10.0.3.1 255.255.255.0 UG 0 0 0 eth0 10.0.2.0 10.0.3.1 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 yourname#show ip route 10.0.0.0/24 is subnetted, 3 subnets C 10.0.2.0 is directly connected, FastEthernet0/0 C 10.0.3.0 is directly connected, FastEthernet0/1 S 10.0.1.0 [1/0] via 10.0.2.22 The network configuration was all correct according to the routing tables above. Question 1: The captured wireshark traffic consists of UDP packets from PC1 to PC4, ICMP packets back to PC1 from the router and PCs that were on the way to PC4, and ARP packets requesting the MAC address. PC1 sent out UDP packets to PC4 targeted at strange port numbers that we hoped nothing would be listening on. Traceroute transmits packets with small TTL values. Every router or PC that handles a packet subtracts one from the packet's TTL. If the TTL reaches zero, the packet are expired and discarded. The router or PCs that routed the packets before they reached PC4 sent ICMP time exceeded messages back to PC1. This is how traceroute gets information about the routers on the way from the host to the destination. PC4 ignored the packets after generating port unreachable messages. The port was the UDP port number that traceroute used on its first packet, and the port number was incremented by one for each subsequent packet. [Excercise 3C] We erased all ARP entries on all PCs and the router using commands `arp -d` and `clear arp_cache`. We started wireshark on both PC1 (eth0) and PC4 (eth0). On PC1 we issued command `ping -c 5 10.0.3.41`. We saved the wireshark traffic as file ex3c.txt. Question 1: Traffic captured on PC1 shows that the ARP request and response are between PC1 (10.0.1.11) and PC2 (10.0.1.21). The ICMP packets are between PC1 and PC4 (10.0.3.41). [Question 2] Traffic captured on PC4 shows that the ARP request and response are between PC4 (10.0.3.41) and the router (10.0.3.1). The ICMP packets are between PC1 (10.0.1.11) and PC4. [Question 3] The routing table tells which IP address is the next hop, so while sending the packets, PC1 needed to request the MAC address from the next hop, PC2. The same idea applied to PC4. The next hop for PC4 was the router, so it requested only the MAC address from the router. When the ARP tables on PC1, PC2, and the router were all set up, ICMP packets were sent. ICMP is an IP protocol, and the IP header contains only the final destination. Therefore ICMP packets show communication between only PC1 and PC4. [Excercise 3D] We added three non-existing routing entries into PC1's routing table: on PC1 `route add -net 10.0.0.0/16 gw 10.0.1.71` on PC1 `route add -host 10.0.3.9 gw 10.0.1.81` on PC1 `route add -net 10.0.3.0/24 gw 10.0.1.61` By looking at the routing table, we saw these IP addresses match with different entries: 10.0.3.9 matches with: 10.0.3.9 gw 10.0.1.81 (exact and best match) 10.0.3.0/24 gw 10.0.1.61 10.0.3.0/24 gw 10.0.1.21 (default) 10.0.0.0/16 gw 10.0.1.71 10.0.3.14 matches with: 10.0.3.0/24 gw 10.0.1.61 (best match) 10.0.3.0/24 gw 10.0.1.21 (default) 10.0.4.1 matches with: 10.0.0.0/16 gw 10.0.1.71 (only and best match) We issued several ping commands and captured the traffic while pinging. on PC1 `ping -c 1 10.0.3.9` on PC1 `ping -c 1 10.0.3.14` on PC1 `ping -c 1 10.0.4.1` None of these echo ping packets went through. We saved PC1's routing table: [root@PC1 ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.3.9 10.0.1.81 255.255.255.255 UGH 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.21 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.1.61 255.255.255.0 UG 0 0 0 eth0 10.0.3.0 10.0.1.21 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 10.0.0.0 10.0.1.71 255.255.0.0 UG 0 0 0 eth0 Question 1: We did not save the wireshark traffic for this exercise. The traffic showed only ARP request packets for those IP addresses but no response or anything else. That's because the best matches for these IP addresses in the routing table were mapped with non-existing next hops. Therefore, no response was received after the ARP request. Connections were not made. No further communication could go through. It looks like PC1 resolves multiple matches in the routing table by returning the best match. If it can't transmit packets, it just fails. The best match is the longest match among all of the entries in the routing table. [Excercise 3E] We executed the following commands to delete the entries added in Excercise 3D. on PC1 `route del -net 10.0.3.9/32` on PC1 `route del -net 10.0.3.0/24` on PC1 `route del -net 10.0.0.0/16` We issued commands to add default routes on PC1 and PC2: on PC1 `route add default gw 10.0.1.21` on PC1 `route add default gw 10.0.2.1` We started three wireshark windows on PC1 (eth0) and PC2 (eth0, eth1) to capture the traffic. We issued a ping command to a network that did not exist: on PC1 `ping -c 5 10.0.10.110` We saved the wireshark traffic separately as ex3e_PC1.txt, ex3e_PC2eth0.txt, and ex3e_PC2eth1.txt. Question 1: The output was a message "connect: Network is unreachable". Question 2: The ICMP echo request traveled to the router interface, eth0. When the command was issued, PC1 examined its routing table. Nothing matched, but PC1 had a default gateway, which was PC2 eth0. So, the request was sent to PC2. PC2 examined its routing table, nothing mathed, but PC2 also had a default gateway, which was the router eth0. So, the request was sent to the router, and the router sent back an ICMP message saying the destination was unreachable, and that was the end of the conversation. Question 3: There was an ICMP packet sent back to PC1 from the router (10.0.2.1) with a message "destination unreachable, host unreachable". [Excercise 4] We issued commands to erase both the ARP table and the routing table of PC4: on PC4 `arp -d` on PC4 `route del -net 10.0.1.0/24` on PC4 `route del -net 10.0.2.0/24` on PC4 `route del -net 10.0.3.0/24` on PC4 `route del -net 192.168.122.0/24` After deleting all the entries, we used command `netstat -r` to make sure the routing table was empty. We issued a command to change the netmask of PC4: on PC4 `ifconfig eth0 10.0.3.41/24` We started wireshark on PC4 (eth0), PC2 (eth1), and PC1 (eth0). We set the display filter as "icmp or arp". We issued a ping command and captured the network traffic. We saved the files as ex4_5wiresharkPC1.txt, ex4_5wiresharkPC2.txt, and ex4_5wiresharkPC4.txt. The ARP table of PC4 was saved as ex4_5arp.txt: [root@PC4 ~]# arp -a ? (10.0.1.11) at 00:1B:D4:3C:33:11 [ether] on eth0 Question 1: By looking at the captured traffic from PC4 and the ARP table of PC4, PC1 was associated with the MAC address 00:1B:D4:3C:33:11. By looking at the captured traffic from PC2, this MAC address is also the MAC address of the router whose IP address is 10.0.2.1. They differed by one digit because they were the MAC addresses of the interfaces that connected the router to two different networks. My guess is the MAC addresses were issued at the same time when they manufactured the router. Source Destination Protocol Info 00:1b:d4:3c:33:10 00:04:76:cd:61:58 ARP 10.0.2.1 is at 00:1b:d4:3c:33:10 Source Destination Protocol Info 00:1b:d4:3c:33:11 00:02:a5:02:29:d0 ARP 10.0.1.11 is at 00:1b:d4:3c:33:11 What happend was PC4 falsely believed that PC1 was directly reachable because PC4 was assigned a netmask containing all the subnets 10.0.1.0/24 and 10.0.2.0/24. PC4, however, had to go through the router and PC2 in order to deliver packets to PC1, while PC4 didn't have the default gateway to the router. PC4 sent out ARP requests addressed to PC1. The router received it, and the router knew that PC1 was reachable, so the router sent back its MAC address as a proxy ARP reply. PC4 put this MAC address in its ARP table to pair up with PC1's IP address. Form then on, PC4 just sent packets to the router thinking that was PC1, while the router sent them to PC2 and then to PC1.