Category Archives: Cisco

Cisco Catalyst Switch Unsupported SFP err-disabled Port

If you have a third party or unsupported SFP installed in your switch the switchport will go to err-disabled state. By running the command show interface status err-disabled you will see the reason is Unsupported SFP.

Obviously the recommended thing to do is purchase a valid, supported SFP that Cisco recommends so if you have any issues you can call them for support. If you don’t have one handy or the time, do the following.

Run the following command:

service unsupported-transceiver

Do not try to tab-complete the command as it is a hidden IOS command. Type it in, hit enter, then you will see the following warning:

Warning: When Cisco determines that a fault or defect can be traced to
the use of third-party transceivers installed by a customer or reseller,
then, at Cisco’s discretion, Cisco may withhold support under warranty or
a Cisco support program. In the course of providing support for a Cisco
networking product Cisco may require that the end user install Cisco
transceivers if Cisco determines that removing third-party parts will
assist Cisco in diagnosing the cause of a support issue.

Furthermore, enter this command as well to disable the switch from putting the port into err-disabled state in the future:

no errdisable detect cause gbic-invalid

Setup DHCP Reservation on Cisco Router/Switch

If you want to configure a DHCP reservation on a switch or router, gather the MAC address of the device. If you are unsure of the MAC address of the device, you can find the current IP address and issue the following commands to get the MAC address and clear the DHCP binding before you create the pool.

show ip dhcp binding | include
clear ip dhcp binding

Next, run the following commands to setup the reservation. Obviously change the pool name and the IP addresses referenced to match your environment. You may notice that the client-identifier below is 14 digits rather than 12 like a standard MAC address. You have to append 01 in front of the MAC address.

ip dhcp pool My_Reservation
client-identifier 01f0.cba1.6916.96
domain-name yourdomain.local

Cisco ASA VPN LDAP Password Management

If you wish to enable password management for LDAP on a Cisco ASA VPN profile, there are certain requirements to be met.

  1. LDAP over SSL must be enabled for the aaa-server group.  Issue the command: ldap-over-ssl enable on the aaa-server host properties.
  2. The domain controller(s) that you are authenticating to must support LDAPS. You can accomplish this by installing Certificate Services on the domain controller and rebooting it. Once that is done, it will accept LDAPS queries.
  3. You must enable the command password-management on the tunnel-group for the VPN.
  4. Optionally, you can use option  password-expire-in-days <# of days> under password-management to notify users that their password will be expiring. If you do not specify that, users will not be notified but will still be able to change their password once it expires.
See the below commands for an example of a full configuration.
aaa-server MyLDAP protocol ldap
aaa-server MyLDAP (inside) host
 ldap-base-dn DC=My, DC=com
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-password *****
 ldap-login-dn CN=ASA VPN, CN=Users, DC=My, DC=com
 ldap-over-ssl enable
 server-type microsoft

tunnel-group Myvpn-LDAP general-attributes
 address-pool ippool2
 authentication-server-group MyLDAP
 default-group-policy Myvpn-AD
 password-management password-expire-in-days 3

ASA 8.4 – no valid adjacency

I recently went through the process of upgrading a customer’s ASA from 7.2 to 8.4 code.  After the upgrade was finished, I noticed that internet access for my VPN users coming in over a full-tunnel connection was failing.  The debugging I did led me to seeing TCP connections being torn down due to “no valid adjacency.”  This was caused by a NAT rule sourcing from any destined for my VPN subnet. Based on looking at the configuration, I believe the NAT rule was used to NAT exempt internal network traffic to the VPN users.

In the examples below, these are the object groups:

object-group network Inside_LAN

object-group network VPN_Clients

The NAT rule causing the problem was:

nat (inside,any) source static any any destination static VPN_Clients VPN_Clients

I fixed the issue by setting up a more restricted NAT rule:

nat (inside,any) source static Inside_LAN Inside_LAN destination static VPN_Clients VPN_Clients

ASA 8.3+ Asymmetric NAT rules matched for forward and reverse flows

For site-to-site (L2L) VPN connections, you may see the following error message on 8.3(2) and later configurations:

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src Outside:x.x.x.x/3214 dst inside:y.y.y.y/80 denied due to NAT reverse path failure

This is due to the unidirectional keyword setup on your NAT configuration that was migrated incorrectly. If you upgraded from 8.2 code directly to 8.3(2) and did not go to 8.3(1) first, the NAT migrations will tag a unidirectional keyword on all the NAT rules which will essentially only allow one-way traffic initiated only from the source side.

Your configuration will look something like this:

nat (inside,any) source static obj-x.x.x.x obj-x.x.x.x destination static obj-y.y.y.y obj-y.y.y.y unidirectional

Simply remove the unidirectional keyword to make your configuration look like the following and you will be good to go.

nat (inside,any) source static obj-x.x.x.x obj-x.x.x.x destination static obj-y.y.y.y obj-y.y.y.y