TAC Security Podcast Episode #2 - New Features Introduced with ASA Version 8.2

[Jay Johnston]

Episode Information

Episode Name: Episode 2 - New Features Introduced With Version 8.2

Contributors: Jay Johnston, Blayne Dreier, David White Jr., Magnus Mortensen

Posting Date: June 1, 2009

Description: In this episode, TAC engineers discuss how they use the Cisco labs to solve customer service requests. New features introduced with ASA version 8.2 are also discussed.

Listen Now    (MP3 44 MB; 32:03 mins)

Subscribe to the Podcast in iTunes by pasting the following link into your browser (which should launch iTunes) where you can subscribe to the podcast.

   itpc://www.cisco.com/cdc_content_elements/rss/security_podcast/security_tac_pcast.xml

Alternatively, you can search within iTunes for Cisco TAC Security Podcast, and subscribe there.  By subscribing, you will automatically receive future episodes when they are posted.

For users who would like an alternative method for subscribing, you can add the following URL into your favorite RSS reader, and subscribe to that feed.

   http://www.cisco.com/cdc_content_elements/rss/security_podcast/security_tac_pcast.xml

Episode Show Notes

• For information about the new features added to this release, read ASA version 8.2 release notes

• Download ASA version 8.2 software

About the Cisco TAC Security Podcast

The Cisco TAC Security Podcast Series is created by Cisco TAC engineers. Each episode provides an in-depth technical discussion of Cisco product security features, with emphasis on troubleshooting.

Complete episode listing and show information

[coffey.j]

Hi Jay et al,

Just wondering if you published an answer to this episode's quiz ?  The issue appears to be arp cache related and I am

wondering what workarounds you guys have (especially in an environment that drops gratuitous arps to servers and you don't control the servers.

On a related note, one of the issues i see with ASA/PIX and FWSM is if you have to physically upgrade, unlike a router, you don't have a virtual MAC created by HSRP group number. If you have the hsrp primary, standby and vip scenario it is easy to replicate the current arp entries in the end hosts because the VIPs MAC is purely a function of group membership (and hence configurable)  One workaround is to change the burnt in mac on the ASA but this doesn't appear to be an option on the FWSM.  Why do the security devices only use 2 addresses for failover and nor a virtual mac and ip.? Is it simply legacy or were you pre-empting the v4 exhaustion problem ;-)

[Magnus Mortensen]

Hey,

     You got it. It is an ARP issue. When the ASA power up, or configures an interface IP, we send a GRAT ARP for that IP. We do not send GRAT-ARPS when we configure or bring up a static translation. This can cause issues where the upstream device has the old MAC-Address for one of our static translations.

In the grat-arp-unfriendly environment you describe, there is litterally no mechanism to fix that issue except for changing the ASA's interface MAC address to match the old MAC.

- Magnus

[Jay Johnston]

Or reboot the upstream equipment; if it is locked in a closet somewhere, briefly cut the power to the building (joke, not recommended )

[coffey.j]

Thanks Magnus what do I win ;-).   More importantly did you have an answer as to why the failover doesn't have a virtual mac and virtual ip ? Is it just legacy or are there deliberate engineering reasons. Te virtual architecture seems cleaner than changing the burned in address.  (and you can't even do that on FWSM).

[Magnus Mortensen]

Wish I had a more exiciting reason, but it is primarily for legacy reasons.