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.
