First of all, it is more important to understand why nat is needed in ACE environment. Asymetric routing is often not accepted by loadbalancers. Therefore, you will need to check the reverse path making sure the server will respond to the client THROUGH the ACE.
Here is common topology you should use the nat on ACE.
client----- internet ---- router1 --- vlan10 -- ACE --- vlan 20 --- router2 --- serverfarm -- server1
| |
eth1 eth2
|_______________________________|
Let's say
client ip : 64.1.1.1
server1 : 40.1.1.1
vip address on vlan 10 of ACE : 10.1.1.10
int vlan 10 of ACE is : 10.1.1.1
int vlan 20 of ACE is : 20.1.1.1
int eth1 of router1 : 30.1.1.1
int eth2 of router2 : 30.1.1.2
1. client sends tcp request to the vip address. So the first packet will be tcp syn and its address should be source with client ip : 64.1.1.1 and dest with vip address on vlan 10 of ACE : 10.1.1.10.
2. If there is no routing issue, this request should get to the ACE and the ACE will go through classification to see if the request hits the vip or not.
3. If the request hits the vip, then the ACE will make forwarding decision to the serverfarm. When this happens, the ACE will be doing destination natting. i.e. the ACE will only replace the dest ip from vip to server1. So the address should be like source with client ip : 64.1.1.1 and dest with server1 : 40.1.1.1.
4. When the server receives this request, the server1 will respond to the client 64.1.1.1. So the reponse packet should be syn/ack and its address should be source with server1 : 40.1.1.1 and dest with client ip : 64.1.1.1.
5. This response will get to the router2 and if the router thinks shortest path to the client1 is via eth2, then the response will bypass the ACE.
6. This is the problem I said earlier as asymmetric routing.
7. The client sends the request with client ip : 64.1.1.1 and dest with vip address on vlan 10 of ACE : 10.1.1.10 but the response with source with server1 : 40.1.1.1 and dest with client ip : 64.1.1.1.
8. The client will reset the connection.
So let's apply dynamic natting to the ACE to avoid this sort of failure.
access-group input any
class-map match-all CUSOMERC-VIP
2 match virtual-address 10.1.1.10 tcp eq www
policy-map multi-match VIPs
class CUSOMERC-VIP
loadbalance vip inservice
loadbalance policy CUSOMERC-POLICY-L7
loadbalance vip icmp-reply active
nat dynamic 20 vlan 20
interface vlan 10
ip address 10.1.1.1 255.255.255.0
service-policy input VIPs <<<<-----
access-group input any
interface vlan 20
ip address 20.1.1.1 255.255.255.0
access-group input any
nat-pool 20 20.1.1.30 20.1.1.30 netmask 255.255.252.0 pat <<<-----
Now two things to remember.
+ We apply the service policy to the incoming interface which is int vlan 10 in this case.
+ We need to change the client source ip to the natted ip as per the nat-pool. This should be applied to the outgoing interface vlan 20.
So thus a sequence to process the dynamic natting for the request should be
service-policy input VIPs --> policy-map multi-match VIPs ---> class CUSOMERC-VIP ----> loadbalance policy CUSOMERC-POLICY-L7 ---> nat dynamic 20 vlan 20
Step1. request comes to int vlan 10. Then it will check "service-policy input VIPs".
Step2. since the service policy applied to the int vlan 10, it will check "policy-map multi-match VIPs".
Step3. "policy-map multi-match VIPs" comtains only one class-map which is "class CUSOMERC-VIP" and the ACE will check if the request hits the vip defined on the class-map.
Step4. Once it verifies if this is good request, then the ACE will find associated "policy-map type". The policy-map type basically perform "forwarding deciscion" which is load balaincing to the serverfarm.
Step5. However, we has defined one more condition to perform "natting" with " nat dynamic 20 vlan 20".
Step6. when the ACE performs the natting, it will change the client source ip to the natted ip with nat-pool 20 which applied on int vlan 20.
I hope this clarifies your question.
-Andrew
