Lesson 53 - Network Address Translation Part 3

In my last post I tried to explain the main principles behind NAT. As an example I used static and dynamic approach in which a client receives multiple IP addresses from the ISP (Internet Service Provider). In most cases though, we receive only a single IP address which is used on the router's interface that faces the Internet.

In that case, how a single IP address can represent (be used by) multiple computers in order to allow them communication with the hosst on the Internet? The solution is to use NAT Overload.

NAT Overload
In this method, the major points described in previous lesson do not change. Still, the router will have configuration that allows is to distinguish the 'nat inside' and 'nat outside' interfaces.

Also, the router is going to replace an 'inside local' IP address with the 'inside global' (the one used on the interface connected to ISP). This time though, ALL inside local addresses (private ones; RFC 1918) will be represented by the same unique public IP address (e.g. 86.46.1.10). This will instigate the problem when the packets are sent back from the Internet. They all point to the SAME public IP. That is why, we need something else to distinguish between PC1 (e.g. 192.168.1.1) and PC2 (e.g. 192.168.1.2) that will be represented by the same address: 86.46.1.10.

What could be this distinguisher?

TCP/UDP ports of course! Recall, that each computer, while sending something out, picks a source port from the range above 1023, and the well-known destination port. These are enough to distinguish PC1 from PC2, since it is very unlikely they will pick the same source port. If that happens, the router will replace this source port in TCP or UDP header with something unique.

Here's what happens when PC1 sends packets towards www.ciscco.com.

Step 1

The packet from PC1 (src: 192.168.1.1) arrives at the 'nat inside' interface (f0/0). The router is instructed to read its source IP address as well as its source TCP port in the layer 4 header. Appropriate entry is created in the NAT table as per Pic. 1 (Inside Local). Note, that this time R1 makes a note of the source port: 192.168.1.1:2001

The IP source address is removed and replaced with the 86.46.1.10 (R1's 'nat outside' interface - S1/0). The entry in the NAT table is created under the 'Inside Global' column. Also, the 'Outside Local' and 'Outside Global' entries are populated as per Pic. 1. This record in the NAT database, will allow to translate the packet back when www.cisco.com is replying to the sender (PC1).

Notice!

The :2001 is the port number in the TCP header.

Pic. 1 - NAT Overload - PC1's Transmission.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Step 2
When www.cisco.com (72.163.4.161) replies, the packet is delivered back to R1. The router, upon receiving the packet on the 'nat outside' interface, must now find the appropriate record in the NAT table, allowing it to locate the original sender's IP address and its source port (here: 192.168.1.1:2001). If there is no such entry, the packet is going to be dropped. Since in our case, the entry exists, the router is translating the packet back as shown in the pic. 2:

Pic. 2 - NAT Overload - PC1 Receives the Reply from www.cisco.com.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Suppose during this transmission, (PC1-to-www.cisco.com), PC2 is also going to send something towards the Internet. In order to simplify our discussion, PC2 is going to send the packet towards www.cisco.com as well (but this could be any host on the Internet).

Step 3
R1 receives another packet on its 'nat inside' interface (f0/0). It is sourced by IP address 192.168.1.2, the source TCP port 1408 this time. This port has not been used yet (does not exist in NAT table under 'inside local' column), so it is unique and can be used to send the packet out. Another entry is going to be created as per pic 3 below. Watch carefully the second record in the NAT table.

Pic. 3 - NAT Overload - PC1's Transmission.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Step 4
The web server (www.cisco.com) is sending the reply back. Again, R1 will look for the appropriate entry in the NAT table ('inside global=86.46.1.10:1408), to find out which machine was the originator of the traffic flow. Translation back to the original values is performed (dst: 192.168.1.2:1408). PC2 receives the reply from the web server.

Pic. 2 - NAT Overload - PC2 Receives the Reply from www.cisco.com.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In case the source port has already been used by some computer (even though it is rare it can happen), the router is going to use a different port. Imagine that the PC2 has also chosen to use the port 2001. In such situation, the 'Inside Local' entry is going to look like this:
192.168.1.2:2001

But, then upon noticing the port is already in use, the router will pick some other port that has not been used yet. The corresponding entry in the 'Inside Global' will be be changed to this for instance:
86.46.1.10:2002

In such case, the cisco web server will be replying to two different destinations:
86.46.1.10:2001 translated back to: 192.168.1.1:2001
and
86.46.1.10:2002 translated back to:192.168.1.2:2001

I hope this will do for you. In my next post, I'm going to show you how to configure NAT using four different methods:

• Static NAT (one-to-one)
• Dynamic NAT using pool of addresses
• Dynamic NAT overload
• Dynamic NAT using pool of addresses with overload

Lesson 25 - Switch Port Security

This post is the last one related to layer 2 technologies. With the next posts, I will shift my focus to layer 3 technologies. If you use GNS-3 or dynagen (dynamips emulator), you'll be able to perform all routing tasks on your computer as long as you have IOS image.

Switchport Port Security
This IOS feature (switch only) allows you to limit the number of MAC addresses that will be serviced on a given port. It comes with multiple options such as which MAC address(es) is/are going to be allowed on a given port, and what action should be taken when the violation of the policy occurs. This way, you can further protect your entry point in the network (access switches).

By default, the port security is turned off on all interfaces. In order to turn it on, a port must be in an access mode. Otherwise the command will be rejected. Check out the below attempt of enabling it when the port is in a 'dynamic desirable' rather than an access mode.

Pic. 1 - Port security (switchport port-security) command rejected.

 

The proper sequence of the commands to enable port security on F0/1 would be as follows:

SW1(config)#interface fastethernet0/1

SW1(config-if)#switchport mode access

SW1(config-if)#switchport port-security

The above configuration applies a default security policy on the port. What settings are going to be used here may vary between switch platforms. But typically, the port in a secure mode allows only aSINGLE MAC address (just one) to be serviced and in the case when the violation occurs, the port will be put in ERR-DISABLE state. This state will put the port down so, no traffic can traverse it.

For the purpose of my presentation, I will use very simple topology (Pic. 2).

Pic. 2 - Topology

Icons designed by: Andrzej Szoblik - http://www.newo.pl

My router R1 is connected to SW1 port F0/1. The MAC address of the R1 (E0/0 port) is:
0050.500f.6600

Now, I want accomplish the two goals:

• R1 E0/0 port should be connected to SW1 port F0/1. In case, the R1 is connected to any other port on this switch, the communication with the R1 should not be allowed.
• SW1 port F0/1 should service traffic to/from R1 E0/0 interface. In case, somebody connects more devices to port F0/1 than R1 port E0/0, and/or different device, the port F0/1 should be put in an ERR-DISABLE state.

Let us go ahead and configure it!

I need to show you what the current status of the SW1 port F0/1 is, before we apply port security.

Pic. 3 - SW1 port F0/1 Before Security is applied

As you see, the MAC address of the R1 E0/0 interface has been learned dynamically from the incoming frames on SW1 port F0/1. At this stage, I must explain the difference between dynamic and static entries in the MAC address table.

• DYNAMIC - the entry is created from the incoming frames by reading the source MAC address field in the Ethernet header. The entry is valid for 5 minutes (300 seconds) by default. If the host with this source address (here R1) does not send any frame towards the port of the SW1 for 300 seconds, the entry is removed. Every time, the R1 sends a frame towards the SW1 F0/1, the entry timer is reset, or if the entry has already been removed, the same MAC address is mapped to the port again.
• STATIC - the entry (MAC address) is permanently mapped to a specific port. It does not age like a 'dynamic' entry. The switch does not create this MAC address to port mapping by reading the source MAC address, but it is the administrator of the switch that creates it in the global config mode using 'mac address-table static' command.

 So, the question is: what is the difference in operation if you use static over dynamic method?

In case of static mapping of MAC address to a port, you CANNOT move this device to any other port as it will not work! The switch expects to receive the frames sourced from the device on the specific port. If it receives the frames with the MAC address on different port than assigned statically, it will drop the frames from that device.

If you rely on dynamic address learning (default), you can plug in a device to any port and quickly the switch flushes the entry from the old port (where the device was connected previously) and re-learns the MAC address on the new port you have just connected your device to.

Knowing that, we can proceed with our security plan now. I have applied the port access and port security commands like presented above. Now, take a look at the default settings applied on this specific switch platform I use (Catalyst 2950). Bear in mind, that your switch may have different default settings.

Pic. 4 - Port in Secure Mode.

Quick dissection of the output's essential information:

• Secure Port - F0/1 is now working in a secure mode.
• MaxSecureAddr - The maximum number of addresses allowed on this port is 1 MAC address.
• CurrentAddr - At this moment, this maximum limit has been reached.
• SecurityViolation - Currently there's been no security violation reported.
• Security Action - In case there is a security violation detected, the port will go DOWN (err-disable).

Let's see which MAC address is now in the secure mode (it should be R1 E0/0).

Pic. 5 - Current Secure MAC Address.

Everything seems good so far. F0/1 port learned dynamically the MAC address of our R1, and is now considered a secured MAC address. One of our two goal plan seems to be working. What if we moved the R1 to another port? What would happen then?

Pic. 6 - MAC address with security enabled.

This specific switch (C2950) has also made the entry 'static' which means, that if you move R1 E0/0 port to another port of this switch, the traffic from R1 will be discarded!

Well, you can further improve the security of your R1. The problem is, that with current configuration, you can reboot the switch and while doing so, you can plug in a different device to F0/1. This way the newly learned MAC address upon reload of the switch becomes the secure one. 

In order to make it more secure, it is recommended that you configure the secure MAC address permanently. Just like in the example below:

SW1(config)#interface f0/1

SW1(config-if)#shutdown

SW1(config-if)#switchport port-security address 0050.500f.6600

SW1(config-if)#no shutdown

SW1(config)#end

SW1(config)#wr

Pay attention to some of the commands presented. I shut the port down first to flush the current (the same) MAC address. Otherwise this command would be rejected (duplicate MAC address). Then, after adding the MAC address, I brought the port up and saved my configuration.

Now, the MAC address becomes the part of configuration and the security applied can withstand the reboot of the switch.

Pic. 7 - Configuration saved in NVRAM.

There is one more command that offers more detailed output (pic. 8).

Pic. 8 - Port security detailed output

Take a look at some interesting options shown below:

Pic. 9 - Port security options.

• Aging - there are two types of secure MAC address aging: 'absolute' and 'inactivity'. The former, allows to specify how long the MAC address should be considered secure, the latter decides that MAC address is no longer secure if it is not transmitting data in a given time. Both parameters can be configured but, as per default, the secure MAC addresses do not age.
• Mac-address - like in my configuration, this option specifies which address is to be secured. You can type in a specific MAC address (like I did) or use a 'sticky' keyword. When 'sticky' is used the MAC address(es) already learned on the port become part of the interface's configuration. However, adding MAC address manually is recommended. Just like I did.
• Maximum - how many MAC addresses can be considered secure on a given port (platform dependent). The default is: 1.
• Violation - this option allows to choose one of the three options as to what action must be taken if the violation of the security is detected. 

Port Violation Actions

1. Protect - when the port receives the traffic from the MAC addresses which are not configured as secure, it silently drops those transmissions. There is NO notification logged about the violation occurring on a port.
2. Restrict - similar to 'protect' only the switch logs the violations detected.
3. Shutdown (default) - the port will transition to err-disable upon detecting the violation.

Let me quickly show you what happens if my switch detects the violation of the port security.

I am going to change the MAC address on my E0/0 port of R1 to:
0000.aaaa.aaaa

As a result of that, the first frame sent towards the SW1 F0/1 will cause the violation of my policy (wrong MAC address, and the port allows only one MAC address previously assigned as the secure one).

Pic. 10 - The log generated after violation on the port occurred.

Below is the status of the port now.

Pic. 11 - Port in err-disable state upon violation of security.

The only way to rectify the situation is to do the following:

1. Plug in the device with the right (secure) MAC address back to the port F0/1.
2. Shut the port down manually (administrative mode shutdown).
3. Bring the port up using: 'no shutdown' command.

This way has one major disadvantage. Well, it seems you have to perform the three steps mentioned above which looks like you are being punished for somebody else's security violation.

You can configure two additional commands in the global configuration mode which allow your switch to attempt to bring the port automatically after a period of time in err-disable mode. If the proper device is already connected, the port will be fully functional again.

SW1(config)#errdisable recovery cause psecure-violation

SW1(config)#errdisable recovery interval 60

The first command instructs the switch to pay attention to any ports in err-disable state. If such ports exist, the switch will attempt to bring them up after 60 seconds of putting the in err-disable mode (second command).

In my next post, we will start talking about layer 3. I propose that we refresh our knowledge of binary system which is essential to understand IP addressing scheme.

Lesson 24 - Layer 2 Etherchannel

There are two more things I would like to cover in this Cisco fundamentals series that relates to switches: the etherchannel technology and switch port security. Then we move on to layer 3 stuff.

Layer 2 Etherchannel

When you're designing your network one of the factors you always consider is resiliency. Redundant connections are part of a good design. Consider picture 1 below. A rule of thumb says that if all the devices connected to SW3 (access switch on first floor) were transmitting at full speed towards distribution switches (here towards SW1) the traffic is allowed to exceed the capacity of F0/2 port onSW1 20 times. In other words, the link between access layer could oversubscribe 20:1 the link on the distribution switch. Well, it is true in most cases. Remember this is just a rule for an average network.

Pic. 1 - 2-tier network design (access+distribution layer).

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In reality, the situation in which all computers begin to transmit at full speed at the same time never happens. The studies show, that the link between access and distribution switch is utilized in 7% on the average (unless some worm has been planted on your computers). In order to live up to this rule (oversubscription 20:1) you might consider access-to-distribution connection using multiple links that form a virtual connection called: etherchannel. Ports that are members of the etherchannel are represented by a virtual interface called: port-channel.

Etherchannel Advantages
Etherchannel is often used between the switches in order to increase the capacity of the connection between them by performing a load balancing of the frames traversing the channel. Load sharing (balancing) is based either on source or destination MAC address of the transmitting computers when layer 2 etherchannel is used. In case of an active link failure (the port in the channel that transmits the frames), the next link is going to transmit the packets with almost no delay. Keep in mind that the word: etherchannel, is a Cisco term. The industry standard name is link aggregation(IEEE 802.3ad).

Enough of the terminology and reasons for using the technology. Let's get practical.


Cisco offers you three ways of configuring the etherchannel ( three modes of operation):

1. Dynamic channel negotiation using Link Aggregation Control Protocol (LACP) which is the industry standard implementation.
2. Dynamic channel negotiation using Port Aggregation Protocol (PAgP) which is Cisco proprietary implementation.
3. Manual channel configuration without using any form of negotiation.

Etherchannel is a very picky technology. For the channel to be formed correctly (without STP loops etc.), there are a lot of link parameters that must match between switches. Even though I'm not a big fan of "automatic", "I-think-for-you" methods, using either LACP or PAgP seems to be a good idea here. If the channel cannot be formed we have a better reporting as to what went wrong and better protection against the loops that might form between switches on mis-configured channels. But if you use switches from different vendors and dynamic methods fails, even though all parameters, are correct, you can always resort to a manual method.

If I decided to use etherchannel in the topology presented in Pic. 1, I could use the following setup using at least two connections between, each forming a single connection like shown below:

Pic. 2 - Redundant Topology with Etherchannels.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

For the argument sake I will use a simple network topology below (pic. 3). Now, let's see the configuration options.

Pic. 3 - Topology

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Etherchannel using LACP
If you want to configure an etherchannel using a dynamic exchange of packets that is compliant with an industry standard method, the IOS offers you two mode options:

• active - in this mode the ports are actively sending negotiation frames to the other switch checking if the required parameters match and the channel can be safely formed.
• passive - in this mode the ports are waiting for the negotiation frames from the other switch in order to form a channel. The ports in the passive mode do NOT initiate any negotiation, but they will reply to negotiation frames received from a neighbor.

In pic. 3, if the parameters between ports F0/13 and F0/14 on SW1 and SW2 are correct (speed, duplex, trunking, vlans allowed etc.), the following channel modes will succeed in forming the etherchannel:

• SW1 active - SW2 active
• SW1 active - SW2 passive
• SW1 passive - SW2 active

---

NOTICE!
In case, when both use channel mode passive, the etherchannel will not form since no switch is going to start negotiation.

NOTICE!
It is imperative that you check all the settings of the ports first (all ports must have identical configuration). Candidate ports must be in the shutdown mode. This precaution is used to avoid loops and other issues while establishing the etherchannel.

---

Etherchannel using PAgP
Port Aggregation Protocol is Cisco proprietory protocol helping establish a virtual link between devices using dynamic negotiation (PAgP frames). Similarly to LACP, it has two modes of operation.

• desirable - in this mode, ports initiate negotiation frames and check if ports on a neighboring switch have proper settings to establish the etherchannel. 
• auto - in this mode, ports cannot initiate negotiation but will respond to the negotiation frames sent by a neighboring switch.

Similarly, assuming that all the port parameters are identical, the following pairs will work in the topology presented above (pic. 3):

• SW1 desirable - SW2 desirable
• SW1 desirable - SW2 auto
• SW1 auto - SW2 desirable

Etherchannel manual
This mode does not exchange any negotiation frames. Be cautious using this method, as switches won't check if port parameters match. Loops can be formed more easily than with the other two methods.

It's time to get our hands dirty!

The configuration assumes that all port parameters are IDENTICAL!

METHOD 1 - LACP (on both switches in my topology shown in pic. 2)

SW(config)#interface range f0/13 - 14

SW(config-if-range)#channel-group 1 mode active

SW(config-if-range)#end

SW#

Verification (here on SW1):

Pic. 4 -  "show etherchannel summary" command.

Pic. 5 - "show etherchannel 1 detail" command.

In the above picture (pic. 5), part of the output has been truncated for a clarity.

METHOD 2 - PAgP (on both switches in my topology shown in pic. 2)

SW(config)#interface range f0/13 - 14

SW(config-if-range)#channel-group 1 mode desirable

SW(config-if-range)#end

SW#

Verification (here on SW1):

Pic. 6 - "show etherchannel summary" command.

Pic. 7 - "show etherchannel 1 detail" output.

 

In the above picture (pic. 7), part of the output has been truncated for a clarity.

METHOD 3 - Manual (on both switches in my topology shown in pic. 2)

SW(config)#interface range f0/13 - 14

SW(config-if-range)#channel-group 1 mode on

SW(config-if-range)#end

SW#

Verification (here on SW1):

Pic. 8 - "show etherchannel summary" command.

Pic. 9 - "show etherchannel 1 detail" command.

In the above picture (pic. 9), part of the output has been truncated for a clarity.

All configurations that do NOT relate to physical aspects of the ports that are member of the etherchannel must be configured on the port-channel interface now. For instance, if you want to change the channel member ports to a trunk or access mode, the configuration must be done as follows:

SW(config)#interface port-channel 1

SW(config-if)#switchport trunk encapsulation dot1q

SW(config-if)#switchport mode trunk 

I hope this will help you get started. For more information on etherchannel, please refer to Cisco documentation.

In my next post I am going to present switch port security. After that, get ready for layer 3 stuff.

Lesson 23 - Introduction to Rapid STP (802.1w)

Good news is that if you have learned 802.1d protocol (STP standard), only few things change in terms of the terminology and operation in the Rapid Spanning-Tree Protocol. RSTP is clearly an evolution of the regular STP but definitely NOT the revolution. The three phases of operation mentioned in lesson 20 still apply.

This post is going to be the last in the series on Spanning-Tree Protocol fundamentals.

Let's focus on the major changes introduced in RSTP by comparing it to the standard STP.

• STP Port States: "disabled", "blocking", "listening" are renamed to DISCARDING inRSTP. As far as the "forwarding" state, the name remains unchanged.
• STP Port Roles: designated and root roles are still the same. But the non-designated role has been split in two new ones: ALTERNATE and BACKUP roles in RSTP.

Below picture will give you an indication as to what they describe.

Pic. 1 - Rapid STP Alternate Port.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

An alternate port is a port that is in a blocking state and receives superior (better) BPDU frames from another switch. The port F0/2 of SW2 is the example of alternate port.

Pic. 2 - Rapid STP Backup Port.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

A backup port is a port in the blocking state that receives superior BPDU frames from the same switch like shown in Pic. 2. The port F0/3 of SW3 is the example of backup port.

Cisco STP Enhancement such as: spanning-tree uplinkfast and spanning-tree backbonefast are no longer used (except for spanning-tree portfast which Cisco still maintain in the IOS as an edge port). They have been replaced with negotiations of the port state that is based on the previously unused flags in the BPDU frame and a different mechanism of sending BPDU frames. The flags are shown below (pic. 3).

Pic. 3 - BPDU Flags.

Understanding the nuts and bolts of the RSTP operation is beyond the scope of this tutorial. All you need to know at this stage is the terminology and benefits of using it over a legacy STP. The major advantage of RSTP is that switches use BPDU frames differently than before. Ports, upon first connection or when topology changes, exchange BPDUs with proposal/agreement flags set helping achieve fast transition to the appropriate state. They negotiate whether the port should be the designated, non-designated or root port role. If the port becomes the root port, all other ports begin negotiation by exchanging proposal/agreement BPDUs since the path towards the root bridge is different. It is extremely fast mechanism that speeds up the convergence upon a topology change.

A few other changes implemented in RSTP you must be aware of are as follows.

• All switches exchange BPDUs instead of relaying them after they have received them from the root bridge. BPDUs have become a true keepalive mechanism. The switches do not have to wait for the root bridge to notify them about topology change that occurred somewhere in the network. A switch that detects change notifies its neighbors about it. And those in turn, notify their neighbors immediately. It is a mechanism similar to OSPF updates in that respect.
• RSTP is backward compatible with STP (802.1d) speaking switches. Upon receiving BPDU version 1 (802.1d), the port transitions to the legacy STP protocol. All timers (max_age, forward_delay) are used according to the STP specifications (802.1d).

There are also two new concepts introduced in RSTP that are worth mentioning:

1. Edge Port - which is something you are already familiar with. It is the port that is the candidate for a quick transition to forwarding state as it connects device that cannot create the loop (no BPDUs received on that port). Cisco enables Edge Port capability by using spanning-tree portfast feature described in the previous lesson. The ports must be a point-to-point link type (full duplex).
2. Link Type - the type of the link is derived from the duplex of the port:

• Full Duplex = Point-to-Point link
• Half Duplex = Shared link

All these changes serve one purpose: they help in fast convergence on a detection of the new connection or/and a topology change. The speed of convergence is similar to the one when Cisco STP Enhancements are used in STP. The difference is that now fast convergence is accomplished as an industry standard mechanism, not a proprietary solution.

The configuration of RSTP is pretty straightforward.

SW(config)#spanning-tree mode rapid-pvst

That is it!

Deterministic election of the root bridge and all the jazz related to it explained in the previous lesson are identical.

If you want to learn more on RSTP operation google it by using this query:
understanding rstp. You'll find a plethora of documents out there.

Lesson 22 - Spanning-Tree Cisco Enhancements

My previous two posts hopefully shed some light on IEEE 802.1d protocol (yes, it is STP). There are two more things I would like to add to that picture. The first thing, deals with situations when the topology changes and how it affects the STP time of convergence. The convergence here, means the time it takes to recompute the STP tree in order to keep the loop free paths upon failure. The second thing, I'd like to bring up is the Cisco STP enhanced the STP operation to decrease the time of convergence compared to the industry standard STP.

Before we delve into the details though, I need to explain something about BPDU frames first. It is true that it is the root bridge that originates those frames and sends them out its designated ports ( downstream, every 2 seconds by default). It is also true, that all other switches (non-root bridges), propagate them downstream out of their designated ports. This way all switches receive the information as to which switch is the root bridge in the network and if it is still functional.

However, what I withheld in previous posts was the types of BPDU frames. There are three types of those:

• Configuration - the type of BPDU which the root bridge sends every 2 seconds, and other switches propagate those out of their Designated Ports (downstream).
• Topology Change Notification (TCN) - the type of BPDU that a switch will send if it detects the topology change (port going down, or TCN received). This BPDU is sent out the Root Port (upstream) towards the root bridge informing it, that the tree needs to be recomputed.
• Topology Change Acknowledgement (TCA) - the type of BPDU that is sent back to the sender of TCN BPDU, acknowledging the reception of the notification.

How do those BPDUs fit into the grand scheme of things?

The default timer of how long the entries are kept in the MAC address table is 300 seconds (5 minutes). This means, that if a host connected to a port of the switch does not speak for at least five minutes, its MAC address is removed from the CAM table. That is a way too long for the switch to re-learn computer's MAC addresses if the STP topology changes.

But why do those MAC entries have to change?

Please, consider the Pic. 1 below. By now, you should be able to tell which ports of the switches are going to learn the PC1 and PC2 MAC addresses. Go ahead, click the Pic. 1, and put down on a piece of paper the switch names and the ports that learn MAC addresses of the PC1 and PC2. That is going to be a good refresher of how switches learn MAC addresses dynamically.

Pic 1 - STP Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

If your answers match mine below, that means that you have mastered the lessons on bridging/switching and STP.

SW1 CAM:
F0/1 - 0000.1111.1111
F0/2 - 0000.2222.2222

SW2 CAM:
F0/1 - 0000.2222.2222
F0/2 - no mac addresses learned since the port is NDP
F0/3 - 0000.1111.1111

SW3 CAM:
F0/1 - 0000.1111.1111
F0/2 - no mac addresses learned as PC1 communicates using SW1
F0/3 - 0000.2222.2222

SW4 CAM: 
F0/1 - no mac addresses learned as SW2's port F0/2 is NDP
F0/2 - 0000.1111.1111
F0/2 - 0000.2222.2222

Now, lets create a problem that causes the topology change in our network. Consider Pic. 2 which shows us why some ports must re-learn the MAC addresses of PC1 and PC2.

Pic. 2 - STP Network Problem

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Given the situation, STP needs to recalculate topology since we lose active connections betweenSW1 and SW2. If it were not for the STP operation in such circumstances, it would take 5 minutes (300 seconds) for the switches to re-learn MAC addresses according to the situation presented in Pic. 3. The resulting topology diagram is depicted below.

Try to put down on the paper which MAC addresses should be learned on which ports of the respective switches after failure (Pic. 3).

Pic. 3 - Topology after losing the connection between SW1 and SW2.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

SW1 CAM: 
F0/1 - down 
F0/2 - 0000.1111.1111
F0/2 - 0000.2222.2222

SW2 CAM: 
F0/1 - down 
F0/2 - 0000.2222.2222
F0/3 - 0000.1111.1111

SW3 CAM: 
F0/1 - no MAC addresses learned
F0/2 - 0000.1111.1111
F0/3 - 0000.2222.2222

SW4 CAM: 
F0/1 - 0000.1111.1111
F0/2 - 0000.2222.2222

In order to decrease the time of re-learning MAC addresses, upon failure SW1 is going to send TCN BPDU out its Root Port. Normally, the Configuration BPDU are sent out Designated Ports NOT the Root Port. But this failure prompts the switches to notify the root bridge about the topology change. That is why, they will send TCN BPDU out their Root Port. All switches, in the path of this TCN BPDU must send the TCA BPDU (acknowledgement) back to the sender and forward TCN BPDUtowards the root bridge. As soon as the root bridge has been notified about the topology change, it begins to send TCN BPDUs out its Designated Ports, so other switches in the network also get notified to give them a chance to flush MAC addresses, recompute the tree and re-learn the MAC addresses according to the new topology (Pic. 3). This reduces the time of convergence from 5 minutes to about 30 - 50 seconds time, depending on the nature of the change.

You might question that and say that the default timers used here (30-50 second delay) are still inappropriate for today's networks transmitting voice, video and data. And you are quite right saying so. The mechanism is still not good enough. But remember, that those timers were designed as SAFE values (not causing the loops) given the maximum diameter of network of seven switches (hops) between the root bridge and the bottom switches. Also, remember that STP was designed when there were no multimedia transmissions being sent across the switches. Is there a solution to those timers? Of course. You may change them manually but DO NOT DO THAT unless you are very experienced with STP operation. Another option is to use some proprietary features implemented in Cisco switches.

Cisco with their STP Enhancement are able to decrease this 30-50 second timers even further allowing video, voice and data co-exist in our layer 2 networks. Keep in mind, that these enhancement are Cisco proprietary STP add-ons: 

1. STP Portfast (now part of standard implementation as well).
2. STP Uplinkfast.
3. STP Backbonefast (this one is beyond the scope of this tutorial).

Let us see how the first two can change the behavior of our sample topology.

STP Portfast feature should be configured on all EDGE ports, i.e. the ones that connect devices that do not send BPDU frames and cannot create loops. These would be your computers, servers, printers etc. What STP Portfast does, it simply skips the LISTEN and LEARN states, going directly to FORWARD state if there was TCN announced or the port in question is just brought up. Think about it. It makes no sense to flush the MAC addresses on the ports that connect the computers directly, since the topology change is not going to affect them. In the topology presented in this tutorial (Pic. 1, 2, and 3), the topology change did not affect the ports F0/3 on both SW2 andSW3 where PC1 and PC2 are connected respectively. They are still connected where they were before the topology change and their addresses are mapped to the same ports as before the change. So, there is no point of flushing the MAC address table entries on SW2 port F0/3 and SW3port F0/3. These ports are the candidates for STP Portfast. Because STP Portfast-enabled ports go FORWARD almost immediately, it is highly recommended to use this feature on ports connected to computers in order to avoid problems of getting the IP address using DHCP services.

There are two ways of enabling STP Portfast feature.

Method 1
In the global configuration mode, type in this command:

SW1(config)#spanning-tree portfast default

All ports that are discovered as EDGE ports (more on that in my next post about Rapid STP), will have STP portfast enabled by default. You can check that using a detailed STP output regarding a port (here F0/1):

SW1#show spanning-tree interface f0/1 detail 

The output shows that STP  portfast has been enabled on this port (look at BPDU received = 0, candidate for portfast):

Pic. 4 - STP F0/1 Detailed Output.

Method 2 
Another method is to type in the following command directly on the chosen port:

SW1(config)#interface f0/1

SW1(config-if)#spanning-tree portfast

This way, we turn on STP Portfast unconditionally (whether port does or does not receive BPDUs).

The second STP enhancement is STP Uplinkfast. This one should be configured on all ACCESS switches (the leaf switches in our topology NOT distribution ones). The feature that is enabled in the global config mode, shortens the time it takes to transition NDP port into RP role upon losing the current Root Port.

In our topology, consider SW2 that has lost its Root Port (F0/1, Pic. 2). Normally, that is without STP Uplinkfast enabled, it would take 30 seconds for the F0/2 port to transition to an RP role. Keep in mind that F0/2 does not have go to blocking state since it keeps receiving superior BPDUs with the Root Bridge ID. Thus, only 30 seconds are required by default (LISTEN+LEARN states). With STP Uplinkfast enabled, Cisco guarantee that the transition of F0/2 to forwarding state (RP role) is going to happen in under 5 seconds.

The configuration of STP Uplinkfast is done in the global config mode as shown below:

SW1(config)#spanning-tree uplinkfast

Similar, in functionality, is STP Backbonefast that could be implemented on distribution switches. However, the details of this feature are beyond the scope of this tutorial.

In my next post, I'm going to briefly present Rapid Spanning-Tree Protocol (IEEE 802.1w) and how it differs from a regular STP (IEEE 802.1d).