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.
