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.
Hi Guys,I'm trying to figure out how to redirect specific BD to a specific l3out. Let's try to be more clear through an exemple :I have 2 L3out :- L3out_core (where the default route is currently pointing to) - L3out_firewall All traffic is...
Managing a 10.4.2 DCNM server with radius/tacac user authentication enabled, so no local accounts. I have a user whenever he logs in his profile seems corrupt, GUI interface shows garbled text and topology is not functioning correctly. All oth...
I am trying to accommodate a vendor who needs to regularly see the cam table for a leaf. I don't want to give them direct access into the leaf. Is there an API call that can return the mac-address to port combination?