ACE - NAT issue

[muhammadrameezkhan]

Dear Fellows,

I have the following working scenario:

1. I am using ACE Module for Server Load Balancing in 6500. I have configured it in Routed mode.
2. I have configured a VIP which works well from Client and Server Side. Whenever a Client sends traffic to VIP, its load balanced in Round Robin Fashion by ACE to two servers. Also, When servers sends traffice to VIP, it gets reply from the other Server.
3. When traffic is sent from Client side to VIP, it gets response with VIP as source Address
4. When traffic is sent from Server Side to VIP, it gets response with Real IP of Other Server

I need the following result:

1. From Server Side, Whenever a Server Pings to VIP, it should get the reply with Source Address of VIP.

Please find the Configuration Attached.

Please help me out at your earliest.

Thanks & Regards,

Rameez

[jbartoldus]

I would think that this could be accomplished by an ICMP class-map and such because normal ICMP traffic would be routed using the most specific match, which is the directly connected interface.

[vpurbiya]

For doing NAT, you would have to create a VIP, which will create the arp entry on the box.

Without matching the VIP, it wont be responding.

[jbartoldus]

I double-checked the config.

I think this is an issue because there are two service policies that each has a valid class-map that recognize ICMP packets and both those service policies are applied to the same interface.  I would think you could test by removing the icmp protocol line from the mgmt class-map and see what results you get.  I suspect that the ACE is processing the ICMP packet as part of the mgmt class-map first.

[muhammadrameezkhan]

Dear Jbartoldus,

I tried according to your suggestion but no luck.

Let me be more clear,  From the Server Side, if a Server sends traffic to VIP, it should get the response with VIP as source address.

Please let know if there are any other possible solutions.

Regards,

Rameez

[jbartoldus]

The only other thing I can think of would be to add the loadbalance vip icmp-reply active command to your L4_VIP_PE_CMAP class statement in your multi-match policy-map.

[rodrguti_2]

Hi Muhammad,

The problem is the NAT you are using, it is not good, that is why you are having an asymmetric flow. You have a layer 2 asymmetric flow, I will assume a couple of variables, so please correct me if I am wrong, but must likely this will solve the problem:

- The servers are using the ACE as default gateway, since you do not have a NAT applied and the external clients are working that means that there is no a L3 devices in between.

- The switches between the ACE and the backend servers have the L2 information of the servers, so without NAT that is the switches can see each other.

Now, back to the ACE, in order to correct this, I will assume that the rservers you have configured are the ones, that are opening connections to the VIP, so in this case, we need to NAT the traffic through the outgoing interface, in other words, the NATPOOL needs to be configured on the interface that the ACE will use to send the traffic to the servers, so the configuration should looks like this:

policy-map multi-match L4_LB_VIP_PMAP

  class L4_VIP_PE_CMAP

    loadbalance vip inservice

    loadbalance policy L7_VIP_PE_PMAP

    nat dynamic 1 vlan 130 -------------------------------------- > HERE

interface vlan 130

  description Server Side

  ip address 10.1.3.6 255.255.255.0

  alias 10.1.3.252 255.255.255.0

  peer ip address 10.1.3.5 255.255.255.0

  no normalization

  no icmp-guard

  access-group input PE

  access-group output PE

  service-policy input PE-SERVER-PMAP

  natpool 1 10.1.3.X 10.1.3.X netmask 255.255.255.0 pat --------------------------> here

  no shutdown

You need to replace X for an available IP on the server's range, now, you need to configure the Natpool first and then apply it to the class under the policy multi-match.

Let me know, it should works. Since you are not doing NAT, what happen is that the backend server knows the MAC address of the other Server that is opening the connection, so when it replies back, the destination MAC is the Server one, as soon as the packet hits the L2 switch, this will send the traffic throught the port when that MAC address was learned, and the packet will end to the Client Server which will drop the packet.

HTH.

Rodrigo.