11-11-2010 10:05 AM
Hi all
Our customer host web applications that are accessible via Public addresses that are NATted to VIPs that reside on a DMZ. Their previous topology was upgraded from 2 PIX firewalls & 2 x Alteon load -balancers to 2 ASAs (active/standby) and 2 ACE appliances last night.
The ACEs are configured with an Admin context each and only 1 shared context for the Web-services using Fault tolerance
I will post the relevant portions of the configurations below.
The ACEs are configured in routed mode. the "client-side" vlan of the ACEs resides on a DMZ of the firewall. This is Vlan 110 and the default gateway for the web-services context is the firewall DMZ interface. All VIPs are configured with addresses on the Vlan 110 subnet.
The "server side" Vlan (vlan 110) is the default-gateway for the real-servers.
The primary ACE service specific context
-------------------------------------------------------------
interface vlan 110
description Client VIP Vlan
ip address 10.0.110.1 255.255.255.0
peer ip address 10.0.110.2 255.255.255.0
access-group input EXTERNAL_WEB_SERVICES
service-policy input EXTERNAL_WEB_SERVICES_VIPS
service-policy input REMOTE_ACCESS_ACE_POLICY
no shutdown
interface vlan 101
description WEB Server Vlan
ip address 10.0.101.254 255.255.255.0
peer ip address 10.0.101.253 255.255.255.0
access-group input SERVER-VLAN
service-policy input REMOTE_ACCESS_SERVER_POLICY
no shutdown
The secondary ACE service specific context
-----------------------------------------------------------------
interface vlan 110
description Client VIP Vlan
ip address 10.0.110.2 255.255.255.0
peer ip address 10.0.110.1 255.255.255.0
access-group input EXTERNAL_WEB_SERVICES
service-policy input EXTERNAL_WEB_SERVICES_VIPS
service-policy input REMOTE_ACCESS_ACE_POLICY
no shutdown
interface vlan 101
description WEB Server Vlan
ip address 10.0.101.253 255.255.255.0
peer ip address 10.0.101.254 255.255.255.0
access-group input SERVER-VLAN
service-policy input REMOTE_ACCESS_SERVER_POLICY
no shutdown
All services are fairly straight forward - Layer-4 class-maps, SRC-IP persistence, leastconns loadbalancing algorithms
Following ARP caches being cleared on the ISP upstream routers all service worked fine on the Primary ACE.
When I powered down the the secondary ACE, all services stopped working
The fault tolerant group had failed over. The Sticky database & the active connections were transfered to the secondary ACE
Prior to the failover the Primary ACE ft status was ACTIVE & the secondary was Standby-HOT
following the powerdown of the primary ACE, the secondary ACE resumed ACTIVE status however i could not get any entry for the ARP cache for the primary client side address of 10.0.110.1 or the server default gateway of 10.0.101.254.
if i issued a show conn command for a new connection the output was
Public CRS IP ->to -> VIP SYNSEEN
rserver ->to-> Public SRC IP INIT
If i removed the peer addresses from the context and re-configured the secondary ACEs with the primary client side address of 10.0.110.1 and the server default gateway of 10.0.101.254 (with no peer IP commands) the new connections inbound from the firewall worked fine
I have configured FT groups using one-arm mode previously using the below Fault tolerant configuration on the modules & the appliances without any issue when they failed over
Primary ACE Admin context relevant configuration
--------------------------------------------------------------------------
resource-class ACE
limit-resource all minimum 0.20 maximum unlimited
boot system image:c4710ace-mz.A3_2_6.bin
shared-vlan-hostid 1
peer shared-vlan-hostid 2
interface gigabitEthernet 1/1
description Data Trunk
switchport trunk allowed vlan 101,110,112
no shutdown
interface gigabitEthernet 1/2
switchport access vlan 102
no shutdown
interface gigabitEthernet 1/3
shutdown
interface gigabitEthernet 1/4
shutdown
ft interface vlan 112
ip address 10.0.112.1 255.255.255.252
peer ip address 10.0.112.2 255.255.255.252
no shutdown
ft peer 1
heartbeat interval 500
heartbeat count 20
ft-interface vlan 112
context EXTERNAL_WEB_SERVICES
allocate-interface vlan 101
allocate-interface vlan 110
member ACE
ft group 1
peer 1
priority 110
peer priority 50
associate-context EXTERNAL_WEB_SERVICES
inservice
Secondary ACE Admin context relevant configuration
--------------------------------------------------------------------------
resource-class ACE
limit-resource all minimum 0.20 maximum unlimited
boot system image:c4710ace-mz.A3_2_6.bin
shared-vlan-hostid 2
peer shared-vlan-hostid 1
interface gigabitEthernet 1/1
description Data Trunk
switchport trunk allowed vlan 101,110,112
no shutdown
interface gigabitEthernet 1/2
switchport access vlan 102
no shutdown
interface gigabitEthernet 1/3
shutdown
interface gigabitEthernet 1/4
shutdown
ft interface vlan 112
ip address 10.0.112.2 255.255.255.252
peer ip address 10.0.112.1 255.255.255.252
no shutdown
ft peer 1
heartbeat interval 500
heartbeat count 20
ft-interface vlan 112
ip route 0.0.0.0 0.0.0.0 10.0.102.254
context EXTERNAL_WEB_SERVICES
allocate-interface vlan 101
allocate-interface vlan 110
member ACE
ft group 1
peer 1
priority 50
peer priority 110
associate-context EXTERNAL_WEB_SERVICES
inservice
I have seen various posts & read some of the guides regarding "alias'" & FT tracking. I'm not sure if I need an alias of 10.0.110.1 & two different addresses for my client side & also an alias of 10.0.101.254 on my server side - similarly to HSRP.
Or do i need FT tracking on my interfaces or do i need a combination of both?
many thanks
Stuart
11-11-2010 04:18 PM
Hi Stuart
Yes you need an alias, if you ae pointing to the ace as a default gateway for the severs you need to make sure that address is always owned by the active ace. so an alias on the server vlan is required.
You probably also need an alias on the client vlan because you probably have static route on firewall pointing to the ace client vlan as a next hop for access to the server vlan.
the alias will work like hsrp and when a switchover occurs the ace will do a gratuitous arp so on client vlan and server vlan configure an alias address and point servers to the server vlan alias as the gateway and static routes on firewall to the client vlan alias. under interface the command is
alias x.x.x.x y.y.y.y with y.y.y.y being the netmask.
11-25-2010 01:33 AM
HI Litrenta,
Many thanks! This resolved my issue.
Would you know why I did not require alias IP addresses when using one-arm mode and redundant Contexts?
Stuart
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide