DHCP Snooping and ARP inspection are two fantastic little layer 2 security features.  I won’t go into the configuration since they has been described quite well in lots of other blogs.

ARP inspection relies on the DHCP binding table that DHCP snooping builds on the switch.  Since this is lost if the switch reboots, hosts would need to re-DHCP in order to be able to send ARPs out.  A nice fix for this is to backup the binding table to a TFTP server like so:

ip dhcp snooping database tftp://10.10.10.10/mydhcptable <-name of the file to be saved; needs be unique for each switch

When I first enabled this I got the following error message:

%DHCP_SNOOPING-4-AGENT_OPERATION_FAILED: DHCP snooping binding transfer failed. Unable to access URL.

The Cisco documentation for this error lists several causes, but none of them seemed to apply to my situation.  After much searching around, it seems that the file needed to be created on the TFTP server first.  I created a text file and uploaded it to the TFTP server and then tried to enable the binding backup again and got this message:

%DHCP_SNOOPING-4-AGENT_OPERATION_FAILED: DHCP snooping binding transfer failed. Expected more data on read

Before I could even start to look this one up I then saw this:

%DHCP_SNOOPING-6-AGENT_OPERATION_SUCCEEDED: DHCP snooping database Write succeeded

I did a TFTP get of the file from the server and sure enough, it had a list of MAC address to IP bindings.

Use caution when enabling these features on a production network.  I enabled them first on a test switch and tried out a few scenarios to see the results.

Links:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swdhcp82.html

http://packetlife.net/blog/2010/aug/18/dhcp-snooping-and-dynamic-arp-inspection/

I’m in the middle of migrating from our VPN3k to using our ASA’s to terminate the VPN connections.  Everything was going along smoothly until I noticed that I couldn’t authenticate using an account in a specific group on our ACS server.  I did a RADIUS debug and some Googling and discovered that the VPN3k uses wildcard masking in its downloadable ACLs, while the ASA expects ACLs to use VLSM masks.

After a few minutes of looking through the multiple groups on the ACS server I discovered that lots of them had downloadable ACLs and I figured I was going to have to re-write them all as I migrated those users over to the ASA.  I took a few aspirin to quell the building headache and then started doing some keyword searches and found a way around all that extra work.  A lovely little command called acl-netmask-convert.

The default value for this command is “standard”, but after changing it to “wildcard” I was able to authenticate without issue.  I then tested the efficacy of the downloadable ACL and found it worked the same as it did with the VPN3k.

Thank you Cisco!  :0)

A few days ago I was writing a regular expression for a string match on one of the ASAs at work.  It should have been a simple exercise as all I wanted to do was block files with the “.lnk” extension via http inspection.  After perusing my notes, I came up with this: “\.[Ll][Nn][Kk]$”.  I thought to my self, “Great! That should take care of the file no matter what case letters are used.”  How wrong I was.

I attempted to test the regex using the fantastic test feature in the ASA.  I checked it against “file.lnk” and was quite surprised when the message came up “match failed”.  After much searching through the ASA documentation pertaining to regular expressions I noticed that while there was mention of the beginning of line anchor “^”, the end of line anchor “$” was missing.  Figuring it must be an oversight in the documentation, I checked the documentation of the IPS, which also supports regex string matching, and sure enough, there was the “$” fully documented.  I tried several variations of the regex and finally achieved a partial success by leaving off the end line anchor.  While this did match “file.lnk”, it also matched “www.lnk.mydomain.com”.  I worked with some of the folks in our Systems department and they assured me that the way I had originally written the regex string should have worked.

With no success finding an answer via web search, I posted on the Cisco Support Community forums.  Within a few hours I got a reply from a TAC engineer who relayed the following to me: “The ASA/PIX Regex engine does not support the end of string anchor ($). Bug CSCsm89915 has been filed as an enhancement to get this functionality into the regex engine. Unfortunately there has been no movement on that enhancement sine 2008.”

I am at a loss as to why something that one would think it would a relatively minor fix like this has yet to be corrected.  Regular expressions are very powerful and highly useful tools.  I realize that I can work around this by adding additional “match not” statements and additional regex strings, but this really shouldn’t be necessary.

I guess I’ll email our Cisco account rep and ask him to drive the bug as was suggested by the TAC engineer.