Implementing and Troubleshooting Switch Administration and Layer 2 Protocols

We’ve made up a new word here at Hack and Tinker!  That’s right, not only do you get to learn about exciting networking technologies here, you actually get to witness the birth of language.  Could it possibly get more exciting around here?!?

Here we go into the exciting world of Layer 2 technologies!  What better way could there possibly be to bring in a new year than to start talking about LAN Switching!?  Our first couple topics will start out pretty light, but don’t get used to that idea!  I’ve written quite a bit for our future series on Spanning-Tree and I can’t even begin to describe how amazing and enlightening that has been.  In the meantime, here’s our first few Layer 2 topics:

2.1   LAN switching technologies
2.1.a   Implement and troubleshoot switch administration
2.1.a (i)   Managing MAC address table
2.1.a (ii)   errDisable recovery
2.1.a (iii)   L2 MTU

Managing MAC Address Table

I’m gonna go out on a limb and guess that you’re already familiar with the fact that there’s a show mac address-table command.  There is also a show mac address-table count command that can enable you to view the number of CAM table entries are currently in use, and the number of CAM table entries your switch is capable of holding.

Another key command is the show mac address-table aging-time command.  By default, switches age out MAC table entries after 300 seconds (5 mins).  It’s probably not something you’ll have to tune or adjust often, but it’s good to remember that it’s happening.  Further, you can change this value if needed with the global mac address-table aging-time value command.

ErrDisable Recovery

There are tons of reasons a port can become errdisabled.  Most Engineers are familiar with those concepts.  Somewhat less commonly known however, is the fact that you can have a switch automatically restore an errdisabled port, either in general or for specific errdisabled resons.  Simple configure the cause(s) that you want to have automatically recover with the global config errdisable recovery cause reason command.  Then, you need to tell the switch how often it should check for errdisabled ports and automatically recover them with the errdisable recovery interval seconds command.


Remember that when we talk about the default MTU of 1500 bytes, we’re talking about the L2 MTU, and that we’re talking about the amount of data inside the L2 frame that can be transmitted.  It’s easy to get a little confused by this.  Take a look at a Wireshark capture and you’ll see that we’re transmitting frames that are 1514 bytes.


That can seem really confusing when you look at the MTU on an interface and see that the MTU is set to 1500 bytes.



A look inside the packet reveals the answer to our mystery: we’ve got 1500 bytes of data (layers 3-7) inside the L2 frame.


It’s kind of amazing how easy it is to talk about a concept like MTU and not even realize that we often forget to think about the fact that a packet’s size will grow and shrink as you encapsulate and decapsulate it.  In fact, if you look at the bottom of that screen shot, you can see that TCP reports the packet as 1460 bytes.  Is this thing 1514 bytes?  Is it 1500 bytes?  Is it 1460?  Yes, yes, and yes.

To further add to the confusion, you can dig in even deeper and see that the 1514 “default” Ethernet MTU can also be 1518 bytes if you include the L2 FCS, or 1526 bytes if you include the Ethernet preamble – which Wireshark is not showing.  Layer 2 frame size will also grow when you are using 802.1q encapsulation, or Q-in-Q tunneling.  The bottom line is though, that when you configure the L2 MTU, your L2 headers don’t normally count against that MTU – it’s only the data inside the frame that is being quantified here.  You are configuring the maximum amount of data INSIDE the frame.

This one is easy to configure –  you either use the global system mtu bytes command, or go to individual interfaces and use the mtu bytes command.
Next on our CCIE Written Exam Blueprint:

2.1.b   Implement and troubleshoot layer 2 protocols
2.1.b (i)   CDP, LLDP
2.1.b (ii)   UDLD


Can I coin the term “Homotocol?”  Seriously, we need a word that tells us when two protocols are practially the exact same thing.  CDP and LLDP are pretty analagous, with CDP being Cisco-proprietary and LLDP being an industry standard.

Let’s start by diving into CDP, since that’s the one we’re probably already more familiar with.  CDP is enabled by default on most Cisco devices and can be turned off with the global no cdp run command.  It can also be turned off on invididual interfaces with the no cdp enable command.  CDP has a default hello time of 60 seconds and a hold time of 180 seconds, these can be tuned with the global cdp timer seconds and cdp holdtime seconds commands.  CDP runs version 2 by default.  You can view CDP table info with the show cdp neighbors command, and can get detailed info with the show cdp neighbor detail command.  You can use the show cdp entry command if you know the hostname of a device you’re looking for.  You can use the show cdp traffic command to view CDP traffic counters.  Most of this is all second nature to Engineers, so I won’t go into any further detail.

LLDP, on the other hand, is probably not quite as familiar.  LLDP is not enabled by default, but can be with the lldp run command.  LLDP has defualt hello and hold timers of 30 and 180 seconds and can be adjusted with the lldp timer seconds and lldp holdtime seconds commands.  LLDP can also be instructed to wait for up to 5 seconds after an interface comes up before it intializes with the lldp reinit seconds command.  LLDP has two more commands that you should be familiar with related to TLVs.  TLVs (Type, Length, Value) are the fields that LLDP packets use to advertise information.  Any kind of information that can be transmitted in an LLDP packet, such as hostname, port-descriptions, management-ip-address has a particular TLV.  Cisco’s implementation of LLDP allows you to specify which TLVs you will send or receive.  Specify these with the lldp tlv-select tlv-type command.  This can be done globally or per-interface.  You’ll find that the tlv-types differ per platform, and even within a platform, depending on whether you are in global config or interface config mode.  An extension to LLDP called LLDP Media Endpoint Devices (LLDP-MED) provides additional support for, you guessed it, media endpoints.  These include VoIP phones and telepresence devices.  By default, a switch only sends standard LLDP packets unless it receives and LLDP-MED packet from a device.

As with the configuration commands, many of the LLDP show commands are the same as their CDP equivalents (or, their CDP “homotocolous correlatives”, as I’ve started calling them as of the time of the writing of this sentence.)  The show lldp interface command is available, as are show lldp neighbor, show lldp entry , show lldp traffic… no big surprises anywhere there.  One big advantage of LLDP is the fact that is can run on your desktops, which can provide some nice visibility in your network if desired.


UDLD stands for Uni-Directional link detection, and is especially useful in fiber networks, though it can run on other media as well, including copper.  The basic idea behind UDLD is that unidirectional links are bad and must be discovered and shut down to prevent loops.  Loops form on unidirectional links because switches need to see BPDUs in both directions in order to know of each other’s existance and to calculate the STP topology correctly.  Fiber links tend to be more succeptible to unidirectional links because of their being two separate and independant cables, whereas copper holds the twisted pairs within the same sheath.  UDLD can be turned on with the interface UDLD port aggressive command.  Normal mode simply logs UDLD messages, but does not shut down an interface.  Aggressive mode will indeed kill the link.  Verify UDLD operation with the show udld interface number command.  UDLD must be running on both devices in order to operate.  Also, know that UDLD will not shut down a link until after a UDLD neighborship occurs, where both ends of the link have exchanged UDLD messages with each other.

Thanks again for stopping by.  Have a safe and Happy New Year everyone!  We’re looking forward to all that 2015 will bring here at Hack and Tinker!

Leave a Comment

Your email address will not be published. Required fields are marked *