Showing results for 
Search instead for 
Did you mean: 

TAC Security Podcast Episode #5 - Troubleshooting Firewall Failover, Part 2


Episode Information


Episode Name:Episode #5 - Troubleshooting Firewall Failover, Part 2

Contributors: Jay Johnston, Blayne Dreier, David White Jr., Kurt Chapman

Posting Date: November 4, 2009

Description: The panel of experts discusses the software version terminology and release process for the ASA, PIX and FWSM platforms. The episode then continues with part 2 of troubleshooting firewall failover.



Listen Now    (MP3 49.3 MB; 33:27 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.




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.


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



Hi TAC Gurus

I was listening to this episode this morning and have tried to log all level 1 messages to flash, to catch any failover as per your episode, however on my FWSM (4.2.1), the logging flash-bufferwrap command is not available.

Can anyone shed any light on how I can log failover messages to flash? I'm running A/A and have tried this in system, admin and my contexts.

Many thanks and keep up the sterling work! :-)

Jay Johnston
Cisco Employee

Thanks for the feedback; as you have discovered the FWSM does not support this feature.

With the FWSM it is a good idea to always ensure that you log these messages to a syslog server (at a minimum level 3 and lower), and perhaps add a static route your external syslog server in the FWSM's configuration. The static route might increase the chance that the syslog messages reach the server in the event that there are problems with routing protocols that are run on the FWSM (OSPF or RIP), which might cause a disruption of the routing table.


Cheers for the reply.

Content for Community-Ad