Yu Cheng (Jade) ICS 351 Lab Report 6 December 6, 2008 [Exercise 1A] We connected the ethernet interfaces of the PCs. We used the following commands to configure the interfaces of the PCs: on PC1: `ifconfig eth0 10.0.1.11/24` on PC2: `ifconfig eth0 10.0.1.21/24` on PC2: `ifconfig eth1 10.0.1.22/24` on PC3: `ifconfig eth1 10.0.1.31/24` We also recorded the MAC addresses on all PCs: -------------------------------------------------------------------------------- Linux PC MAC Address of eth0 MAC Address of eth1 PC1 00:02:A5:00:B8:87 00:50:DA:67:BC:95 PC2 00:02:A5:57:1B:8A 00:04:76:CD:61:58 PC3 00:02:A5:17:5D:73 00:10:4B:9B:38:3F PC4 00:02:A5:02:29:D0 00:10:4B:6F:8D:DB -------------------------------------------------------------------------------- [Exercise 1B] We started gbrctl on PC2 using command `gbrct1`. We added a bridge and named it "Bridge 1". We then configured this bridge by adding its two interfaces. For this exercise, we didn't use STP. The STP button was, therefore, disabled. We used command `ifconfig Bridge1 up` to activate the bridge we added in PC2. [Exercise 1C] We started the wireshark on PC1's and PC3's interface eth0. We issued ping commands from PC1 to PC2, `ping 10.0.1.21`, and from PC3 to PC2, `ping 10.0.1.22`. They both failed to communicate because once the bridging was activated on PC2, the configured IP addresses should be disabled. We then cleared the arp tables using command `arp -d` on both PC1 and PC3. We issued a ping command from PC1 to PC3. It went through successfully. We saved the output as ex1c.txt. I also attached the ping staticstics below. -------------------------- 10.0.1.31 ping statistics --------------------------- 1 packets transmitted, 1 received, 0% packet loss, time 10ms rtt min/avg/max/mdev = 1.066/1.066/1.066/0.000 ms -------------------------------------------------------------------------------- Question 4-a, 4-b PC2 did not modify the source and destination MAC and IP addresses. Attached below is the MAC and IP addresses information in the icmp echo reply message. ------------------------------- icmp echo reply -------------------------------- Destination: HewlettP_00:b8:87 (00:02:a5:00:b8:87) Source: HewlettP_17:5d:73 (00:02:a5:17:5d:73) : Internet Protocol, Src: 10.0.1.31 (10.0.1.31), Dst: 10.0.1.11 (10.0.1.11) -------------------------------------------------------------------------------- The source and desination MAC and IP addresses in the icmp echo reply packet are shown as above. They are the MAC and IP addresses of PC1 and PC3. PC2 did not show at all. If PC2 was configured as a router, it would manipulate the MAC address. In the icmp reply packet, it would show PC2's MAC address as the destination MAC address. The source and destination IP addresses would still be PC1 and PC3's. We issued a traceroute command form PC1 to PC3. It went through successfully. We appended the output in file ex1c.txt. I also attached below the output. ----------------------------- traceroute 10.0.1.31 ----------------------------- traceroute to 10.0.1.31 (10.0.1.31), 30 hops max, 40 byte packets 1 10.0.1.31 (10.0.1.31) 0.696 ms 0.630 ms 0.542 ms -------------------------------------------------------------------------------- Question 5-a PC2 is invisible in this saved traceroute output. That is because PC2 was configured as a switch not a router. This is why it is called transparent bridge. Question 5-b If PC2 is configured as a IP router, we would see one more entry in the traceroute output indicating PC2. We changed the IP address of PC3 to 10.0.2.12/24. The previous ping command failed in this case. Because, the bridge thought PC3 was in another network, although they were directly connected, PC2 did not even try to forward the packets. We save the wireshark captured traffic. Copied below is an icmp echo request packet's source and desitnation MAC and IP addresses information. As we can see the request was from PC1 to PC2. The MAC addresses also indicate PC1 eth0 to PC2 eth0. ------------------------------- icmp echo reply -------------------------------- Destination: HewlettP_57:1b:8a (00:02:a5:57:1b:8a) Source: HewlettP_00:b8:87 (00:02:a5:00:b8:87) : Internet Protocol, Src: 10.0.1.11 (10.0.1.11), Dst: 10.0.1.21 (10.0.1.21) -------------------------------------------------------------------------------- [Exercise 1D] In this exercise, we had a look at the MAC forwarding table in PC2. The MAC forwarding table for bridge functions as the routing table in a router. We observed two entries: ----------------------------- MAC forwarding table ----------------------------- Port no Mac address Is local? Ageing timer 1 00:02:A5:57:1B:8A Yes 0.00 2 00:04:76:CD:61:58 Yes 0.00 -------------------------------------------------------------------------------- Both of the two entries were local MAC addresses of PC2. Because the ageing timers were set to zero. The entries other than local MAC addresses were immediately deleted after adding. We then disabled the bridge on PC2. This was down with two steps. First we used command `ifconfig Bridge1 down` on PC2. Then we seleted delete for Bridge1 in gbrctl. We issued ping commands to verify the deletion. on PC1: ping -c 1 10.0.1.21 on PC3: ping -c 1 10.0.1.22 The first command went through as we expected. The second one failed. We think this might be a bug in the adding and deleting bridges process. When the bridge was activated, the IP addresses should be disabled as we observed previously. When it was deleted, the IP addresses should come back to working mode. We then issued a ping command from PC1 to PC3 `ping -c 1 10.0.1.31`. This command failed as expected because PC2 was not forwarding packets. [Exercise 2] We connected the ethernet interfaces of the PCs and Router1. We used the following commands to configure the interfaces of the PCs: on PC1: `ifconfig eth0 10.0.1.11/24` on PC2: `ifconfig eth0 10.0.2.21/24` on PC3: `ifconfig eth1 10.0.1.31/24` on PC4: `ifconfig eth1 10.0.1.41/24` We then used command `show interfaces` on the routers in order to record their MAC addresses on both interfaces. ------------------------- MAC Adresses of the routers -------------------------- Router MAC Address of eth0 MAC Address of eth1 Router1 00:1B:D4:3C:33:10 00:1B:D4:3C:33:11 Router2 00:1B:54:DD:7C:50 00:1B:54:DD:7C:51 Router3 00:1B:D4:DB:9A:70 00:1B:D4:DB:90:71 Router4 00:1B:D4:DB:94:50 00:1B:D4:DB:94:51 -------------------------------------------------------------------------------- We then used the following commands to configure Router1 as a bridge. Router1 yourname# config t yourname(config)# no ip routing yourname(config)# bridge 1 protocol ieee yourname(config)# bridge 1 priority 128 yourname(config)# interface fa0/0 yourname(config-if)# bridge-group 1 yourname(config-if)# bridge-group 1 spanning-disabled yourname(config-if)# no shutdown yourname(config-if)# interface fa0/1 yourname(config-if)# brige-group 1 yourname(config-if)# bridge-group 1 spanning-disabled yourname(config-if)# no shutdown yourname(config-if)# end yourname# clear bridge yourname# clear arp-cache Both interfaces were assigned to the bridge, but the spanning tree protocol is disabled. We used command `arp - a` to verify that the arp caches in PC1 and PC3 were empty. We issued a ping command from PC1 to PC3, `ping -c 1 10.0.1.31` and a traceroute command from PC1 to PC3, `traceroute 10.0.1.31`. We saved the output in file ex2.txt. I also attached the ping statistics and the traceroute output as below. -------------------------- 10.0.1.31 ping statistics --------------------------- 1 packets transmitted, 1 received, 0% packet loss, time 2ms rtt min/avg/max/mdev = 1.901/1.901/1.901/0.000 ms ----------------------------- traceroute 10.0.1.31 ----------------------------- [root@PC1 ~]# traceroute 10.0.1.31 traceroute to 10.0.1.31 (10.0.1.31), 30 hops max, 40 byte packets 1 10.0.1.31 (10.0.1.31) 0.513 ms 0.391 ms 0.337 ms -------------------------------------------------------------------------------- Question5-a The traceroute output looks just like the traceroute output in Exercise 1C. Router1 did not appear in the output. Question 5-b We couldn't ping Router1 from neither PC1 nor PC3 because Router1 was configured as a transparent bridge. Its configured IP addresses were disabled. [Exercise 3A] We connected the hubs and the ethernet interfaces of the PCs. We used the following commands to configure the interfaces of the PCs: on PC1: `ifconfig eth0 10.0.1.11/24` on PC2: `ifconfig eth0 10.0.2.21/24` on PC3: `ifconfig eth1 10.0.1.31/24` on PC4: `ifconfig eth1 10.0.1.41/24` We saved the outputs of command `ifconfig -a` on PC1 and PC3 as ex3a2pc1.txt and ex3a2pc3.txt. The initial collsion numbers were zero. ------------------------ ifconfig -a eth0 output on PC1------------------------- eth0 Link encap:Ethernet HWaddr 00:02:A5:84:3D:14 inet addr:10.0.1.11 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::202:a5ff:fe84:3d14/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:759 errors:0 dropped:0 overruns:0 frame:0 TX packets:284 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:73907 (72.1 KiB) TX bytes:18039 (17.6 KiB) ------------------------ ifconfig -a eth0 output on PC3------------------------- eth0 Link encap:Ethernet HWaddr 00:02:A5:32:59:E8 inet addr:10.0.1.31 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::202:a5ff:fe32:59e8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:507 errors:0 dropped:0 overruns:0 frame:0 TX packets:652 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:55422 (54.1 KiB) TX bytes:46163 (45.0 KiB) -------------------------------------------------------------------------------- We issued the following commands to flood the network and hopefully generat some collisions. on PC1: ping -f 10.0.1.21 on PC3: ping -c 100 10.0.1.41 We saved the outputs of command `ifconfig -a` on PC1 and PC3 again. They are saved as files, ex3a5pc1.txt and ex3a5pc3.txt. We observed 8 collisions on PC3 and 3 collisions on PC1. ------------------------ ifconfig -a eth0 output on PC1------------------------- eth0 Link encap:Ethernet HWaddr 00:02:A5:84:3D:14 inet addr:10.0.1.11 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::202:a5ff:fe84:3d14/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:625702 errors:0 dropped:0 overruns:0 frame:0 TX packets:625226 errors:0 dropped:0 overruns:0 carrier:0 collisions:3 txqueuelen:1000 RX bytes:61317979 (58.4 MiB) TX bytes:61261907 (58.4 MiB) ------------------------ ifconfig -a eth0 output on PC3------------------------- eth0 Link encap:Ethernet HWaddr 00:02:A5:32:59:E8 inet addr:10.0.1.31 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::202:a5ff:fe32:59e8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:612 errors:0 dropped:0 overruns:0 frame:0 TX packets:756 errors:0 dropped:0 overruns:0 carrier:0 collisions:8 txqueuelen:1000 RX bytes:65522 (63.9 KiB) TX bytes:56131 (54.8 KiB) -------------------------------------------------------------------------------- [Exercise 3B] We replaced the hubs with one switch. We repeated the previous exercise. The outputs of command `ifconfig -a` on PC1 and PC3 were saved as files, ex3b2pc1.txt and ex3b2pc3.txt. The collisions for this exercise started as 8 for PC3 and 3 for PC1. After the network flood using the two commands list above, we recorded the outputs of command `ifconfig -a` on both PC1 and PC3 again. This time we didn't observe any more collision generated. (For Exercise 3, I believe something is wrong with the file we saved. I remembered observing those numbers of collisions in the lab and recorded them, but the file we saved indicates that the collision for PC1 eth0 didn't change after Exercise 3B and the collision of PC3 changed back to zero after Exercise 3B.) [Exercise 4A] We connected the ethernet interfaces of the PCs and routers. We used the default IP addresses for the PCs this time, to save us the step of configuring the interfaces. We used the following commands on all routers to configure the them as bridges. Router# yourname# config t yourname(config)# no ip routing yourname(config)# bridge 1 protocol ieee yourname(config)# bridge 1 priority 128 yourname(config)# interface fa0/0 yourname(config-if)# bridge-group 1 yourname(config-if)# bridge-group 1 spanning-disabled yourname(config-if)# no shutdown yourname(config-if)# interface fa0/1 yourname(config-if)# brige-group 1 yourname(config-if)# bridge-group 1 spanning-disabled yourname(config-if)# no shutdown yourname(config-if)# end yourname# clear bridge yourname# clear arp-cache We connected PC2 with the real hub. For this exercise PC2 was configured as a host not a bridge. We verified that all arp caches on PC1, PC2, and PC3 were empty. We issued the following ping commands and saved the output of `show bridge` on each router after each ping commnd. on PC1: ping -c 1 10.0.1.12 on PC2: ping -c 1 10.0.1.11 on PC2: ping -c 1 10.0.1.14 on PC3: ping -c 1 10.0.1.12 We observed the learning procedure of the bridges. We used Router1 as an example. Copied below are the outputs of `show bridge` on Router1 after the first, second, and third ping commands. ---------------------------- after ping 1: Router1 ----------------------------- yourname#show bridge Total of 300 station blocks, 296 free Codes: P - permanent, S - self Bridge Group 1: Address Action Interface Age RX count TX count 001b.54dd.7c50 forward FastEthernet0/1 4 1 0 0002.a517.5d73 forward FastEthernet0/1 3 2 0 0002.a500.b887 forward FastEthernet0/0 0 3 3 0002.a557.1b8a forward FastEthernet0/1 0 8 6 ---------------------------- after ping 2: Router1 ----------------------------- yourname#show bridge Total of 300 station blocks, 298 free Codes: P - permanent, S - self Bridge Group 1: Address Action Interface Age RX count TX count 0002.a500.b887 forward FastEthernet0/0 0 6 6 0002.a557.1b8a forward FastEthernet0/1 0 11 9 ---------------------------- after ping 3: Router1 ----------------------------- yourname#show bridge Total of 300 station blocks, 296 free Codes: P - permanent, S - self Bridge Group 1: Address Action Interface Age RX count TX count 0002.a500.b887 forward FastEthernet0/0 1 6 6 0002.a557.1b8a forward FastEthernet0/1 1 13 9 001b.d4db.9a70 forward FastEthernet0/1 0 1 0 0002.a502.29d0 forward FastEthernet0/1 0 0 0 -------------------------------------------------------------------------------- We can see that before the first ping command, Router1 has MAC address entires for Router2 eth0, PC1 eth0, PC2 eth0, and PC3 eth0. After the second ping command, Router1 has MAC address entires for PC1 eth0 and PC2 eth0. After the third ping command Router1 has MAC address entires for PC1 eth0, PC2 eth0, PC4 eth0, and Router3 eth0. The first ping command was from PC1 to PC2, the entries for PC3 eth0 and Router2 eth0 were not used. They were, therefore deleted, after the ageing timer expired. After the thir ping command, Router1 learned about PC4 eth0 and Router3 eth0, and added them in the MAC forwarding table. If there would be packets to those two MAC addresses, based on the mapping, Router1 would know to send them through its interface eth1 instead of broadcasting. [Exercise 4B] In this exercise we learned about how do changing of a location affects the bridge and the hub. We first issued some ping commands to help the bridges to create or refresh their MAC forwarding tables. We then disconnect PC2 with its hub and connected it to the switch of PC4. We should've observed some failures of the pinging because PC2 was connected with a hub, which did not learn about the moving of PC2. Router2 had no way not know that PC2's MAC address should be added in its MAC forwarding table matching with the interface eth0. Eventually old enties would be deleted and the icmp echo requests would flood on all ports. New connections would be built. However, we didn't observe as discribed because there was another machanism that helped PC2 to broadcast its new conncetion by itself. We didn't observe any unsuccessful pinging. We repeated this exercise with PC3. PC3 was connected with a switch. The bridge Router3 should learn about this change and delete the entry of PC3's MAC address mapped with its interface eth0 while add an entry of PC3's MAC address mapped with its interface eth1. However, because of the other broadcasting mechanism, we observed immediately updating for both of these two parts of this exercise.