JNCIA Lesson 4 1/2 -- More on Routing Policies and Firewall Filtering

One of the concepts that I have struggled with the most while trying to learn JunOS is the filtering language used on Juniper devices. That's a pretty significant problem too, because the filtering language is basically a core feature of JunOS, cropping up in Class of Service/Quality of Service, routing policies, and, of course, basic firewall/security on JunOS devices. It's pretty safe to say that if you don't understand this core concept, you will not be proficient in JunOS, and therefore, I decided I needed to spend a little while playing with the filtering syntax so I can understand it better. In it's most basic form, the filtering rules follow the pattern, "match-action" -- that is, you define a pattern to match, then upon a match, you perform some action on incoming packets -- and then you apply the filter to an interface or VLAN. There are three important concepts to keep in mind when trying to compose a filter rule:

1. Within a single term, match rules are logical-AND'ed together. That is, if you put a rule to match a source IP address inside a term, then put a second rule to match a destination port, the filter will only match packets from that particular source IP address AND to that particular destination port (i.e., from 192.168.1.17, to port 23). If you want to logically OR rules, you have to create separate terms in the firewall rule-set;
2. Packets are compared to each term from the top down, and the firewall stops comparing the packet to the firewall rules when it finds a match. In other words, if you put an "allow any" rule as the first term in your match rules, then put specific "deny ..." rules below, all packets will match against the "allow any" and no packet will ever be compared against the "deny ..." rules;
3. There is an implicit "deny all" at the very end of the firewall rules, even though it is not shown in the configuration. Therefore, you must always make sure that you include rules to match all of the traffic that you want to allow. For example, suppose you are seeing brute-force password guessing attacks through SSH from the IP address 1.2.3.4, so you create a rule to drop traffic matching the source address of 1.2.3.4 and destination port 22. Unless you configure a rule to allow everything else, the implicit "deny all" rule will drop all traffic coming in on the interface or VLAN to which you applied the firewall rule.

Let's start with a simple example: suppose I have a switch on the 192.168.1.0/24 network, I have a host at 192.168.1.1, and on my switch, I want to block ICMP messages from that host with an "ICMP Administratively Prohibited" notification, while allowing any other protocol from 192.168.1.1 or all traffic from other source addresses.

root@branch-3200# set firewall family inet filter no-icmp term drop-icmp from source-address 192.168.1.1

[edit]
root@branch-3200# set firewall family inet filter no-icmp term drop-icmp from protocol icmp

[edit]
root@branch-3200# set firewall family inet filter no-icmp term drop-icmp then reject administratively-prohibited

[edit]
root@branch-3200# commit
commit complete

[edit]
root@branch-3200#


If we attempt to ping 192.168.1.2 (the EX3200 switch) from 192.168.1.1 at this point, we will find the firewall isn't particularly effective:

root@main3200> ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=3.630 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=2.408 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=2.395 ms
^C
--- 192.168.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.395/2.811/3.630/0.579 ms

root@main3200>


Since we haven't applied the firewall to an interface or VLAN yet, no incoming packets are being compared against the firewall rules, and therefore all inbound traffic is still allowed. Let's take care of that, now:

root@branch-3200# set interfaces vlan unit 0 family inet filter input no-icmp

[edit]
root@branch-3200# commit
commit complete

[edit]
root@branch-3200#


To create our firewall, we started by adding a rule that drops traffic only if the source address is 192.168.1.1. However, we only want to drop ICMP traffic, so we then added a second rule (with the same term name, namely "drop-icmp") that drops ICMP traffic. Since the terms are cumulative, we've essentially created a rule that says, "if the source address matches 192.168.1.1 AND the protocol is ICMP..." Then, we created an action to reject matching packets with the "administratively prohibited" message. Let's see how it works:

root@main3200> ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
36 bytes from 192.168.1.2: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 d4e0   0 0000  40  01 2275 192.168.1.1  192.168.1.2
<...snip...>
^C
--- 192.168.1.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
root@main3200>

Good, good...

root@main3200> telnet 192.168.1.2
Trying 192.168.1.2...
telnet: connect to address 192.168.1.2: Operation timed out
telnet: Unable to connect to remote host

root@main3200>


Hrmmm...Well, we're half-way there. We are successfully blocking ICMP, but apparently, we are also blocking telnet. Remember, JunOS adds an implicit "deny all" at the end of the firewall rules. Since we create a rule to block ICMP from 192.168.1.1, but we didn't include a rule to allow any packets, we are actually blocking ALL packets on vlan.0. To fix this, we have to add a new term to allow anything that isn't ICMP and from 192.168.1.1:

root@branch-3200# set firewall family inet filter no-icmp term everything-else source 0.0.0.0/0

[edit]
root@branch-3200# set firewall family inet filter no-icmp term everything-else then accept

[edit]
root@branch-3200# commit
commit complete

[edit]
root@branch-3200#


Let's see if that solves the problem:

root@main3200> ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
36 bytes from 192.168.1.2: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 2f4c   0 0000  40  01 c809 192.168.1.1  192.168.1.2

36 bytes from 192.168.1.2: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 2f76   0 0000  40  01 c7df 192.168.1.1  192.168.1.2

36 bytes from 192.168.1.2: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 2f9c   0 0000  40  01 c7b9 192.168.1.1  192.168.1.2

^C
--- 192.168.1.2 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

root@main3200> telnet 192.168.1.2
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.

branch-3200 (ttyp0)

login:
telnet> quit
Connection closed.

root@main3200>


That's more better :) We are now successfully blocking ICMP from 192.168.1.1 while still allowing other protocols, such as TCP/23 (telnet) to the switch.

However, looking at the firewall rules, something doesn't seem to be right. We have two rules to block source-address 192.168.1.1 and protocol ICMP, but the allow rule only specifies a source-address. How does this rule work?

Keep in mind that JunOS firewall rules work from top down, and they stop looking for matches as soon as a packet matches a term. Consequently, any packet originating from 192.168.1.1 and using the ICMP protocol matches our "reject ..." rule. However, if the packet comes from another source address or is a protocol other than ICMP, JunOS continues comparing the packet with the firewall rules. Therefore, anything not matching the "drop-icmp" term is compared to the "everything-else" term. The "everything-else" term tries to match the packet against the source-address of 0.0.0.0/0 -- in other words, against all possible source IP addresses. Since this second term will match a packet coming from any IP address, it is essentially an "allow any" rule. Therefore, our rule effectively reads, "if the packet matches 192.168.1.1 and matches the ICMP protocol, then reject it with the 'administratively-prohibited' message. If it is anything else, allow it."

JNCIA Lesson 6 -- Spanning Tree, Rapid Spanning Tree and Multiple Spanning Tree

In our network design, we have two EX3200 switches at the main office, connected through a single copper cross-over cable. A savvy network administrator would probably look at our design and ask, "What would happen if either Ethernet port, or more likely, the Ethernet cable itself were to fail?" The link from our main3200 switch to our main2-3200 switch is indeed a single point of failure on our network. Many a junior network admin have had the sudden realization that such a design is a problem waiting to happen, and in their eagerness to show how pro-active and fore-sighted they are, have then run a second Ethernet cable between the two switches in order to create a redundant connection between them.

If the junior admin was lucky, (s)he probably just spent a while wondering why one of the redundant Ethernet ports suddenly went off-line (had a customer do that to me once, on a Metro-Ethernet ring, in fact). If the junior admin was not so lucky, however, (s)he created a broadcast storm, crashing the entire Layer-2 network with (her)his well-intentioned, but naive, blunder:

In actual practice, the diagrams above are an over-simplification: if Switch A was actually sending a broadcast, it would have forwarded the frame out the ports to *both* Switch B and Switch C, and both Switch B and Switch C would have forwarded the broadcast frame to each other, resulting in multiple copies of the same frame circulating through the network simultaneously. In fact, if there are four or more switches in the network connected in a full-mesh network, then with every cycle there are more and more frames circulating through the network until the switches can no longer keep up with traffic (with three or less switches, the number of frames circulating won't grow, since the switches will not forward a broadcast back out the interface upon which it was received).

In our example with the junior admin, (her)his instincts were good; the network, as originally designed, was vulnerable to failure, and it would be a good idea to design a redundant path between switches, if there were a way to prevent such loops from occurring. Fortunately, this is exactly the type of problem that the Spanning Tree protocol (STP), and it's later refinements, Rapid Spanning Tree (RSTP) and Muliple Spanning Tree (MSTP), were designed to solve.

The method through with STP prevents loops is quite simple: essentially, the protocol just shuts down redundant network ports until/unless the switches in the tree detect a failure on an active port. In our example above, and assuming that Switch A was the "root bridge" (we'll define that term shortly), Spanning Tree (or RSTP or MSTP) would put one of the ports on either Switch B or Switch C into a "blocking" state, thus breaking the loop. Now, if Switch A sends a broadcast frame to Switches B and C, they will each forward the packet to devices connected to their switch ports, but NOT to each other.

This (simplified) explanation of Spanning Tree raises an important question: how do the switches determine if there is a loop, or if there is a network port which needs to be shut down? When a switch (or group of switches) is first powered on, it sends a query out each of its enabled switch ports, called a "Bridge Protocol Data Unit." Routers and PCs ignore the BPDU, but other switches examine the BPDU to check for loops in the layer-2 topology. Some of the data transferred during this process is used to elect a "root bridge" -- the switch that will be the pinnacle of the spanning tree network. As we've already stated, spanning tree will shut down ports to break loops in the layer-2 network, but the root bridge is special: all enabled ports on the root bridge always remain active. On any switches with a single port connected to the root bridge, those ports will also always remain active, and are known as "root ports." If there are multiple ports to the root bridge, the switch will select a single port as a root port, and shut down the rest. Any ports that spanning tree uses to reach other switches, but which do not provide a path for that switch to reach the root bridge will are called "designated ports." Confused yet? Let's look a drawing to try to make it a little clearer:

As you can see, all of the switch ports that are directly connected to Switch A are root ports, all of the switch ports in a forwarding state that are NOT directly connected to Switch A are designated ports, and the ports in a blocking state are non-designated ports.

One other question that might come to mind at this point is, "how do the switches determine which switch is the root bridge?" Spanning Tree uses two metrics for electing a root bridge: first, the admin can set a value known as "root bridge priority" when configuring spanning tree, and lowest priority wins; second, if two or more switches have the same priority, then the switch with the lowest MAC address wins. In JunOS, the root bridge priority and MAC address are concatenated into a single value known as the "root ID" which can be shown with the "show spanning-tree bridge" command:

root@main3200# run show spanning-tree bridge

STP bridge parameters
Context ID                          : 0
Enabled protocol                    : RSTP
<...snip...>
  Local parameters
    Bridge ID                       : 32768.3c:8a:b0:99:df:c1
<...snip...>
root@main3200#


As you can see, the root ID on this switch is 32768.3c:8a:b0:99:df:c1. Suppose we had two other switches in a full-mesh, layer-2 network, and the other switches had root ID's of 32768.3c:8a:b0:99:e5:41 and 32768.3c:8a:b0:9a:22:01. Which switch would be elected root bridge? Let's connect these three switches together and find out! I'll connect ge-0/0/23 on the first switch to ge-0/0/22 on the second switch, connect ge-0/0/23 on the second switch to ge-0/0/22 on the third switch, then connect ge-0/0/23 on the third switch to ge-0/0/22 on the first switch. Once the switches are wired up to create a loop at layer-2, we'll re-run the "show spanning-tree bridge" command and see which switch was actually elected to be the root bridge:

root@main3200# run show spanning-tree bridge | match "Root ID"
  Root ID                           : 32768.3c:8a:b0:99:df:c1

[edit]
root@main3200#


root@branch1-3200# run show spanning-tree bridge | match "Root ID"
  Root ID                           : 32768.3c:8a:b0:99:df:c1

[edit]
root@branch1-3200#


root@branch2-3200# run show spanning-tree bridge | match "Root ID"
  Root ID                           : 32768.3c:8a:b0:99:df:c1

[edit]
root@branch2-3200#


Since all three switches have the same priority (JunOS' default of 32768), the election was determined by the lowest MAC address, which belongs to main3200.

If we wanted to know which ports were shut down, we would use the "show spanning-tree interface" command, but here, I have to make an admission: I couldn't actually find enough cross-over cables to connect all three switches in a full-mesh network, so I had to disconnect branch2-3200 for the following portion of the lab:

root@main3200# run show spanning-tree interface

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-0/0/22.0    128:535      128:535  32768.3c8ab099dfc1     20000  FWD    DESG
ge-0/0/23.0    128:536      128:536  32768.3c8ab099dfc1     20000  FWD    DESG

[edit]
root@main3200#


root@branch1-3200# run show spanning-tree interface

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-0/0/22.0    128:535      128:536  32768.3c8ab099dfc1     20000  BLK    ALT
ge-0/0/23.0    128:536      128:535  32768.3c8ab099dfc1     20000  FWD    ROOT

[edit]
root@branch1-3200#


If you notice, ge-0/0/22 on branch1-3200 is blocked by Spanning Tree, which shows that, when a link between two switches is determined to be redundant, if the path-cost back to the root bridge is equal, the lowest port number will be shut down (however, you can manually assign a port-cost to bias for or against a particular port, if you want).

RSTP is enabled on Juniper EX-series switches by default, but if you need to manually configure Spanning Tree, Rapid Spanning Tree or Multiple Spanning Tree, it's a very easy process. All three protocols are configured in exactly the same way, with just a couple of exceptions, which we'll cover in just a minute. Consequently, we'll only run through the configuration steps once, using RSTP. If you are using STP or MSTP, then rather than using "edit protocols rstp" (or "set protocols rstp ..."), you will use "edit protocols stp" or "edit protocols mstp" as appropriate.

First, we'll set the bridge priority to be lower on branch1-3200, to make it the root bridge instead of main3200:

root@branch1-3200# edit protocols rstp

[edit protocols rstp]
root@branch1-3200# set bridge-priority 20k

[edit protocols rstp]
root@branch1-3200#


Next, we will disable RSTP on ge-0/0/12.0 and commit the config:
root@branch1-3200# set interface ge-0/0/12.0 disable

[edit protocols rstp]
root@branch1-3200# commit
commit complete

[edit protocols rstp]
root@branch1-3200#


Now, one of the ports on main3200 should be in the blocking state, rather than on branch1-3200:

root@main3200# run show spanning-tree interface

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-0/0/22.0    128:535      128:536  20480.3c8ab099e541     20000  BLK    ALT  
ge-0/0/23.0    128:536      128:535  20480.3c8ab099e541     20000  FWD    ROOT

[edit protocols rstp]
root@main3200#


...and sure enough, ge-0/0/22.0 on main3200 is now in the blocking state. Let's adjust the priority to put ge-0/0/23 in the blocking state, instead:

root@main3200# set interface ge-0/0/22 cost 1000

[edit protocols rstp]
root@main3200# commit
commit complete

[edit protocols rstp]
root@main3200# run show spanning-tree interface

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-0/0/22.0    128:535      128:536  20480.3c8ab099e541      1000  FWD    ROOT
ge-0/0/23.0    128:536      128:535  20480.3c8ab099e541     20000  BLK    ALT  

[edit protocols rstp]
root@main3200#


One of the problems with spanning tree is the time it takes for the network to "converge" -- that is, the time it takes for the switches to elect a root bridge, determine if there are any loops in the topology, and then to shut down any redundant links. In STP, convergence can take almost a full minute, which is at least part of the reason RSTP was created. While RSTP is already quicker to converge than STP, it can converge even quicker if point-to-point links are declared as such with the "set protocols rstp interface ge-0/0/<whatever> mode point-to-point" command (Edit: if you are confused here, you are not alone. I'm not sure what a "point-to-point" link even means in a layer-2 network, but if I find out, I'll notate it here).

MSTP also differs from standard STP configuration in that you must add two more lines to the config:

root@main3200# set protocols mstp configuration-name jncia-example-1

[edit]
root@main3200# set protocols mstp msti 1 vlan [ 1 2 4 ]

[edit]
root@main3200# set protocols mstp msti 2 vlan [ 3 5 6 20 ]

[edit]
root@main3200#
<...etc...>


The only "gotcha" when putting VLANs into an MSTP instance (MSTI) is that every VLAN in a given instance must share a common topology.

Appendix A -- More on Spanning Tree

Spanning Tree was enabled by default on the 2924 switches I have in my lab, but sometimes the network admin needs to tweak the settings a little. For example, the network admin may want to force a particular switch to be the root bridge -- wouldn't it make sense to have the most powerful switch in your network be the root bridge rather than a small, inexpensive, low-powered access switch in a wire closet in the hut next door to your main building on your campus?

Unfortunately, I have become quite frustrated with the documentation on Spanning Tree in the several CCNA test prep books I have purchased over the years (I started working on a CCNA over eight years ago, but circumstances changed, and I never took the exam). I don't know about you, but for me, I don't retain much by simply reading technical documentation. Since I can't afford to NOT know the correct answers when I take the CCNA exam this coming week, I decided the best way to get the straight scoop was to configure, tweak, and observe Spanning Tree on my switches.

Root Bridge Election: Let's start with manipulating the root bridge election process. This was an area where I got really frustrated with the documentation, so let's just play with it on the switches and see what happens. Here goes:

lab2924a#sho span

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 0003.e3e4.f887
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag not set, detected flag not set, changes 1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 13, path cost 0
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 1416, received 8

Interface Fa0/2 (port 14) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 14, path cost 0
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 1383, received 2


...and lab2924b:

lab2924b#sho span

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 00d0.58dd.d186
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 32768, address 0003.e3e4.f887
  Root port is 13, cost of root path is 19
  Topology change flag not set, detected flag not set, changes 3
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 13, path cost 0
   Timers: message age 3, forward delay 0, hold 0
   BPDU: sent 39, received 3092

Interface Fa0/2 (port 14) in Spanning tree 1 is BLOCKING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 14, path cost 0
   Timers: message age 6, forward delay 0, hold 0
   BPDU: sent 1, received 2916


The rest of the ports on the two switches are just "leaf nodes" -- that is, they connect to routers and laptops, rather to switches, and therefore, they are incapable of creating loops in the layer-2 network. From the output above, we can see that lab2924a is the root bridge, that fa0/1 and fa0/2 on lab2924a are designated ports, that fa0/1 on lab2924b is a root port and that fa0/2 on lab2924b is a blocking port. What happens if I pull the Ethernet cable on fa0/1 on one of the switches? Let's find out! Here's what I see on lab2924a:

lab2924a#sho span

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 0003.e3e4.f887
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag set, detected flag set, changes 2
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 30, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is down
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 13, path cost 0
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 1734, received 8

Interface Fa0/2 (port 14) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 14, path cost 0
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 1705, received 4


For almost a full minute, however, I couldn't see anything from lab2924b (since I was directly connected to 2924a), which underscores a big problem with STP -- the network will recover from failure of a redundant link, but users will definitely notice the outage while spanning tree reconverges. Eventually, however, my telnet session recovered, and here is what I saw on lab2924b:

lab2924b#sho span

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 00d0.58dd.d186
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 32768, address 0003.e3e4.f887
  Root port is 14, cost of root path is 19
  Topology change flag set, detected flag not set, changes 4
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is down
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 00d0.58dd.d186
   Designated port is 13, path cost 19
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 39, received 3474

Interface Fa0/2 (port 14) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 14, path cost 0
   Timers: message age 1, forward delay 0, hold 0
   BPDU: sent 3, received 3340


Now we see that fa0/1 is down on both switches, and fa0/2 is forwarding on both switches once again. No surprises, right?

From the output above, we can see that both switches have a priority of 32768. If both switches have the same priority, then the choice of root bridge is decided by MAC address. lab2924a has MAC 0003.e3e4.f887 and lab2924b has MAC 00d0.58dd.d186. 0x0003 < 0x00d0 so apparently the low MAC address wins the election process when the priority is the same. But what if I wanted lab2924b to be the root bridge? Would I set the STP priority on lab2924b higher or lower than lab2924a? Let's try it and find out:

lab2924b#conf t
lab2924b(config)#spanning-tree priority 4096
lab2924b(config)#exit
lab2924b#sho span

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 4096, address 00d0.58dd.d186
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag set, detected flag set, changes 6
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 1, topology change 24, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 4096, address 00d0.58dd.d186
   Designated bridge has priority 4096, address 00d0.58dd.d186
   Designated port is 13, path cost 0
   Timers: message age 0, forward delay 0, hold 0
   BPDU: sent 48, received 3744

Interface Fa0/2 (port 14) in Spanning tree 1 is LISTENING
   Port path cost 19, Port priority 128
   Designated root has priority 4096, address 00d0.58dd.d186
   Designated bridge has priority 4096, address 00d0.58dd.d186
   Designated port is 14, path cost 0
   Timers: message age 0, forward delay 3, hold 0
   BPDU: sent 10, received 4070


Wow...that was fast! Since STP takes almost a minute to move the ports to the forwarding state, I didn't expect lab2924b to assume its new role as root bridge quite so quickly, but it did. You can see that fa0/2 is still in the listening state as I ran the "sho span" command, but it already knows that it's the root bridge. Edit: I later reset lab2924b's priority back to 32768, and it seemed to take a few seconds to update its status, so it's not quite instantaneous -- say about 10 or 15 seconds, maybe?

How about lab2924a?

lab2924a#sho span

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 0003.e3e4.f887
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 4096, address 00d0.58dd.d186
  Root port is 13, cost of root path is 19
  Topology change flag set, detected flag not set, changes 4
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 128
   Designated root has priority 4096, address 00d0.58dd.d186
   Designated bridge has priority 4096, address 00d0.58dd.d186
   Designated port is 13, path cost 0
   Timers: message age 2, forward delay 0, hold 0
   BPDU: sent 1869, received 36

Interface Fa0/2 (port 14) in Spanning tree 1 is BLOCKING
   Port path cost 19, Port priority 128
   Designated root has priority 4096, address 00d0.58dd.d186
   Designated bridge has priority 4096, address 00d0.58dd.d186
   Designated port is 14, path cost 0
   Timers: message age 10, forward delay 0, hold 0
   BPDU: sent 2087, received 30


Yep, it has relinquished its role as root bridge already, and has fa0/2 in a blocking state. So apparently, a low priority and/or a low MAC address makes a switch a root bridge, and the lowest numbered redundant interface on a switch becomes the root port. Easy :)

Here's something even cooler. In our scenario, we have two switches with two redundant links. However, we are only using fa0/1 to carry traffic between the two switches. In effect, while fa0/2 is providing redundancy, it is essentially wasted bandwidth until a failure occurs. Wouldn't it be great if we could distribute the load between these two ports without setting up LAG or Etherchannel? As it turns out, we can.

You see, Spanning Tree runs a separate instance for each VLAN, which is often described as "Per-VLAN Spanning Tree" or "PVST." It turns out that we can tweak the priority of each VLAN on the FastEthernet port on each switch, making fa0/1 the designated/root port for some VLANs and fa0/2 the designated/root port for other VLANs. To keep it simple, I set this up with odd numbered VLANs on fa0/1 and even numbered VLANs on fa0/2. In a real environment, it would probably be better to do some traffic analysis and find out which VLANs typically have equal amounts of traffic and try to balance load intelligently. At any rate, here's how you do it:

lab2924b(config)#int fa0/1
lab2924b(config-if)#spanning-tree vlan 1 port-priority 64
lab2924b(config-if)#spanning-tree vlan 3 port-priority 64
lab2924b(config-if)#spanning-tree vlan 5 port-priority 64
lab2924b(config-if)#spanning-tree vlan 7 port-priority 64
lab2924b(config-if)#int fa0/2
lab2924b(config-if)#spanning-tree vlan 2 port-priority 64
lab2924b(config-if)#spanning-tree vlan 4 port-priority 64
lab2924b(config-if)#spanning-tree vlan 6 port-priority 64
lab2924b(config-if)#exit
lab2924b(config)#exit
lab2924b#sho spanning-tree vlan 2

Spanning tree 2 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 00d0.58dd.d180
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 32768, address 0003.e3e4.f880
  Root port is 14, cost of root path is 19
  Topology change flag set, detected flag not set, changes 9
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Interface Fa0/1 (port 13) in Spanning tree 2 is BLOCKING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f880
   Designated bridge has priority 32768, address 0003.e3e4.f880
   Designated port is 13, path cost 0
   Timers: message age 1, forward delay 0, hold 0
   BPDU: sent 8, received 3274

Interface Fa0/2 (port 14) in Spanning tree 2 is FORWARDING
   Port path cost 19, Port priority 64
   Designated root has priority 32768, address 0003.e3e4.f880
   Designated bridge has priority 32768, address 0003.e3e4.f880
   Designated port is 14, path cost 0
   Timers: message age 2, forward delay 0, hold 0
   BPDU: sent 5, received 3376

lab2924b#sho span vlan 1

Spanning tree 1 is executing the IEEE compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address 00d0.58dd.d186
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 32768, address 0003.e3e4.f887
  Root port is 13, cost of root path is 19
  Topology change flag not set, detected flag not set, changes 7
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Interface Fa0/1 (port 13) in Spanning tree 1 is FORWARDING
   Port path cost 19, Port priority 64
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 13, path cost 0
   Timers: message age 2, forward delay 0, hold 0
   BPDU: sent 347, received 6622

Interface Fa0/2 (port 14) in Spanning tree 1 is BLOCKING
   Port path cost 19, Port priority 128
   Designated root has priority 32768, address 0003.e3e4.f887
   Designated bridge has priority 32768, address 0003.e3e4.f887
   Designated port is 14, path cost 0
   Timers: message age 4, forward delay 0, hold 0
   BPDU: sent 309, received 6948


Important! I didn't show it in the config above, but I repeated the same configuration on lab2924a -- this doesn't seem to work if the priority is changed on only one switch!

Notice how fa0/1 is forwarding on VLAN 1, but is blocking on VLAN 2, and vice versa for fa0/2? You are now utilizing both 100M Ethernet ports on your switch while still avoiding loops!