Cisco ASA 5510 Active/Standby Pair - Polling/Standby IP Questions

[Jim R]

Hi all,

Have had a bit of a weird problem with a Cisco ASA 5510 Active/Standby pair configured by someone else and left for me to install.  Basically after around a minute or so of being connected local LAN connectivity would be lost to the whole subnet that the ASA was connected to (Even though no traffic was passing through that ASA).  Removing the ASA from the network appeared to fix the problem.  Having very little time to diagnose properly I blew away the configuration and re-configured the device from scratch which fixed the problem.

Having a bit more time now I am trying to determine the "why" behind the previous problem I compared the two configurations and found a couple of subtle differences but nothing hugely conclusive.  So I decided to do some digging and have since come up with the following gaps in my understanding and was hoping someone could help:

1) Polling and device health:  I know that there is a 'failover' interface between the two which helps the devices find out whether the other device is still a live (I.e. software ok, physical connectivity ok) but what happens if this cable fails but all interfaces are still ok on both devices?  Does the ASA pair also check health using the primary/standby addresses assumoing they are assigned?

2) Standby Address:  Leading on from the previous questions, can someone tell me, other than for management, EXACTLY what the standby IP address gets used for?  Is it used for the above and can someone explain in some detail what communication passes between them?  If no address is configured does this mean the only time a ASA will fail over is when the primary device is physically off or the failover cable is disconnected (As it is my assumption the devices cannot monitor interface health without the standby address)

Actually question 2 was quite a few questions wasn't it ?

Any answers or discussion would be greatly appreciated.

Jamie

[Mohammad Alhyari]

Hi Jamie ,

thanks for postinhg this here !

1-we have the failover interface and the remaining ASA normal interfaces such as outside and inside .

unit monitoring is done on the failover interface to check if the other unit is alive and also to replicate the configuration , obtain the IP and MAC addresses of the primary unit . this interface is monitored and you can say that each units sees the other unit through this interface, if this interface fails through operation no failover will happened but the unit will not be able to see the other unit and if you restarted the secondary it will become the active one .

we have another thing that is called interface health monitoring , each ASA send hellos out each monitored interface and wait to hear a hello  from the second unit , ip addresses to do this exchange are the primary and the standby IPS of the interfaces , now if the ASA (Active ot Standbye ) . didn't recieve a hello from the other unit for the interface poll time , then it will start testing the interface within the following procedure :

-line up down.

-ARP.

-ping

if the test passed then no failover will happen , if failed then the device will failover.

by default all physical interfaces are monitored and subint are not monitored .

2-as mentioned above standby addresses are used for the hello exchange on the ASA monitored interfaces other than the failover interface iteslf, so you need them to detect failed data interfaces

for example on the primary outside int you will see those packets :

hello from [active ip] dst [standby ip] "assuming the primary is active"

see this intresting Link :

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

see failover triggers

HTH

Mohammad.

[Jim R]

Hi Mohammad,

Thanks for taking the time to get back to me.   It looks like what more than likely happened is the failover link cable (which was not a cross over cable) resulted in the interface being down on boot which would have resulted in both devices being active on startup.

We would have obviously of had an IP address conflict but two seperate MAC addresses so I am happy that at layer 2 non of the above would have caused a problem. 

Looks like I am down to VLAN tagging or some dodgy duplex/speed/switch combination of events which broke this particular setup.  I'll keep looking

Thanks again,

Jamie

[Mohammad Alhyari]

Anytime Mate .

Mohammad.