topic I don't suggest that you in Application Networking

VIP to VIP Communication behind same ACE

cmills — Mon, 28 Sep 2015 20:55:28 GMT

Running into an issue I've never worked with before. Consider this scenario:

Serverfarm1 and Serverfarm2 (physical servers) live on the same ACE behind this network:

192.168.1.0/24

Serverfarm1 and Serverfarm2's Load Balanced Addresses live behind this network:

192.168.2.0/24. Let's say they have 192.168.2.10 (serverfarm1) and 192.168.2.11 (serverfarm2)

The physicals on serverfarm1 (192.168.1.0/24) need to send traffic to the VIP of serverfarm2.

Right now this isn't working and I'm not sure why. I am making the assumption that the servers on Serverfarm1 are configured correctly with the alias ip for the ACE VLAN Interface of their subnet. Doing a sh connec <serverfarm> doesn't yield any information to indicate the connections are establishing.

Being the ACE's are basically security devices my thought was this isn't going to be allowed but I can't see why. We've run into things related to the security features before.

Going to set up some sniffer captures to see where/if it is hitting the wire. So that's the question - is this something the ACE will not allow? The traffic is syslog (udp/514) so not TCP connection to be established.

Hi, If the two VIPs

ciscocsoc — Tue, 29 Sep 2015 14:52:32 GMT

Hi,

If the two VIPs serverfarms are in the same context then you will need to source-NAT traffic from the rservers to an address in the serverside VLAN. If you don't do this then the traffic becomes asymmetric and is dropped by the ACE (unless you disable some of the security features).

The extract below allows the rservers to communicate with another VIP in a context:

class-map match-any REAL-SERVERS
2 match source-address 10.10.10.181 255.255.255.255
3 match source-address 10.10.10.182 255.255.255.255
4 match source-address 10.10.10.183 255.255.255.255
5 match source-address 10.10.10.184 255.255.255.255
6 match source-address 10.10.10.186 255.255.255.255
7 match source-address 10.10.10.187 255.255.255.255
8 match source-address 10.10.10.188 255.255.255.255

policy-map multi-match L4POLICY

...
class REAL-SERVERS
nat dynamic 1 vlan 382

interface vlan 382
description ACE-Web1-Serverside
ip address 10.10.10.178 255.255.255.240
alias 10.10.10.177 255.255.255.240
peer ip address 10.10.10.179 255.255.255.240
access-group input PERMIT-ALL
access-group output PERMIT-ALL
nat-pool 1 10.10.10.190 10.10.10.190 netmask 255.255.255.240 pat
no shutdown

HTH

Cathy

Yep...I did some further

cmills — Tue, 29 Sep 2015 19:10:05 GMT

Yep...I did some further research last night and that's what kept being the recurring theme.

We already disabled normalization. What security features can be disabled to facilitate this?

They are in the same context, but a different VIP.

I don't suggest that you

Peter Koltl — Fri, 02 Oct 2015 06:12:11 GMT

I don't suggest that you tweak the ACE to accept asymmetric traffic. If reply packets avoid the ACE, it is not capable of any advanced L7 function. In addition, real servers send replies with their real src IP addresses while the initiating servers expect the reply packets with the VIP address. So the connections cannot be established.

Set up source NAT, I would prefer static 1-to-1 NAT to identify which server the traffic comes from.