cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
975
Views
0
Helpful
7
Replies

Configuring ACE Module for Redundancy

limtohsoon
Level 1
Level 1

Hi Sir,

I'm configuring fault tolerance between two ACE modules installed on two different Catalyst 6513 switches. I have one Admin context and 3 user contexts.

Do I need to configure 4 "ft group", i.e. one context per group? E.g. config:

ft group 1

peer 1

priority 110

peer priority 105

associate-context Admin

inservice

!

ft group 2

peer 1

priority 110

peer priority 105

associate-context ace-context1

inservice

!

ft group 3

peer 1

priority 105

peer priority 110

associate-context ace-context2

inservice

!

ft group 4

peer 1

priority 105

peer priority 110

associate-context ace-context3

inservice

!

Can you also explain the purpose of configuring an alias IP address on the client-facing VLAN interface? I understand we need an alias IP address on the server-facing VLAN interface to provide a virtual gateway address to the servers. But what's the use of an alias IP on the client-side?

Thank you.

B.Rgds,

Lim TS

7 Replies 7

Hi,

You need to configure a ft group for every context.

We have not configured the Admin context as fault tolerant, i think it is possible.

The alias on the client side is necessary if you want to use that as gateway too.

regards,

Sebastian

Sebastian is right you need an ft group for every "User-Context".

I am actually not sure if it is possible to run the admin context itself in FT mode. On the two ACE setups i configured so far, i haven't been able to get the admin context into ft mode. I also haven't read anything useful regarding FT and the admin context.

So my guess is... it is not best practices to put the admin context into FT mode unless someone proves me wrong or i fundamentally misunderstood the whole ACE FT concept.

Roble

Roble,

the recommendation is to use FT for the admin context as well.

Forgetting some important commands in admin context could create problems - ie: if you forget about resource allocation on the backup.

That's why it is recommended to have FT between admin contexts as well.

Gilles.

I see the point Gilles but how do you get the config on the second blade initially?

If you take a pix,asa or fwsm e.g. you define the secondary attributes in the config of the active device. Once you configure the failover on such device the standby devices gets automagically configured.

Somehow that approach never worked out for me when configuring the primary ACE. The ACE Docs i have here locally (pdf) are first hour papers. If there has been a revision explaining this better i am happy to read all the stuff i can get. As i am a big fan of the RTFM approach a link with text that enlightens the reader would also help. :)

Thanks for the info though.

Roble

Roble,

basically you have to use the 'peer' keyword to configure the standby device from the active.

All you need on the standby is a valid ft config.

Then config sync will do the rest.

Not sure about new version of manual.

All I can suggest is check the version on our website.

Gilles.

Hi Gilles,

I have configured FT for all user contexts as well as for the admin context. It works. My FT config is identical to the one I posted in this thread. Of course, one has to define the "ft interface vlan" and "ft peer" before configuring FT groups.

I noticed a few things:

(1) After the initial FT config, subsequent FT groups just need to be configured on the active Admin context and it will be replicated to the standby ACE, with the priority correctly reversed.

(2) You will get the message "NOTE: Configuration mode has been disabled on all sessions" when you log in to a standby context.

(3) The hostname of the active Admin context is not synced to the standby ACE. Do you know why?

One issue I encountered in one of the user contexts is as follows:

ace1/ace-context-1# sh run int

Generating configuration....

interface vlan 950

description *** Client-Facing VLAN ***

ip address 10.1.35.5 255.255.255.0

alias 10.1.35.4 255.255.255.0

peer ip address 10.1.35.6 255.255.255.0

access-group input ACL_VL950_IN

service-policy input REMOTE_MGMT

service-policy input MY_LB

no shutdown

interface vlan 951

description *** Connection to Real Servers ***

ip address 10.1.36.2 255.255.255.0

alias 10.1.36.1 255.255.255.0

peer ip address 10.1.36.3 255.255.255.0

access-group input ACL_VL951_IN

service-policy input NAT_REAL

no shutdown

This is the active context. It can ping to 10.1.35.4 (alias) and 10.1.35.6 (peer) over VLAN 950 (client-side). It can ping alias 10.1.36.1 over VLAN 951 (server-side) but can't ping to peer 10.1.36.3. The ACL_VL951_IN permits ip any any. Do you know why?

Secondly, I can remotely ping to alias 10.1.35.4 but can't telnet to it (I'm expecting it to telnet to the active context). I have to telnet to 10.1.35.5. Is this normal behavior?

Please advise.

Thank you.

B.Rgds,

Lim TS

You can't ping an interface A when going through an interface B.

So, if your client is on interface B, you can ping all ip addresses interface B but can't ping any ip of interface A.

Under some conditions you would be able to ping the peer ip address.

Telnet to alias address is not allowed.

Gilles.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: