{{2010-2011:students:vic_ding:stp1whole.tar.gz|dump file for network 1}} \\
{{2010-2011:students:vic_ding:stp2core.tar.gz|dump file for network2}} \\
{{2010-2011:students:vic_ding:stp1improve.tar.gz|dump file used for improvement of network 1}} \\
{{2010-2011:students:vic_ding:stp2improve.tar.gz|dump file used for improvement of network 2}}
==== UML switches can be created as a switch or a hub. Which do you need to use for sniffing and why? ====
We need hub here, as switch will not forward Ethernet frames to certain ports according to the filter rule learned during the learning state. Sniffer can only capture the Ethernet frames for other nodes when they are on the same collision domain. In this case, we are taking a look at STP which work on Ethernet level, so hub should be the only choice.
==== Download the Ubuntu package and install the files in your UML filesystem as per usual. ====
Please see the work log.
==== Can you think of reasons not to use the Busybox version of brctl? ====
The reason is simple, busybox version of brctl miss some functions. The normal brctl provides the following function
vic@umlubuntu:~/uml$ brctl --help
Usage: brctl [commands]
commands:
addbr add bridge
delbr delete bridge
addif add interface to bridge
delif delete interface from bridge
setageing
==== Provide and investigate the reasoning behind each of the following items. Also explain any choices you made in the process. ====
- To be able to analyze the collected data, we need to be able to put it into a timeline.
- We need to see all the relevant packets produced by the Spanning Tree Protocol. That means that irrelevant packets can be left out, though your
should carefully decide what they are.
- We need to be able to see the content of the STP packets. tcpdump can show that in a nice format so be sure to look into that.
- We need to be able to see what (sub)network the packet was retrieved from.
The order in which the nodes send/receive the packet is very important. They have influence on the procedure and the convergence time of the network. The // t // family of tcpdump can help us
-t Don't print a timestamp on each dump line.
-tt Print an unformatted timestamp on each dump line.
-ttt Print a delta (micro-second resolution) between current and pre‐
vious line on each dump line.
-tttt Print a timestamp in default format proceeded by date on each
dump line.
-ttttt Print a delta (micro-second resolution) between current and
first line on each dump line.
We can use filters to ensure that only the relevant packets are captured, like protocol = stp, and so on. However, I did not apply any filter in the tcpdump. There are two reasons for that
- simplify the scripts: I do not have to let tcpdump use different filter in every different assignment where different packets have to be captured.
- I have more complete capture file, every packet is captured, to play with later with either tcpdump itself or wireshark (GUI tool).
There are parameters we can define in tcpdump to let it present us with some more human-friendly packet contents. Like -v -vv -x -xx. The v family, present more verbose output includes more fields and the x family gives out also the packet content instead of only the header.
-v When parsing and printing, produce (slightly more) verbose out‐
put. For example, the time to live, identification, total
length and options in an IP packet are printed. Also enables
additional packet integrity checks such as verifying the IP and
ICMP header checksum.
When writing to a file with the -w option, report, every 10 sec‐
onds, the number of packets captured.
-vv Even more verbose output. For example, additional fields are
printed from NFS reply packets, and SMB packets are fully
decoded.
-x When parsing and printing, in addition to printing the headers
of each packet, print the data of each packet (minus its link
level header) in hex. The smaller of the entire packet or
snaplen bytes will be printed. Note that this is the entire
link-layer packet, so for link layers that pad (e.g. Ethernet),
the padding bytes will also be printed when the higher layer
packet is shorter than the required padding.
-xx When parsing and printing, in addition to printing the headers
of each packet, print the data of each packet, including its
link level header, in hex.
I "mark" the packets with bridges' IDs and their ports IDs. Like, for example
bridge 1:
AA:BB:CC:DD:01:AA - port 1 AA:BB:CC:DD:01:01
- port 2 AA:BB:CC:DD:01:02
bridge 2:
AA:BB:CC:DD:02:AA - port 1 AA:BB:CC:DD:02:01
- port 2 AA:BB:CC:DD:02:02
- port 3 AA:BB:CC:DD:02:03
In this way, I can easily see in the dump file where the specific packet come from. The host and rcS scripts have to be adapted to the change as well.
+ change in host file. It will accept manual MAC addresses assignment.
+
bridge)
macbr=$4
macif1=$5
sw1=$6
#hostname=$macbr
if [ -z "$7" ];
then
#echo "screen -d -m -S $hostname linux.uml rootfstype=hostfs rootflags=$home/ r umlid=$hostname role=$role hostname=$hostname eth0=daemon,,unix,$home/switch/$sw1.ctl macbr=$macbr macif1=$macif1 sw1=$sw1"
screen -d -m -S $hostname linux.uml rootfstype=hostfs rootflags=$home/ r umlid=$hostname hostname=$hostname role=$role eth0=daemon,,unix,$switchhome/$sw1.ctl macbr=$macbr macif1=$macif1 sw1=$sw1
else
macif2=$7
sw2=$8
if [ -z "$9" ];
then
#echo "screen -d -m -S $hostname linux.uml rootfstype=hostfs rootflags=$home/ r umlid=$hostname hostname=$hostname role=$role eth0=daemon,,unix,$home/switch/$sw1 eth1=daemon,,unix,$home/switch/$sw2 macbr=$macbr macif1=$macif1 sw1=$sw1 macif2=$macif2 sw2=$sw2"
screen -d -m -S $hostname linux.uml rootfstype=hostfs rootflags=$home/ r umlid=$hostname hostname=$hostname role=$role eth0=daemon,,unix,$switchhome/$sw1.ctl eth1=daemon,,unix,$switchhome/$sw2.ctl macbr=$macbr macif1=$macif1 sw1=$sw1 macif2=$macif2 sw2=$sw2
else
macif3=$9
sw3=$10
#echo "screen -d -m -S $hostname linux.uml rootfstype=hostfs rootflags=$home/ r umlid=$hostname hostname=$hostname role=$role eth0=daemon,,unix,$switchhome/$sw1.ctl eth1=daemon,,unix,$switchhome/$sw2.ctl eth2=daemon,,unix,$switchhome/$sw3.ctl macbr=$macbr macif1=$macif1 sw1=$sw1 macif2=$macif2 sw2=$sw2 macif3=$macif3 sw3=$sw3"
screen -d -m -S $hostname linux.uml rootfstype=hostfs rootflags=$home/ r umlid=$hostname hostname=$hostname role=$role eth0=daemon,,unix,$switchhome/$sw1.ctl eth1=daemon,,unix,$switchhome/$sw2.ctl eth2=daemon,,unix,$switchhome/$sw3.ctl macbr=$macbr macif1=$macif1 sw1=$sw1 macif2=$macif2 sw2=$sw2 macif3=$macif3 sw3=$sw3
fi
fi
echo "bridge $hostname started"
;;
+ change in rcS on UML instances. It will change the MAC address of each interface of each bridge accordingly (AA:BB:CC:DD::). And assign MAC address (AA:BB:CC:DD::AA) to bridge.
+
bridge)
echo "bridge: $hostname"
mount -t hostfs none /lib/modules/ -o /usr/lib/uml/modules
modprobe llc
modprobe stp
modprobe bridge
#add br and interfaces
/bin/brctl addbr $hostname
ifconfig $hostname hw ether $macbr
if [ ! -z $macif1 ];
then
ifconfig eth0 hw ether $macif1 up
/bin/brctl addif $hostname eth0
fi
if [ ! -z $macif2 ];
then
ifconfig eth1 hw ether $macif2 up
/bin/brctl addif $hostname eth1
fi
if [ ! -z $macif3 ];
then
ifconfig eth2 hw ether $macif3 up
/bin/brctl addif $hostname eth2
fi
/bin/brctl stp $hostname on
ifconfig $hostname up
echo "INFO: bridge $hostname activated"
;;
==== Witnessing the start-up ====
=== Describe in detail (i.e. your own words, not verbatim dumps) what packets are sent, when and why. ===
=== What parameters are used in the packets and what are the set to (timing parameters in the BPDU packets etcetera. . . )? ===
=== Does the witnessed behaviour of the protocol deviate in any way from the official specification? ===
Improvement
Yes. The strange issue I saw is that when there is no change on the network, the TC bit will all of sudden be set. and last for about 36 seconds. Please see the following packets.
179 28.210945 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
18 28.217348 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
180 30.213560 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
19 30.220059 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
.
.
35 62.213755 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
197 64.209801 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
This situation happen more than one time, please see the packets below
320 318.064784 aa:bb:cc:dd:02:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
151 318.071218 aa:bb:cc:dd:02:02 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8002
.
.
162 340.070109 aa:bb:cc:dd:02:02 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8002
The TC bit does not get cleared after packet 162 at 340 second. But my capture file stopped here. This is more likely to be a implementation error in the software.
Below the read out of // tcpdump // of the captured packets with option // xx // and // vv //
21:48:35.148686 STP 802.1d, Config, Flags [none], bridge-id 8000.aa:bb:cc:dd:01:aa.8001, length 35
message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
root-id 8000.aa:bb:cc:dd:01:aa, root-pathcost 0
0x0000: 0180 c200 0000 aabb ccdd 0101 0026 4242
0x0010: 0300 0000 0000 8000 aabb ccdd 01aa 0000
0x0020: 0000 8000 aabb ccdd 01aa 8001 0000 1400
0x0030: 0200 0f00
It is possible to do the full analysis by using tcpdump, but it is just so much easier if we use // Wireshark // a GUI tool with lots of easy to use built in functions, like merge the dump file, make time line and sort according to different fields.
== Network 1 ==
The following image shows how the tree look like after the convergence. Bridge1 is elected as the root bridge. And both port 1 of the other two bridges are used as root port, and both port 2 are blocked.
{{2010-2011:students:vic_ding:stpnetwork1.png|(Picture of the network needed)}}
The result of my STP caculation:
+ Bridge 1: by running brctl showstp br1
+
/ # brctl showstp br1
br1
bridge id 8000.aabbccdd01aa
designated root 8000.aabbccdd01aa
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 1.23 tcn timer 0.00
topology change timer 0.00 gc timer 15.23
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.23
flags
eth1 (2)
port id 8002 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.23
flags
+ Bridge 2: by running brctl showstp br2
+
/ # brctl showstp br2
br2
bridge id 8000.aabbccdd02aa
designated root 8000.aabbccdd01aa
root port 1 path cost 100
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 9.96
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 19.84
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
eth1 (2)
port id 8002 state blocking
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 19.84
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
+ Bridge 3: by running brctl showstp br3
+
/ # brctl showstp br3
br3
bridge id 8000.aabbccdd03aa
designated root 8000.aabbccdd01aa
root port 1 path cost 100
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 12.84
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 18.77
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
eth1 (2)
port id 8002 state blocking
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 18.77
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
Now we take a closer look into the captured file.
Below are the first 6 packets I got from the capture. Every bridge start by announcing themselves as the root, on all the ports, however with one exception which is the port 2 of bridge 2, as it may has heard of bridge 1 earlier than announcing itself as root, it starts broadcast bridge1 as the root and give cost of 100.
#bridge 3
1 0.000000 aa:bb:cc:dd:03:01 Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/0/aa:bb:cc:dd:03:aa Cost = 0 Port = 0x8001
4 0.010066 aa:bb:cc:dd:03:02 Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/0/aa:bb:cc:dd:03:aa Cost = 0 Port = 0x8002
#bridge 1
2 0.000208 aa:bb:cc:dd:01:01 Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
5 0.010070 aa:bb:cc:dd:01:02 Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
#bridge 2
3 0.000632 aa:bb:cc:dd:02:01 Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
6 0.011331 aa:bb:cc:dd:02:02 Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8002
The BPDUs are flooded to Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00), so every STP talking bridge should receive them. In this case, bridge3 boot up quickly and start the STP election first by broadcast itself as the root on both of his port. The port 1 of bridge 1 start in between and broadcast also itself as the root on both of its port.
Bridge2 starts latest among the three. Its port1 is broadcasting itself as the root, but port2 is broadcasting bridge1 as the root bridge, as it may has received the earlier sent BPDU by others (bridge1 and/or bridge3). Since every bridge is using the same priority (32768), which is also broadcast in the BPDU, we do need the tie breaker here. The MAC address is therefor used. That's why finally bridge1 is elected as the root with lowest MAC address (aa:bb:cc:dd:01:aa).
The BPDUs are sent in the interval of 2 seconds through out the whole procedure. However, after the election, only the root bridge will keep sending out BPDUs. Others only listen.
All the ports enter listening mode first, after the root bridge is elected, they will enter learning port. Then after the forwarding delay (15 seconds) they enter the forward mode.
Many parameters are sent in the BPDU packets
- source (MAC of originating ports) and destination (01:80:c2:00:00:00 STP bridge) addresses
- BPDU flag
* TCN (topology change)
* TCA (acknowledge of TCN)
- BPDU type (configuration, TCN, TCA)
- root id (root brdige id)
- bridge id (bridge's own id)
- cost (cost to root)
- port id (originating port)
- bridge priority (32768)
- message age (start with 0)
- max age (20)
- Hello time (2)
- forward delay (15)
** What happens if the topology changes? ** \\
Depending on the role of the down port of bridge, the STP will behave differently. If it is not a port on the root bridge, the bridge will just unblock the formerly blocked port and the network flow will not be disturbed. But in case of a root port or root bridge down, the topology of the whole network will be changed, hence a TCN will be triggered and acknowledged by others.
** What happens if you disturb the network by shutting down the root bridge? ** \\
Improvement: Does the witnessed behaviour of the protocol deviate in any way from the official specification? \\
I did not notice any abnormal behavior in the log nor on the bridges. The STP on each bridge just behave like described in the book and slides of Karst.
** Explore as many possibilities for situations that could/should/may give rise to problems as can be imagined (i.e. more than one), describe them and then test them. **
I turn off STP on bridge1 (root). So a new election is needed. However, it will not happen until the max age (20 seconds) is reached. We can see this clearly from the capture below
126 118.339826 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
127 138.334867 aa:bb:cc:dd:03:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:03:aa Cost = 0 Port = 0x8001
128 138.334869 aa:bb:cc:dd:02:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
129 138.335206 aa:bb:cc:dd:03:01 01:80:c2:00:00:00 STP Topology Change Notification
Improvement \\
Bridge2 is elected as the new root bridge, as it has lowest bridge ID (MAC address) and port 1 and 2 of it are serving as the DP.
br2
bridge id 8000.aabbccdd02aa
designated root 8000.aabbccdd02aa
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 1.87 tcn timer 0.00
topology change timer 0.00 gc timer 7.87
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd02aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.87
flags
eth1 (2)
port id 8002 state forwarding
designated root 8000.aabbccdd02aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.87
flags
bridge3 port 1 is the root port for bridge3. It has lower port ID (0x8001), so it preferred over port2 (0x8002)
/ # brctl showstp br3
br3
bridge id 8000.aabbccdd03aa
designated root 8000.aabbccdd02aa
root port 1 path cost 100
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 3.86
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd02aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 19.71
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
eth1 (2)
port id 8002 state blocking
designated root 8000.aabbccdd02aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 19.71
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
BPDU number 126 (time 118), we still have bridge 1 as the root and the root is then brought down by me. BPDU number 127 (time 138, which is 20 seconds later), bridge 3 reached max age and start sending out BPDU to announce that there is a topological change and itself should be the new root. In BPDU 128 (time 138), bridge 2 does the same. A new election hence should be started. Probably, in this round bridge2 will become the new root, due to the lower bridge id. At almost the same time, bridge 3 send out the TCN to yield that there is a change on topology.
As shown below,
129 138.335206 aa:bb:cc:dd:03:01 01:80:c2:00:00:00 STP Topology Change Notification
136 138.346604 aa:bb:cc:dd:03:01 01:80:c2:00:00:00 STP Topology Change Notification
137 139.421463 aa:bb:cc:dd:02:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
138 139.432378 aa:bb:cc:dd:02:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
The TCN is sent in a very high frequency. Same goes with the TCA. As each of the TCN will be acknowledged by a TCA. The TCA is a normal looking BPDU packet with only the BPDU flag TCA bit set while TCN is a packet in different form. It is a packet without content and only has the BPDU type set to 0x80. Interesting enough, if we do not look at the content and TC flag of TCA, we will have the flag of TCA also as 0x80.
Now bridge2 takes over the role as root bridge. And broadcast in every 2 seconds the BPDU.
** investigate more cases **
* Turn back on the bridge 1
In the same network, I turn on the previously turned off bridge1. It starts broadcasting BPDU to announce itself as the root. And amazingly enough, in such a huge change of topology. There is no TCN nor TC flag. Both bridge2 and 3 will quietly accept it and use bridge1 as the root again.
184 185.325847 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
185 185.336085 aa:bb:cc:dd:02:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8002
186 185.336599 aa:bb:cc:dd:03:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8002
187 185.336928 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
188 186.322706 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
189 186.333423 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
Improvement \\
126 118.339826 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
This is the last BPDU from previous root bridge 1 at time 118 second.
172 172.427118 aa:bb:cc:dd:02:01 01:80:c2:00:00:00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
173 174.414214 aa:bb:cc:dd:02:01 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8001
This 172 packet is the last packet from new root bridge 2 with TC set. After that it broadcasts normal 2 second's BPDU.
184 185.325847 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
This is the first packet from re-turn on bridge1 at time 185 second.
Next all the bridges just send BPDU to compete for the root role
185 185.336085 aa:bb:cc:dd:02:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8002
186 185.336599 aa:bb:cc:dd:03:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8002
187 185.336928 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
188 186.322706 aa:bb:cc:dd:01:01 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8001
189 186.333423 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
No TC, no TCN, no TCA. Only the down of the root bridge will be notified via TCN and TC. The join of a "better" root is not notified via these packets. A new election just happen and every other bridges follow quietly.
== network 2 ==
{{2010-2011:students:vic_ding:stp2.png|}}
Result of STP calculation
+ Bridge 1 (root)
+
/ # brctl showstp br1
br1
bridge id 8000.aabbccdd01aa
designated root 8000.aabbccdd01aa
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 1.72 tcn timer 0.00
topology change timer 4.84 gc timer 1.72
flags TOPOLOGY_CHANGE TOPOLOGY_CHANGE_DETECTED
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.72
flags
eth1 (2)
port id 8002 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.72
flags
eth2 (3)
port id 8003 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 0 hold timer 0.72
flags
+ Bridge 2
+
/ # brctl showstp br2
br2
bridge id 8000.aabbccdd02aa
designated root 8000.aabbccdd01aa
root port 2 path cost 100
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 15.04
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 100 hold timer 1.04
flags
eth1 (2)
port id 8002 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 19.92
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
eth2 (3)
port id 8003 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 0.00
designated port 8003 forward delay timer 0.00
designated cost 100 hold timer 1.04
flags
+ Bridge 3
+
/ # brctl showstp br3
br3
bridge id 8000.aabbccdd03aa
designated root 8000.aabbccdd01aa
root port 3 path cost 100
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 6.92
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd03aa message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 100 hold timer 0.92
flags
eth1 (2)
port id 8002 state blocking
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd02aa message age timer 19.92
designated port 8003 forward delay timer 0.00
designated cost 100 hold timer 0.00
flags
eth2 (3)
port id 8003 state forwarding
designated root 8000.aabbccdd01aa path cost 100
designated bridge 8000.aabbccdd01aa message age timer 19.93
designated port 8003 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
This is a more complicated setting than network 1, in the sense that not only bridge 1 (root) is sending period BPDU but also bridge 2 is sending BPDU on port 3 (connected to bridge3) with weight 100, to tell bridge 3 that it has a route to root bridge with cost 100.
1 0.000000 aa:bb:cc:dd:03:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:03:aa Cost = 0 Port = 0x8002
2 0.000455 aa:bb:cc:dd:02:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:02:aa Cost = 0 Port = 0x8003
3 0.074078 aa:bb:cc:dd:03:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:03:aa Cost = 0 Port = 0x8003
4 0.074313 aa:bb:cc:dd:01:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8003
5 0.140022 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
6 0.991514 aa:bb:cc:dd:03:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8002
7 1.066574 aa:bb:cc:dd:01:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8003
8 1.113405 aa:bb:cc:dd:02:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8003
9 2.033120 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
10 2.068905 aa:bb:cc:dd:01:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8003
11 2.116324 aa:bb:cc:dd:02:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8003
12 3.993914 aa:bb:cc:dd:02:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8003
13 4.031611 aa:bb:cc:dd:01:02 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
14 4.068319 aa:bb:cc:dd:01:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8003
15 5.998564 aa:bb:cc:dd:02:03 01:80:c2:00:00:00 STP Conf. Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8003
Only the first 12 BPDUs are related to the root election. The later three (13 to 15) are period BPDUs. Two sent by root bridge with cost 0, and one sent by port 3 of bridge 2, which is connected to the blocking port of bridge 3. This shows that even if the port is in the state of blocking it is still taking part in the STP and listening to BPDUs.
If I turn off the port 3 on bridge 3 which is the root port for it, port 2 will immediately be put into listening state. And send out BPDU to announce itself as root. Only after the first receipt of the root BPDU, it will use the lower root id bridge as the root. Port two will then be put into learning mode, after 15 seconds' forward delay, it will be in forwarding state.
If I shutdown the root bridge in this setting, it does not make too much sense, as there is no fault tolerance in the network. If any one of the bridge, it will break the current network setting and leave us with a totally different two bridge network. The reachability of the hosts is gone. However, let's suppose the root bridge 1 is down. Then host1 will be disconnected from the rest of the network, and bridge 2 will be the new root.
=== Analyse both networks using the above approach. ===
You can turn off individual ports on the bridges. In that case there is fault tolerance! Network 2 needs more work (more tests) \\
I will first turn off one of the ports on root bridge, in this case bridge1 port 2. As there is no more direct link to root from bridge 2, bridge2's port to port 1 on root should be blocked, however, since the connected root port is down, it will not receive BPDU, so it will not be put into block mode, rather it will stay in the forwarding mode broadcast BPDU to the UML hub. Its port to bridge3 should be left untouched in forwarding state. Port on bridge3 to bridge2 become DP, the other one should become RP. Let's see if it works as expected.
port 2 on root brdige1 is down, below is the message on bridge2
br2: neighbor 8000.aa:bb:cc:dd:01:aa lost on port 2(eth1)
br2: topology change detected, propagating
Next, the previously blocked port of bridge3 will be bring up. And there is TCN generated to announce the change of topology as we can see from the message below.
br3: port 3(eth2) entering learning state
br3: topology change detected, sending tcn bpdu
So everything works as expected. In a triangle topology even one port is down does not take down the whole network. We can conclude certain level of fault tolerance. But not as high as in network 1.
Next, I bring back the disabled port on root, wait till the network re-convergence. Then try to disable a port on bridge3's RP. Just to see how smooth the switch of port state can be. And how fast it can be.
turn down the interface on bridge3 to root bridge 1
/ # ifconfig eth2 down
br3: port 3(eth2) entering disabled state
br3: port 2(eth1) entering listening state
immediately, the previously blocked port 2 enter listening state. Same time, the TCNs are sent from two bridges
182 115.006268 aa:bb:cc:dd:02:02 Spanning-tree-(for-bridges)_00 STP Topology Change Notification
183 115.040180 aa:bb:cc:dd:03:02 Spanning-tree-(for-bridges)_00 STP Topology Change Notification
bridge3 is the the place where the change occurs, but maybe it is too busy with the change, bridge2 is just a tiny bit faster in sending out the TCN.
186 116.415578 aa:bb:cc:dd:01:03 Spanning-tree-(for-bridges)_00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8003
187 116.589078 aa:bb:cc:dd:01:02 Spanning-tree-(for-bridges)_00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
188 116.653639 aa:bb:cc:dd:02:03 Spanning-tree-(for-bridges)_00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8003
The the patent of the repetation of the BPDUs goes back to normal. bridge1 is still the root, so both of its ports are sending out BPDUs. And bridge2 port 3 became DP for bridge3, and sending out BPDU. Its port 2 is the RP. bridge3's port 2 is disabled. And port3 is used as RP. \\
The switch is real fast and smooth, from the above packets we can calcute that the total process of switching takes only around 1.5 seconds. It is the full convergence time, if we look at the packets below, the time of convergence should be reduced to half a second
184 115.588295 aa:bb:cc:dd:01:02 Spanning-tree-(for-bridges)_00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 0 Port = 0x8002
BPDU flags: 0x81 (Topology Change Acknowledgment, Topology Change)
185 115.652761 aa:bb:cc:dd:02:03 Spanning-tree-(for-bridges)_00 STP Conf. TC + Root = 32768/0/aa:bb:cc:dd:01:aa Cost = 100 Port = 0x8003
BPDU flags: 0x81 (Topology Change Acknowledgment, Topology Change)
=== Make a thorough comparison between the analyses of both networks. ===
== Are the observations the same for both networks? What, if any, are the differences? ==
network 1 is smaller in size but complicated topology wise due to the loops created by the connections to the switches. It probably takes more CPU cycles from the bridge to run STP algorithm.
Improvement: why netowrk 1 take more CPU cycles on STP \\
There are 3 portential loops in first network: bridge 1 and 2, bridge 1 and 3, bridge 2 and 3. There are even more combinations with up/down ports to form more complicated issues. However, in network2, there is max one physical loop as it is a triangle. STP is the protocol created with loop emission as goal, it will have to work harder within a heavy loop environment.
But network 1 comes with more fault tolerance than network 2. there are three redundant links between hosts. Any two bridges can be down, and at most 4 connections can be down, as long as the broken links comes in pairs. In network 2, with only one bridge down the host connected to it will be inaccessible.
STP is not sticky and deterministic. If the election criteria keeps the same, like bridge id, port id and etc, the root bridge will always be the same one. Even after it went down for a while, after it came back online, it will take over the root role smoothly.