RE: ASA Failover Design Issue

You can configure preemption in A/A HA but his description of standby units
made it seemed like it was either or (at least how I read it) so I assumed
he was using A/S HA which has no preemption. Although in hindsight that term
is used in A/A configuration as well.

As to your other question, I have used ASA to ASA connection for failover
and state links in production environments. I do try to stay away from
direct cable connections because I cant remotely SPAN the port to see what's
happening in case of troubleshooting. And although I have never had a cable
go bad the Cisco doc's are pretty clear on the rules for initiating
failover. That's why I suggested calling TAC. He has either hit a bug on
software version, or the cables aren't the issue.

I just looked up the latest docs (didn't have these for older software
versions) and they recommend using the cable instead of a switch in
multitudes of scenarios. But their reasoning for the risk they are
mitigating doesn't make sense. They assume the switch is never going to
fail, so their design guides assume each of those switches have multiple
blades and redundant supervisors, not the case in a lot of data center
cabinets. All these designs are for "Avoiding Interrupted Failover Links"
and they seem to set you up for total outage in case of switch failure but a
good read anyways:
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ha_ov
erview.html#wp1089655

Failover rules (a/s and a/a)
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ha_ac
tive_standby.html#wp1079555
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ha_ac
tive_standby.html#wp1079555

For A/S
Failover link failed at startup
 Policy: No failover
 Active Action: Mark failover interface as failed
 Standby Action: Become active
 If the failover link is down at startup, both units become active.

Failover link failed during operation
 Policy: No failover
 Active Action: Mark failover interface as failed
 Standby Action: Mark failover interface as failed
 You should restore the failover link as soon as possible because the unit
cannot fail over to the standby unit while the failover link is down.

For A/A
Failover link failed at startup
 Policy: No failover
 Active Group Action: Become active
 Standby Group Action: Become active
 If the failover link is down at startup, both failover groups on both units
become active.

Failover link failed during operation
 Policy: No failover
 Active Group Action: n/a
 Standby Group Action: n/a
 Each unit marks the failover interface as failed. You should restore the
failover link as soon as possible because the unit cannot fail over to the
standby unit while the failover link is down.

-----Original Message-----
From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
Sent: Saturday, January 14, 2012 7:03 AM
To: Joseph L. Brunner
Cc: 'amirsepassi_at_ccgrp.com'; 'marco207p_at_gmail.com'; 'amsoares_at_netcabo.pt';
'ccielab_at_groupstudy.com'
Subject: Re: ASA Failover Design Issue

Joseph,
please share your findings about the behaviour with an ASA trying to reset.
I would like to reach some conclusion and I still think this thread is
confusing two different things: service interface with "monitor/query"
feature on one side, and FT link and FT and HA protocol (HELLOs/state).

In the former, a switch is mandatory. In the latter it is not.
The only place a 15" cable can be used is the failover link (and
stateful link).

That being the case, I fail to envision a fail case where the FT link
flapping causes more problems without a switch than with a switch.
And without a switch, a peer down recognition is immediate sometimes.

Are you saying that an Active ASA that only sees its FT link going down
might try to failover ? I find it ... pointless.

Armin:
there is preemption on multicontext. I don't know the details of the
preempt (coup ?) decision but a recovering ASA might try to regain
active state ?

-Carlos

Joseph L. Brunner @ 13/01/2012 21:21 -0300 dixit:
> You just made my point.
>
> Both asa's fail when they BOTH have at least 1 down interface (regardless
of peer ha keepalives status)
>
> Use a switch (or two) instead of cables between the asa's to always have 1
healthy asa, ok?
>
>
>
> ----- Original Message -----
> From: Armin Mirsepassi [mailto:amirsepassi_at_ccgrp.com]
> Sent: Friday, January 13, 2012 06:15 PM
> To: Joseph L. Brunner; marco207p_at_gmail.com <marco207p_at_gmail.com>
> Cc: amsoares_at_netcabo.pt <amsoares_at_netcabo.pt>; ccielab_at_groupstudy.com
<ccielab_at_groupstudy.com>
> Subject: RE: ASA Failover Design Issue
>
> I would call tac because there is no such thing as preempt with A/S HA.
The
> only time your original ASA will try to be active is if something fails on
> the secondary causing a failover. So what you are seeing is both your
ASA's
> failing.
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Joseph L. Brunner
> Sent: Friday, January 13, 2012 3:54 PM
> To: 'marco207p_at_gmail.com'; 'amirsepassi_at_ccgrp.com'
> Cc: 'amsoares_at_netcabo.pt'; 'ccielab_at_groupstudy.com'
> Subject: Re: ASA Failover Design Issue
>
> I'm sure he was responding to me... Sorry - but I'm in the realtime
managed
> services business for trading firms and power generation companies - we
> simply can't have surprise issues.
>
> I have replaced many 18 inch cables between pairs of asa's lately. An asa
> with a failed interface will reset it self and try to become in its normal
> state at random periods possibly dropping connections. I have email
scripts
> I'll share with the group- we get email alerts when this happens on a
> secondary asa with its fo interface down cause the primary is dead - and
of
> course our monitoring systems (and angry clients calling in) notice...
>
> So an asa with 1 failed interface even fo is no good for us
>
> Joe
>
>
> ----- Original Message -----
> From: George J. Sanchez [mailto:marco207p_at_gmail.com]
> Sent: Friday, January 13, 2012 03:49 PM
> To: Armin Mirsepassi <amirsepassi_at_ccgrp.com>
> Cc: Joseph L. Brunner; <amsoares_at_netcabo.pt> <amsoares_at_netcabo.pt>;
> <ccielab_at_groupstudy.com> <ccielab_at_groupstudy.com>
> Subject: Re: ASA Failover Design Issue
>
> Armin, not sure which Joe you are addressing this, if it is me Joe
Sanchez;
> then I would say your tone and attitude is pretty nasty.. I will not
respond
> any further.
>
> Regards,
> Joe Sanchez
>
> On Jan 13, 2012, at 12:49 PM, "Armin Mirsepassi" <amirsepassi_at_ccgrp.com>
> wrote:
>
>> Joe I am well aware how ASA HA behaves in most scenarios. My question to
> you
>> was
>>
>> "Can you sanitize your "firewall to firewall data interfaces direct
> connect"
>> setup from your customer and share it, because you are insinuating that
it
>> is possible to do that and have HA."
>>
>> I do not see how what Antonio's customer is stating as working can
> actually
>> work. You keep insinuating that it can work because you have crappy
>> customers that have it. So please don't be a tease and help a brother out
>> with a config or explanation of the setup where it would work. You're not
>> helping anyone out with just rhetoric.
>>
>> armin
>>
>> -----Original Message-----
>> From: Joseph L. Brunner [mailto:joe_at_affirmedsystems.com]
>> Sent: Friday, January 13, 2012 12:40 PM
>> To: Armin Mirsepassi; marco207p_at_gmail.com
>> Cc: amsoares_at_netcabo.pt; ccielab_at_groupstudy.com
>> Subject: RE: ASA Failover Design Issue
>>
>> Nope... wrong...
>>
>> We use 2 switches, one on each asa.
>>
>> The asa with the perfectly healthy interfaces continues unencumbered with
> a
>> down failover interface :)
>>
>> We are not talking about "most people"... his design was looking for
>> failover... here's a question for you and lets see if you or anyone else
>> gets it?
>>
>>
>> What does an ASA do that has down interfaces Itself, but does not see its
>> failover neighbor?
>>
>> Now, tell me what you would rather have, 1 ASA (primary active or
> secondary
>> active) all interfaces healthy up, but not able to see its neighbor
>>
>> -or-
>>
>> One or both ASA's with a down interface?
>>
>> (If you don't know what is going to happen to the traffic you should
>> probably lab this up for 24 hours) :0)
>>
>> -Joe
>>
>> -----Original Message-----
>> From: Armin Mirsepassi [mailto:amirsepassi_at_ccgrp.com]
>> Sent: Friday, January 13, 2012 12:11 PM
>> To: Joseph L. Brunner; marco207p_at_gmail.com
>> Cc: amsoares_at_netcabo.pt; ccielab_at_groupstudy.com
>> Subject: RE: ASA Failover Design Issue
>>
>> Joe how does a switch remove your failure? You just moved your single
> point
>> of failure to the switch. A switch failure causes the same issues as a
>> direct connected cable failure (split brain scenario). You could have
just
>> as easily just replaced the patch cable and you would be in same risk
>> scenario. Unless you're saying a complicated switch is less likely to
have
> a
>> failure then 4 strands of copper. The most common reason for direct
>> connecting both the failover and state links is its a cheap method of
> saving
>> 4 ports in maxed out access switches in already crammed cabinets in
> already
>> crammed data centers. It has its pro's and con's in designs.
>>
>> You can throw in 2 switches, but you cant get around the fact that
>> *monitored for HA* ports need to be able to send HA hello messages to
each
>> other, so you need to trunk the switches to carry all vlans used by any
>> *monitored* interfaces (and the state/failover vlans). Hopefully, with
> more
>> then one port to remove that single trunk port point of failure.
>>
>> However, most people use only one switch (on the access side) because
most
>> of the time your carriers only hand off one physical connection for a
> path.
>> So in the end the switch that has that carrier is the single point of
>> failure.
>>
>> And what does directly connected firewalls have to do with how eigrp is
>> (mis)configured on firewalls. So equivalently, are you saying if you
>> directly connect 2 interfaces on 2 routers it wont work unless you throw
> in
>> a switch between the 2 routers?
>>
>> Can you sanitize your "firewall to firewall data interfaces direct
> connect"
>> setup from your customer and share it, because you are insinuating that
it
>> is possible to do that and have HA.
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Joseph L. Brunner
>> Sent: Friday, January 13, 2012 10:10 AM
>> To: 'marco207p_at_gmail.com'
>> Cc: 'amsoares_at_netcabo.pt'; 'ccielab_at_groupstudy.com'
>> Subject: Re: ASA Failover Design Issue
>>
>> Have you ever had a customer failover due to power loss or a bad cable
and
>> drop connections when the devices failed back and forth all due to a 18
> inch
>> cable between the two firewall's fo interfaces? Instead of using a
switch?
>>
>> Know what we call that customer in my firm? "The Fortinet Customer" lol
>>
>> They got tired of these little issues before I could save the account for
>> cisco...
>>
>> Believe me I never just harp on the whitepaper or "what tac supports" (I
>> don't call tac except for parts replacement) - but you don't want
> firewalls
>> cabled directly together for many reasons...
>>
>> Another gotcha with the "firewall cabled to firewall" design and we saw
> this
>> tuesday - we had the same eigrp route coming in via two interfaces - it
>> choose an asymmetric way back and what do asa's do with asymmetric paths?

>>
>> Block
>>
>>
>> ----- Original Message -----
>> From: George J. Sanchez [mailto:marco207p_at_gmail.com]
>> Sent: Friday, January 13, 2012 08:36 AM
>> To: Joseph L. Brunner
>> Cc: Antonio Soares <amsoares_at_netcabo.pt>; Cisco certification
>> <ccielab_at_groupstudy.com>
>> Subject: Re: ASA Failover Design Issue
>>
>> Joe, I've also read this whitepaper and the ASA cisco press books that
say
>> the same thing, however this not true. I've tested this many times and
> had
>> other engineers test the same setup with positive Results. With that
> being
>> said TAC may not support the setup, but to this day I've never had a
>> customer comeback and indicate any problems with this design.
>>
>> Regards,
>> Joe Sanchez
>>
>> On Jan 12, 2012, at 6:26 PM, "Joseph L. Brunner"
<joe_at_affirmedsystems.com>
>> wrote:
>>
>>>> I need help with this one. I have a customer asking me to connect two
>> pairs of ASAs directly, without any switch in the middle. I never saw
>> something like this and >after a few hours playing with this setup, I'm
>> almost giving up.
>>> This is why the CCDE exists... to vet bullsh*t designs from people
>>> that
>> really should not be designing... If you read the Cisco white paper on
>> failover it clearly says the design of failover is to use a switch to
> avoid
>> "both interfaces down the firewalls fo interface".
>>> I have done "all routed asa's" but used load balancers in between also
>> running ospf...
>>> Good luck.. bad design... probably not the results you want if you do
>> figure it out anyway...
>>> -Joe
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
>>> Of
>> Antonio Soares
>>> Sent: Thursday, January 12, 2012 6:53 PM
>>> To: 'Cisco certification'
>>> Subject: ASA Failover Design Issue
>>>
>>> Hello group,
>>>
>>> I need help with this one. I have a customer asking me to connect two
>> pairs of ASAs directly, without any switch in the middle. I never saw
>> something like this and after a few hours playing with this setup, I'm
>> almost giving up.
>>> Please check here the diagram:
>>>
>>> http://www.ccie18473.net/failover.jpg
>>>
>>> I'm running OSPF between the two pairs of ASAs in order to get maximum
>> redundancy. Suppose that initially FW-1 and FW-3 are active. The first
>> problem I see is that only one OSPF adjacency is up, between the active
>> ASAs. I understand that this happens because OSPF is inactive on the
> standby
>> ASAs. Ok, the setup is broken because is FW-1 goes down, I would need to
>> wait for the new OSPF adjacency between FW-2 and FW-3. Another issue I
see
>> is that if I play a little with "failover active" and "no failover
> active",
>> this becomes completely broken: the ASAs start moving from active to
> standby
>> without any pattern. I think this is because the ASAs in each pair don't
> see
>> each other. Ok, this seems to be completely against the basic ASA
Failover
>> design. Each firewall must see its peer on the data interfaces.
>>> Can somebody tell me if this is possible to achieve ? The customer
>>> keeps
>> telling me that there are other vendors that do this without any
issues...
>>> Thanks.
>>>
>>> Regards,
>>>
>>> Antonio Soares, CCIE #18473 (R&S/SP)
>>> amsoares_at_netcabo.pt
>>> http://www.ccie18473.net
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> ______________________________________________________________________
>>> _ Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> ______________________________________________________________________
>>> _ Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net