Let me see if I can find the report with show failover output ti send everyone then each one can make up there own minds.
Regards,
Joe Sanchez
On Jan 13, 2012, at 1:03 AM, "Armin Mirsepassi" <amirsepassi_at_ccgrp.com> wrote:
> No man, they are pulling your leg. As for the simple fact that "Each
> firewall must see its peer on the [**monitored**] data interfaces."
>
> However, you can disable monitoring of all the "data" interfaces and just
> monitor unit health and failover/state links for some weird edge case
> design. So you could make it work except for...
>
> I'm pretty sure they weren't thinking that because of the multi-homing of
> each unit in a pair to their counterparts. That made me laugh.
>
> Just curious what does OSPF have to do with redundancy between high
> availability firewall pairs? I don't understand where that would come into
> play between directly connected firewall pairs. These are being used as
> firewalls correct? Not some super expensive but crappy routers or l3
> switches?
>
> *****
> What would tracking get him? He controls both pairs of firewalls. If he has
> failover configured and then tracking he is checking for failure twice on
> the same object and enforcing failover twice. Either way, tracking and
> failover are there to handle two different design issues. Especially since
> he has state replication on. Tracking would kill all the sessions since it
> would change the egress interface once activated. Explain more please on how
> this helps?
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Radioactive Frog
> Sent: Friday, January 13, 2012 12:39 AM
> To: Antonio Soares
> Cc: Cisco certification
> Subject: Re: ASA Failover Design Issue
>
> Just use backup interface! or Tracking.
>
> On Fri, Jan 13, 2012 at 10:52 AM, Antonio Soares <amsoares_at_netcabo.pt>wrote:
>
>> 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
Received on Fri Jan 13 2012 - 07:37:41 ART
This archive was generated by hypermail 2.2.0 : Thu Feb 02 2012 - 11:52:51 ART