Skip navigation
Cisco Learning Home > CCIE Security Study Group > Discussions
This Question is Not Answered 1 Correct Answer available (4 pts) 2 Helpful Answers available (2 pts)
5521 Views 13 Replies Latest reply: Jul 27, 2012 11:21 PM by zac ragoonath RSS

Currently Being Moderated

ASA Failover incident what happens when failover take place

Sep 1, 2011 2:28 AM

Rajesh Agrawal 71 posts since
Nov 2, 2009

Any Body  can exlain little about ASA Failover incident what happens when failover occures. If you can tell me step by step like how does gratituos ARP injecteded to the standby device and all.

 

Thanks

Rajesh Agrawal

 

 

  • Aaron 129 posts since
    Aug 23, 2009

    Hi,

     

    Basically, when the standby unit, or in case of A/A FO, the standby context, detects a fail on the primary unit, then it assumes all the IP and MAC addresess of the failed unit. Through the failover link, both units are replicated in real time, so the standby unit becoming active can take care of the connections,

     

    Cheers, 

  • CCIE_2B 124 posts since
    Nov 5, 2009

    HI.

    the secondary device asume the IP and MAC of the primary, threfore, for the station behing the ASA nothing changes, they will just send the traffic as nothing happen, on a statefull failover all the state table are passed continuoslly between devices, so the failover takes places, most of the connection can persist.

  • Jesse 7 posts since
    Oct 29, 2009

    From Cisco's Website

    http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080834058.shtml

     

    I do remember reading that the ASA sends out a gratuitous ARP when it becomes active after failover. (will try to find the doc)

    When a failover occurs, all active connections are dropped. Clients need to re-establish connections when the new active unit takes over.

    When stateful failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.

    The state information passed to the standby unit includes these:

    • The NAT translation table
    • The TCP connection states
    • The UDP connection states
    • The ARP table
    • The Layer 2 bridge table (when it runs in the transparent firewall mode)
    • The HTTP connection states (if HTTP replication is enabled)
    • The ISAKMP and IPSec SA table
    • The GTP PDP connection database

    The information that is not passed to the standby unit when stateful failover is enabled includes these:

    • The HTTP connection table (unless HTTP replication is enabled)
    • The user authentication (uauth) table
    • The routing tables
    • State information for security service modules

    Note: If failover occurs within an active Cisco IP SoftPhone session, the call remains active because the call session state information is replicated to the standby unit. When the call is terminated, the IP SoftPhone client loses connection with the Call Manager. This occurs because there is no session information for the CTIQBE hang-up message on the standby unit. When the IP SoftPhone client does not receive a response back from the Call Manager within a certain time period, it considers the Call Manager unreachable and unregisters itself.

  • Jesse 7 posts since
    Oct 29, 2009

    This is from a old PIX document but it states that this is done in version 5.2 and later...

     

    http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094ea7.shtml

    Operating Failover in Switched Environments

    There are two issues to address in switched environments. First, the switch needs to learn that a particular MAC address has moved from one port to another. Each unit (unless the unit is failed) transmits a series of failover messages on each interface with the use of its new MAC and IP addresses. This allows the switch to update its internal MAC tables. Cisco strongly recommends that customers enable portfast on all switch ports that connect to PIX interfaces. In addition, channeling and trunking need to be disabled on these ports. Thus, if the interface of the PIX goes down during failover, the switch does not have to wait 30 seconds while the port transitions from a listening to learning to forwarding state.

    This blocking of network traffic brings us to the second issue. If the "hello" packets that are sent by failover do not get forwarded, each unit thinks something is wrong and begins to test its interfaces. This results in the failure of one unit because the test results are "if I am okay, then you must be failed." In order to get around this problem, any time a switchover takes place, the units enter a "waiting" state. In this state network traffic is free to flow through the active unit, but failover waits for two "hello" messages to be received before it monitors interfaces again. This allows the switch to enter a blocking state without disrupting failover. Once the second "hello" message is heard, failover resumes normal monitoring of its interfaces.

    For PIX Software version 5.2 and later, when a device changes state from standby to active, or from active to standby, a gratuitous ARP is set to each network interface to rebroadcast the new IP and MAC addresses.

  • Jesse 7 posts since
    Oct 29, 2009

    As my 2nd post says, a gratuitous ARP is sent by both devices (granted both are "healthy" enough) out failover interfaces. As far as traffic level info, if i had 2 ASAs in a lab i would configure and do a packet capture during failover.  But i don't think you will find that level of detail in Cisco docs.

     

    HTH

  • Bruno Silva 17 posts since
    Mar 10, 2010

    Hello Rajesh,

     

    This is my simple explanation about failover.

     

    First of all, I assume you have perfect understanding of how failover works in general because we have stateless failover and statefull failover. In statefull failover no connections are dropped and the state table gets replicated to the standby unit.

     

    Anyways, whenever failover occurs here is what happens:

     

    Using cisco words:

     

    When stateful failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.

    The state information passed to the standby unit includes these:

    • The NAT translation table
    • The TCP connection states
    • The UDP connection states
    • The ARP table
    • The Layer 2 bridge table (when it runs in the transparent firewall mode)
    • The HTTP connection states (if HTTP replication is enabled)
    • The ISAKMP and IPSec SA table
    • The GTP PDP connection database

    The information that is not passed to the standby unit when stateful failover is enabled includes these:

    • The HTTP connection table (unless HTTP replication is enabled)
    • The user authentication (uauth) table
    • The routing tables
    • State information for security service modules

     

    After all this replication happens the ASA assume the active ip address and send a gratuitous arp to the devices on the network so they can update their ARP entries. I guess this is the step you were strugling at.

     

    Best Regards,

    Bruno Silva.

  • MIKIS 78 posts since
    Dec 12, 2010

    Hello

     

    I run a small failover lab and I used SPAN to capture the traffic on one of the ASA's data interfaces. The following screenshot shows the Gratuitous ARP that was generated during the failover. This information is also mentioned in 'Cisco ASA: All-in-One-Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance' book in page 552.

    By the way, SCPS (IP protocol 105) is the protocol used for interface and unit polling.

     

    ASA_failover_gratuitous_ARP.JPG

     

    Regards

  • Aakil 69 posts since
    Apr 29, 2012

    Dear Rajesh,

     

    You are right that gratuitous ARP injected by ASA to other connected Device. But the best solution to implement failover is to use a virtual mac address, if you will use the Virtual mac address for failover then the ARP entries will not get changed and there will be no timeout anywhere on the network. If you are not using the virtual mac address then if failover occurs in that case the arp entries will be chagned and when the new device takes over the active state then it will send the gratituous arp

     

    Regards,

     

    Aakil

  • zac ragoonath 2 posts since
    Oct 6, 2008

    Hey guys thannk you for each takign the time to explain and prove even the gratuitous arp.

    cheers

    zac

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)