Blog: Cisco

Here are a couple tips for working with Cisco sticky MAC addresses on port security:

If a mac address has been assigned by port security to one port and the device is then moved to another port you have to clear the mac address off of the old port before the new port will allow this device to pass traffic even if the new port does not have port security enabled.

Also if you are seeing a duplicate mac address and seeing two interfaces interchangeably locking each other out when the other is enabled you might check to see if someone has two ports on a phone plugged into these ports. I ran accross this at a customer site recently where it was creating a loop on the two interfaces.


 
 

Cisco devices will ignore leading spaces when entering passwords, but spaces after the first text character are considered valid.  This includes trailing spaces, so if you have a device that will no longer accept your login after changing the password, try adding a space at the end.


 

I recently started reevaluating how we do port security as a result of a recent customer's information security audit.  We normally turn on port security and set the maximum MAC addresses to 1 (the default) or 2 (if there is an IP phone connected).  The default behavior is to disable the port when the MAC changes or if the number of concurrent MAC’s exceeds the maximum.

However during testing I discovered this didn’t work exactly like I expected.  Port security was enforced as long as a device stayed connected to the port.  If the port was disconnected, the switch would remove the pre-existing MAC’s and ANY new device could connect, as long as the maximum was not exceeded.  While this prevents unauthorized hubs and switches, it doesn’t prevent someone from unplugging a device and plugging in a different unauthorized device.

The solution to this is to use the sticky option on the port security interface command: [more]

  • switchport port-security – enables port security, optional “maximum <n>” to set the max greater than 1
  • switchport port-security mac-address sticky – turns on the sticky MAC feature

After enabling, you will notice the currently connected MAC address(es) will appear in the running config:

  • switchport port-security
  • switchport port-security mac-address sticky
  • switchport port-security mac-address sticky 0080.6433.xxxx

This will stay in the config until the switch is rebooted, so it’s important to write the config.

Other related commands:

  • show port-security address – lists all the learned MAC addresses by interface
  • show port-security interface fa0/1 – shows the detailed port security settings for an interface, including enable/disable status
  • clear port-security sticky interface fa0/1 – clears the learned sticky MAC addresses, must be done prior to a shut/no shut to re-enable a port disabled due to port security

When you use sticky MAC addresses you'll want to make sure that the MAC addresses are cleared off of a switch when a device is moved.  We had a laptop that was moved from one client location to another and one of the distribution switches was thinking the device was plugged into the old switch and the other distribution switch thought it was plugged ito the new switch.  This created a situation where some network traffic was reaching the laptop and some was going into a black hole.  After clearing the the sticky MAC addresses on the old switch the problem was resolved.

Update:  You might also be interested in a couple stick MAC address tips.


 

Multiple vulnerabilities have been discovered in Cisco ASA and PIX devices running version 7.x and 8.x software. Cisco has released free software updates to address the vulnerabilities. Installation of updates will require after hours work and device reboots.

For more information about individual vulnerabilities, refer to the following link:
http://www.cisco.com/warp/public/707/cisco-sa-20080604-asa.shtml

[more] If you'd like help updating your Cisco ASA and PIX devices, please contact CoNetrix at support@conetrix.com or call (800) 356-6568.


 

When setting up a Cisco Express 500, the instructions strongly recommend that you use the Smartport feature for each of the ports. I enabled the port that was an uplink port as a “Switch Port” as recommended. However, I could not get any traffic to pass through to the uplinked switch. There were NO errors or any indication on the Catalyst Express that anything was wrong. I finally saw this small blurb in the setup manual: [more]

The Smartport role Switch automatically enables 802.1Q trunking on the port. If a remote switch does not support 802.1Q trunking or the trunking is manually turned off, the spanning tree state of the port on the remote switch goes to blocking for type inconsistency. If the remote switch is the root bridge, the switch port does not go to blocking mode. In this case, the switch port trunk status is ON at both ends of the switches, but there is not any communication between the switches through these ports. There are no diagnostic messages displayed on the Catalyst Express 500 device.

I removed the Smartport feature on this port and traffic immediately started flowing.


 

I was researching a way to do major router changes remotely.  I found that if I tftp’ed a new configuration directly to NVRAM and replaced the startup-config file, then reloaded the router, all changes would go into effect.  While testing this process locally, I found out that when the router was reloaded with the new configuration file, the SSH encryption keys got erased and had to be regenerated.  So if this process is used, make sure telnet is enabled on the VTY lines so that you can get back into the router!


 

We have had recently had a problem with a Cisco 3560 PoE switch and a Toshiba IP phone. The issue is that when a call is made from a Toshiba IP phone (problem spanned phone and phone/firmware versions), the conversion was one way. The party on the remote end could not hear the party in private banking. We have this switch deployed several other places with the same version of IOS and don’t see the issue. Finally the mystery has been solved. After running capture on the links and doing troubleshooting, I was able to determine that the "switchport voice vlan 1" command on each interface that was used for a phone was the magic bullet. For some reason, in its given setup, this switch needs this command to make everything work whereas it isn’t needed in other places. Cisco is current still looking into the issue and last I heard it is at TAC level 4.


 

We use the ip tcp adjust-mss command on Cisco routers to set the maximum segment size for TCP connections going over VPN connections.

To find the optimum maximum segment size, be sure to use the do-not-fragment option when pinging across the link.  Sending a regular ping will show you the largest packet size that will make it across the link; using the df flag will tell you the largest packet that can traverse the link without being broken into multiple parts.  To set the do-not-fragment flag using the Windows ping utility, add "-f" to the command line.

Also, be sure to perform the same test over the regular, non-tunneled connection to the destination router.  Make sure your adjust-mss value is lower than the maximum non-fragmented packet.


 

We have struggled with CRC errors on routers with 2 frame relay circuits connected to a dual channel T1 card.  The CRC errors seemed to only occur on the newly added secondary port on the card, and the connectivity would act intermittently.  In working with Cisco, I have learned that both ports’ default clock is set to ‘line’ which gets the clocking from the ISP.  When both ports are set at ‘line’, they both battle to keep up with the clocking.  To fix this problem, set one of the T1 controller’s clock source to ‘internal’.  This tells the port to get clocking from the other port configured as ‘line’.