Archive for March 2013
We all know the big advantage of configuring Portfast, a port configured with Portfast will immediately start transmitting data in the ‘forwarding’ state bypassing the other spanning-tree states. This is certainly a great feature to have configured on your downstream ports connecting to your end-user workstation or your servers. There is also another great reason to configure Portfast on your client edge ports, that is not such widely known.
Whenever a switchport goes up or down the switch generates a TCN (Topology Change Notification) packet and sends this TCN packet to the root bridge, the root bridge then responds back with a TCA (Topology Change Acknowledge) packet simply to acknowledge the TCN packet. The root bridge then transmits another BPDU with the TC (Topology Change) bit set to every switch within the Spanning-Tree domain. When the other switches receive this TC marked packet it resets the aging time of every entry in the CAM table (Also known as the MAC address table) down to 15 seconds which can cause the switch to rebuilt it’s it CAM table if the entries start aging out. Now depending on the size of your layer 2 network this can waste a lot of resources on your switches. Not to mention causes a lot of unnecessary traffic overhead, since we have a set of BPDUs transmitted with the TCN, TCA, and TC flags set individually. Keep in mind also, that if CAM table entries start expiring this can cause unnecessary ARP traffic for additional information the switch already had.
Now let’s review some of this:
Here is a port configuration, without portfast:
When we disconnect and reconnect fa1/0/5, we get the following log output:
In that previous screen shot, you’ll notice the first thing that happens is spanning-tree sends out that TCN BPDU, and interface is marked as down. I then reconnect the cable to fa1/0/5 and you see the port go through the spanning-tree stages, from listening to learning and finally to forwarding. (Extra credit which version of spanning am I running?) Something to notice as well is the fact another TCN BPDU packet is sent as the port is set back in the forwarding state.
Now let’s configure Portfast on this switchport:
Now again lets disconnect and reconnect this port again:
There is much less going on here compared to our previous experience, the important thing here is to notice there are no TCN transmitted not when the port is marked as down nor when the port marked as up (or forwarding). The only STP events that are registered is the fact port fa1/0/5 goes directly to the forwarding state from the blocking state bypassing the listening state and the learning state, allowing the client to start using the network even quicker.
Now, let’s sit back in our chair for a second and think about this for a minute. A TCN is sent out when the switchport goes down and again when the switchport enters the forwarding state. So when an end user decides to reboot their PC, when they undock their laptop to go to a meeting, dock back in at their desk again, or when they decide to re-organize their desk and unplug their PC a TCN wills be transmitted causing the switches to lower the aging timers of entries in the MAC address table. That could be a lot of unnecessary resource utilization.
P.S. Remember to enable BPDU Guard when enabling portfast! Portfast is great a tool but because it skips the listening and learning states you run the possibility of create layer 2 switching loops if cross connect multiple switches or your users start connecting simple switches/hubs at their desks. BPDU Guard will place a port in an Err-Disabled status if it receives a BPDU on that port.
By default syslog run over UDP port 514, UDP as well all know is unreliable. Now lets say you have a couple of core devices and you wanted to ensure the syslog messages from these devices successfully arrived to your syslog server or NMS well in that case I would say your best bet would be to configure syslog to use TCP to send syslog messages to that destination. This is conveniently configured in on simple line:
So now Syslog messages to 10.1.1.1 will be handled by TCP over port 8080, with that said you can even specify a different port number if you see it necessary, just remember to configure your syslog server to accept the syslog messages over the specific port that you can configure.
You can also use this configuration to change the default UDP port used by syslog if your environment calls for it. So instead of the default port UDP 514, syslog messages will be sent over UDP port 5514 in this example:
I while back I mentioned it is possible to debug a single IPSec tunnel using crypto conditions, this functionality also extends outside of crypto conditions. IOS routers offer the functionality to create debug conditions and limit debug output to specific interfaces, ip addresses, and more see the following list:
You can also stack these debug conditions on top of each other:
You will see as you specify additional conditions it tells how many conditions have been set. Issuing the command show debug condition will display a list of debug conditions that been set.
One thing you will want to keep in mind if you do not remove these conditions is when you finished troubleshooting your problem you should remove these debug conditions are else they will affect any other debugs you run in the future. You can remove these debug conditions by issuing the command no debug condition. One thing to keep in mind is that you have the ability to remove the debug conditions in any order, using the above configuration as an example lets say you want to keep seeing debug messages pertaining to IP address 192.168.1.254 and also pertaining to any interface and not just when it includes interface fa0/0, you can issue the command the no debug condition condition 1 or no debug condition interface fa0/0 depending which method you find simplier.
While conditional debugging is a very powerful tool when troubleshooting, you will still want remember that debugging can be very processor intensive and still might hinder performance on a production router, after all the debug is still running using debug conditions just limit the messages you will see.