Hello Syed,

Thank you very much for the quick response! I looked at your sample configuration and it took me some time to understand it, probably because I used ANM to configure the ACE module and contexts, so I am not completely familiar with the CLI. I had to read parts of the documentation and I think I finally understand half of your explanation.

I understand the part where you say: "You will also need to have a multi-match policy listening on VIP address on the vlan where traffic from Rservers is expected". I know that I don't have that right now, and that I will need to add this.

But I still don't understand why I have to SRC NAT traffic from the RServers to the VIPs.

The Catalyst 6500 with the ACE module is not at the periphery of our network, it's in front of our server room. With our network team, we decided not to NAT internal traffic from our server room. Real servers use 10.x.y.z addressing, and the VServers use external (routable) addresses. Being a university, we are lucky enough to have a class B network, let's call it A.B.0.0/16. Our SMTP server has VIP address A.B.6.34 (external routable address) and it's load-balanced to real servers with IP addresses 10.32.33.9 and 10.32.33.10. Other VLANs routed by the ACE module in the same or other contexts have similar arrangements (10.x.y.z addressing for real servers, A.B.c.d for VIPs).

(in my first post, I used an example with "10.32.33.2" as the VIP of our SMTP server; that's a test I tried of a VIP on the same subnet as the rservers, but it didn't work. The VIP that is used normally is A.B.6.34)

Inter-server traffic will be of two kinds: some will have to go directly to a specific server (because we have only one; it's the case with certain database servers). For the cases where we have more than one server for the same service and we configure load balancing with a serverfarm and a VIP, inter-server traffic should use the VIP to reach the real servers.

With this arrangement, it would be much simpler if we could just leave the addresses as they are (10.x.y.z). "Much simpler" here relates to DNS entries and local firewall rules (iptables on Linux boxes) that are easier to maintain if all addresses remain intact. If an outgoing connection from a real server ever has to reach the Internet, it's policy-NATted on a separate ASA 5540 that we have at the periphery of our network.

I don't know if I included enough information for you to understand the reasons why I would prefer not to use NAT at all on the ACE module... but as a conclusion I will ask the following question: if I add a multi-match policy listening on the VIP addresses on the vlan where traffic from the Rservers is expected, can I get away without SRC NATTing the outgoing RServer traffic and still reach the VIPs from RServers within the same context?

Thank you very much,

Marc.

You only need to translate "REAL to VIP" traffic, whichyou can easily filter using ACLs on ACE.

I will try to explain why we need to translate for Real-->VIP traffic.

Lets assume that VIP for app1 is 200.200.200.200

and the servers for app1 are

REAL1(IP: 10.10.10.1 & MAC: aa-aa-aa-aa-aa-aa) & REAL2(IP: 10.10.10.2 & MAC: bb-bb-bb-bb-bb-bb).

Now lets assume that REAL1 initiates traffic for the VIP, the packet will look like

Srcip:10.10.10.1 Dstip:200.200.200.200

The ACE will rcv the packet as its listening for VIP 200.200.200.200. ACE will then select the REAL server using the LB algo.Lets assume ACE selects REAL2 for this request.

ACE will change the request packet as follows

Srcip:10.10.10.1 Dstip:10.10.10.2

Now the REAL2 sees that this request came from REAL1 (10.10.10.1) and since 10.10.10.1 belongs to its local network, instead of sending the reply back to ACE it will send the response directly to REAL1 (using its ARP table).

Since REAL1 sent a request to 200.200.200.200, it is expecting a response from the same IP (VIP).

When it rcvs a response from REAL2(10.10.10.2) it will discard it.As it is not expecting any response from REAL2 (there is no connection entry for such reply).

In order to make sure that servers get responses back from the same ip where they sent the initial request its absoulutely needed to translate the src ip.

HTH

Syed Iftekhar Ahmed

Hello again Syed,

Thank you very much for your explanations, they were very clear. And it made me realize that the problem is not present in the whole context, but just on the same VLAN.

In fact, I can now use a VServer from real servers located in another VLAN of the same context, which I couldn't do before. In ANM, I only had to include the other VLAN in the list of VLANS associated with the virtual server - except that I was disappointed with the fact that in ANM, we can't add a new VLAN to an existing VServer; if I do, I get the message: "Virtual server Vlan set cannot be changed", so I had to delete the VServer and recreate it with the additional VLANS, which means that there's an interruption of service. Bummer! ;-(

I will now experiment with NATting outgoing connections from real servers to VServers that are load-balanced to real servers in the same VLAN as the requesting rserver.

Thanks again!

Marc.

Hello Syed,

I've been busy on other things but I finally had the time to test source-natting traffic from the real servers to a VIP in the same VLAN. I can't say that the solution is simple and elegant, but it works great!

Thanks again for taking the time to respond to my questions, it was extremely useful!

By the way, how can I mark this thread with the red check-mark that means "includes response(s) that solved Author's issue"? I checked everywhere and couldn't find anything else than the score (1 to 5) that we can assign to individual messages in the thread.

Thanks again,

Marc.

I am glad it worked for you.

Though I do get these "red check marks" regularly.I really don't know how to assign these to a post :)

Thanks

Syed Iftekhar Ahmed