I would like to confirm how ASA Failover would handle a situation
The scenario would be the following:
- Two ASAs running 8.4
- One physical link with subinterfaces connected from ASA to Cisco 7609 (subinterfaces configured with the "monitor-interface" configurations)
- Separate customer links forward from the 7609 to the customer
- Physical connections = ASA ----7609 ----- Stack (So ASA is not really aware of the actual customer link)
- L2 connections all the way from ASA to customer (ASA to 7609 and 7609 to Customer links connected trough configurations on the 7609)
- Customer C3750 stack with SVI for all the customer data subinterfaces on the ASA. SVIs in different VRFs
What I'm interested in is what happens if lets say the main fiber link from 7609 to Customer goes down?
Primary ASA won't see this as its connection to the 7609 is still fine.
If I understand correctly it would first notice that the customer subinterfaces Failover Hello -packets wouldn't be going through and start performing tests to determine the state of Failover
The ASA documentation says that one of the first tests the ASA would do is to check if its interfaces packets counters would be increasing.
This brings me to the next question. Would it be possible that the link between ASA and the C7609 would still be generating somekind of traffic (although the 7609 to Customer link is down) that would fool the Primary ASA to stay active and this way cut all connections for the customer until a manual "failover active" is issued on the Secondary ASA?
Or would the Primary ASA perhaps notice that its Primary Customer link is down when it does the ARP test. As with that test it would not be able to connect to/get reply from the SVI on the customer stack along the primary link as the 7609 to Customer fiber link is down.
For reference heres the sections directly from the ASA documentation that I have read
When a unit does not receive hello messages on a monitored interface for half of the configured hold
time, it runs the following tests:
1. Link Up/Down test—A test of the interface status. If the Link Up/Down test indicates that the
interface is operational, then the ASA performs network tests. The purpose of these tests is to
generate network traffic to determine which (if either) unit has failed. At the start of each test, each
unit clears its received packet count for its interfaces. At the conclusion of each test, each unit looks
to see if it has received any traffic. If it has, the interface is considered operational. If one unit
receives traffic for a test and the other unit does not, the unit that received no traffic is considered
failed. If neither unit has received traffic, then the next test is used.
2. Network Activity test—A received network activity test. The unit counts all received packets for up
to 5 seconds. If any packets are received at any time during this interval, the interface is considered
operational and testing stops. If no traffic is received, the ARP test begins.
3. ARP test—A reading of the unit ARP cache for the 2 most recently acquired entries. One at a time,
the unit sends ARP requests to these machines, attempting to stimulate network traffic. After each
request, the unit counts all received traffic for up to 5 seconds. If traffic is received, the interface is
considered operational. If no traffic is received, an ARP request is sent to the next machine. If at the
end of the list no traffic has been received, the ping test begins.
4. Broadcast Ping test—A ping test that consists of sending out a broadcast ping request. The unit then
counts all received packets for up to 5 seconds. If any packets are received at any time during this
interval, the interface is considered operational and testing stops.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :