In Cisco ACE the redundancy feature provides seamless switchover in case an ACE becomes unresponsive or a critical host or interface fails. ACE has robust software and hardware that makes it possible to handle high volume of traffic at real time. Cisco ACE supports virtualized architecture to increase datacenter scalability. Two ACEs, properly configured, form a failover pair. Each appliance can contain one or more fault-tolerant (FT) groups. Each FT group consists of one active context and one standby context. Each FT group acts as an independent redundancy instance. When a switchover occurs, the active member in the FT group becomes the standby member and the original standby member becomes the active member. To achieve active-active redundancy, a minimum of two contexts and two FT groups are required on each ACE.
A failed ACE appliance is required to be replaced. The configuration should be preserved and the primary switchover need to happen.
Stateful Failover and Config sync
Cisco ACE replicates flows on the active FT group member to the standby group member per connection for each context. The replicated flows contain all the flow-state information necessary for the standby member to take over the flow if the active member becomes unresponsive. Note that ACE does not support the stateful failover of any connections that are proxied. Such connections include Layer 7 connections (including SSL), inspection, and HTTP compression.
Redundancy uses a dedicated FT VLAN between redundant ACEs to transmit flow-state information and the redundancy heartbeat. You must configure this same VLAN on both peer ACEs. You also must configure a different IP address within the same subnet on each ACE for the FT VLAN.
The ACE automatically replicates the active configuration on the standby member during config sync. This process automatically replicates any changes in the configuration from active to standby peer.
Follow these steps to swap the failed device and get it back in sync with the primary:
a) Complete all the physical network connectivity.
b) Disable config auto-sync in the primary ACE.
c) Configure the management Vlan for basic network connectivity.
d) Make sure the new device has the same code as the primary; if not you'll need to upgrade it.
e) Install the license (if used).
f) Copy all the SSL files stored in the primary APP. (If any)
g) Copy the scripted keepalives (If any)
h) Configure the FT interface Vlan, FT peer, FT group for the Admin context. (Be careful about the priority you assign).
i) Re-enable config auto-sync on the primary APP in order to replicate the config to the standby.
Hello, We are trying to get our contracts between EPGs to log the deny and permit traffic as seen within the Tenant > $tenant > Operational > Packets > L3 Permits/L3 Denys. According to the obscure documentation it seems that one of ...
Hello, Sorry for this long-winded post... I am more of a routing and switching kind of guy but stuck managing a small SAN with backend fiber. This is probably a simple task for an expert but its so far out of my area of expertise so I wanted to get s...
Hi All, Can anyone confirm me about the Cisco Nexus data center 10G switches as what is the main difference between both of them as i need to create vPC and for vPC both should be identical but i am little bit confused about the models or both are sa...
HI Guys, I am going to deploy multi-site EVPN fabric on cisco 9K switches but one of the requirements is to make sure that all communications between any subnets (VNIs) should be passing through firewall to achieve desired security posture.&nbs...
Hello. Hope you are all doing fine. Do you know how to change the ssh ciphers for the apic/leafs/spines connections to be stronger using ctr ciphers instead of cbt?I can´t acces the devices using ssh if I dont have an older Secure CRT version. I...