You are currently browsing articles tagged Switching.

Many times we (network engineers) hear the complaint “the network is working, but it is terribly slow”. This is often one user’s perception of a perfectly working network however, other times there is something to the complaint.  One thing to check is if that particular user’s switchport is reporting any errors.  Let’s take a look at the error counters on a typical switchport.

2940#show int faste0/1 counters errors

Port        Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize
Fa0/1               0          0          0         85         0

Port      Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen     Runts    Giants
Fa0/1              0         0         0          0        16         0         0

When I was a younger engineer I used to look at output like this and have literally no idea what any of it meant.  I just wanted to make sure that there weren’t tons of numbers in the output.  After working in the field for awhile I look at this output differently.  Each type can point you in the direction of what’s causing the error.  Below I’ll list some common causes for each of these error types.  Admittedly I don’t have all of these memorized, but as with all things if you don’t have it memorized, you just have to know where to find it.

Note: These errors can be caused by a variety of things.  I’m only listing the most common issues and solutions I have seen.

Cause: Malformed frames, bad hardware, duplex mismatch, and half duplex collisions
Check: Cabling, physical port, duplex settings

Cause: Bad frame checksum, duplex mismatch, bad hardware
Check: Cabling, physical port, duplex settings

Cause: Speed mismatch
Check: Manual speed defined on a port

Cause: Duplex mismatch, backplane congestion
Check: Duplex settings

Cause: Receiving frames that are less than 64 bytes
Check: Device sourcing the frames

Cause: A single collision occurred prior to the switch being able to transmit to media.  Common on half duplex interfaces
Check: Duplex mismatch, high link utilization

Cause: Multiple collisions occurred prior to the switch being able to transmit to media.  Common on half duplex interfaces
Check: Duplex mismatch, high link utilization

Cause: Collision detected prior to frame fully being transmitted
Check: Cable length, duplex mismatch

Cause: Switch encountered 16 successive collisions in a row
Check: Duplex mismatch, high segment or link utilization

Cause: This error counter is incremented each time the switch tries to send data on a half duple link.  With half duplex the port has to check the wire to ensure its open  prior to sending the frame. 
Check: Duplex settings

Cause: Frame is too small (less than 64 bytes) and has bad CRC
Check: Duplex mismatch, cabling, physical port

Cause: Frame exceeds size of 1518 bytes and has a bad FCS
Check: Device sourcing the frames

This post obviously wasn’t meant to tell you absolutely everything about frame and switchport errors.  However, hopefully it has put you on the right track as far as troubleshooting port errors is concerned!


Being able to analyze other users network traffic is a key part of troubleshooting networks.  Back in the day when using hubs was common than switches, it was really easy to analyze network traffic.  All you had to do was plug into an available switchport and you would see all of the network traffic on your segment.  Why?  Because, by default, hubs flood traffic out all of their ports.  When switches came around, the game changed.  Switches build layer 2 address tables (MAC/ARP) and forward traffic based on the layer 2 information in the frame.  That being said, plugging into an available switchport these days will only get you frames that are unicast for your MAC address or broadcast on the segment.  This makes troubleshooting a pain.  In some cases I’ve seen engineers carry small hubs with them.  When they need to listen to traffic for a particular device, they’ll actually throw the hub in wiring path so that they receive all of the data destined for the target they are trying to analyze.  This is shown below. 

In this diagram, the blue shows the normal wired connection directly between a switchport and the end user.  The red line shows what the wiring might look like when a hub is injected into the path.  In this configuration the frames destined for the end user hit the hub, and are forwarded out all of the ports.  This causes packets destined for the end user to also be sent to the network engineer so they can be analyzed.  It should be noted that this is a two way street.  Frames destined for the network engineer will also be flooded out the port that the end user is plugged into.

While the solution above works, it’s not that great.  Best case is that you can put the hub in the switch closet and throw it in line between the patch panel and the switch.  This eliminates the need to crawl under the users desk with a hub and a laptop to analyze their traffic.   However, regardless of what you are analyzing, throwing a hub in place is messy.  What if you are trying to find a bandwidth hog on a local segment and you need to analyze all the traffic going out through the default gateway?  While the hub method works, it requires temporarily taking the network down to throw a hub in the path of all of your outbound traffic.  Not a very elegant solution.  Looking for something easier that doesn’t require re-cabling and throwing a 20 year old hub in your network?  Enter the beauty of Cisco managed switches.

Cisco switches allow you to do what is called port spanning.  While in documentation you might find it called port mirroring, sessions mapping, or spanning, they all mean one thing – you can duplicate port traffic.  Through the rest of the article I’ll refer to the technology as ‘spanning’.   Examine the diagram below. 

That looks a lot cleaner!  Rather than physically putting a device in line to duplicate traffic we now define a span port which duplicates all of the traffic from a selected source port.  Let’s take the example of my home network to solidify the point.

imageSo let’s say that my wife is playing XBOX and I’m sitting on my laptop.  I open a WireShark session on my NIC and start analyzing traffic.  While it’s hard to see in the image below, I’m only seeing traffic coming and going from which is the IP address assigned to my laptop via DHCP. 

Now let’s say that I want to see all of the traffic leaving my network.  To do this, I’m going to span the port that’s connecting the switch to the 2800 series router.  The router is running a ‘router on a stick’ configuration and is acting as the default gateway for all of the VLANs defined on the switch.  The instant I enable spanning and map it to the port my laptop is plugged into, I start seeing all of the traffic.  I can now see traffic coming and going from the XBOX ( as well as (my wife’s laptop) and (my laptop).


There are a couple of things you should know about span ports before you start using them.  Most notably, a destination span port doesn’t pass normal traffic. For instance, if I plug into the LAN, telnet into my switch, and configure my port as a span destination, I’m going to lose telnet access to the switch.  If I try to renew my IP address, I’ll get a 169.254.X.X address meaning the laptop wasn’t able to receive a DHCP address so it issued its own.  Destination span ports only receive copies of the data from the source port.  They aren’t designed to pass their own traffic in addition to this.    Just keep this in mind when configuring spanning.

Also, a source and destination span port need to be on the same switch.  I believe (not 100% sure here) that the exception would be something like a pair of 3750 stack switches.  Generally, I try to keep the source and destination ports on the same physical piece of hardware.

Configuring port spanning
Now let’s take a look at configuring the spanning.  For instance, in my example above, the switch connecting the 2800 router to the rest of my switching infrastructure is a Catalyst 2940.  Configuration was pretty straightforward.

2940#config t
Enter configuration commands, one per line.  End with CNTL/Z.
monitor session 1 source interface faste0/1
2940(config)#monitor session 1 destination interface faste0/2

The connection to the router was port fast ethernet 1 and my laptop was plugged into fast ethernet 2.  To disable the port span you simply issue the ‘no’ version of the command.

2940#config t
Enter configuration commands, one per line.  End with CNTL/Z.

2940(config)#no monitor session 1

Now you might be asking yourself at this point about trunks and VLANs.  In the above example, I slightly reconfigured my network.  Typically I use separate VLANs for different types of devices.  To make things more straightforward I put all the devices in the same subnet/VLAN.  The port connecting the router to the switch was configured as a trunk with DOT1Q encapsulation.  So what happens if we have multiple VLANs generating traffic across the trunk to different sub interfaces on the router?  The above configuration captures all of it.   Since I’m mirroring all of the traffic that traverses that port, I’m going to see everything from every VLAN.  Take a look at the WireShark capture below when I moved the XBOX to a different VLAN/Subnet.  The XBOX now has the IP of and is on VLAN 2.  Note that the capture shows traffic from both the 10.20.30.X and 10.10.10.X subnet which are defined in separate VLANs. 

The point of this article was just to clue you in to the fact that there are better options than physically plugging a hub into your network to analyze non-broadcast traffic. The configuration above is very basic, but for the most part all you would need to configure in order to analyze non-broadcast traffic on your LAN using an application such as WireShark. If you are interested in further span configurations check out this article which describes spanning on Cisco Catalyst series switches in much greater detail.


Tags: ,

Probably one of the larger items I have been getting config requests for is wireless configuration, specifically Guest and Production wireless SSID’s. That is to have an AP (Cisco!) that can host dual SSIDs. The Prod network can get everywhere and the Guest network can only get out to the internet. The thing about the base license ASA’s is that the DMZ can only go one way. That is it can’t be a real DMZ and connect back to you internal network as well. This makes it pretty useful as an interface for the guest network.  Also, this doesn’t have to be just for wireless.  Now that you have that VLAN you can tag it on some other access ports in your conference room for guests to use.  Just keep in mind that you’ll probably have to deal with some unhappy users who can’t get to their power point stored on the server from time to time.



-Insert your relevant information between <>
-Console prompts are show in green
-Text in blue are variable names I made up, feel free to change them

Pre Reqs
-A Cisco AP that can host dual SSID’s and is configured to do so (I used a 1230AG)
-A Layer 2 switch that can do trunking (I used a 2940) The non-Sec+ 5505’s don’t have the ability to trunk. So we need to use a managed switch and plug the AP into a trunk port (So it can see more than 1 VLAN) and then tag two access ports on the switch which connect to two corresponding access ports on the ASA one in each VLAN.
-A Cisco ASA that’s in production and has the 3rd interface available.  By production I mean it has NAT/PAT setup correctly and is a functioning firewall.

Configure a third VLAN (vlan 3)
ASA(config)# int vlan 3 
ASA(config-if)# no forward interface Vlan1 
ASA(config-if)# nameif GUEST 
ASA(config-if)# security-level 50 
ASA(config-if)# ip address <ip address> <subnet mask>

Assign the VLAN to a switchport
ASA(config)# int ethernet0/<Interface number>
switchport access vlan 3

Create a new DHCP scope for the guests and apply it to the VLAN
ASA(config)# dhcpd address <start address>-<end address> GUEST
ASA(config)# dhcpd dns <Outside DNS server> interface GUEST
ASA(config)# dhcpd enable GUEST

Enable outbound access by adding to the NAT
ASA(config)# nat (GUEST) 1 <Guest subnet number> <Guest subnet mask>

Configure the Managed switch you are using to connect the AP and the ASA
Configure a port on the switch for the AP
Switch(config)# int ethernet0/<Interface number>
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan <production vlan number>, 3

Configure a port on the switch for the Guest VLAN
Switch(config)# int ethernet0/<Interface number>
Switch(config-if)# switchport access vlan 3

Configure a port on the switch for the Production VLAN
Switch(config)# int ethernet0/<Interface number>
Switch(config-if)# switchport access vlan <production vlan number>

The cabling is pretty easy.  Plug a patch cable between the AP and the port you tagged as a trunk on the switch.  Then plug two more patch cables into the switch. One in the port you configured for VLAN 3 and the other into the port you configured for your production VLAN.  Then simply plug the other end of those cables into the ASA in the corresponding port per your VLAN configuration.  We are essentially doing the work of a trunk port with physical cabling.  Each cable is carrying traffic for a specific VLAN between the two devices. If we had a Sec+ license on the ASA we could take the switch out of the picture and tag the port on the ASA as a trunk.  This would allow it to carry both VLANs over the same cable.  Additionally with the Sec+ we could use the built-in POE on the ASA 5505 models to power the AP.

It’s not that hard to configure and setup, the catch is you’ll need a L2 switch if you don’t have a Sec+ license.

Tags: ,

Newer entries »