03-04-2008 06:27 AM
Basically we have a running ACE context which works however we are using natting and we have some applications complaining that they can't see the source address of things. So I created a whole new context with the following config but I have the problem of when the client is on the server side network the traffic never makes it there.
ACE1/10.0.0.0_Network# sho run
Generating configuration....
access-list ALL line 8 extended permit ip any any
rserver host CE-565-1
ip address 10.0.2.83
inservice
serverfarm host Content_Engine_SF
rserver CE-565-1
inservice
class-map match-all Content_Engine_VIP
2 match virtual-address 10.0.18.101 any
class-map type management match-any Remote_Management
2 match protocol http any
3 match protocol icmp any
4 match protocol telnet any
5 match protocol ssh any
policy-map type management first-match rmt_mgt_policy
class Remote_Management
permit
policy-map type loadbalance first-match Content_Engine_VIP-l7slb
class class-default
serverfarm Content_Engine_SF
policy-map multi-match int18
class Content_Engine_VIP
loadbalance vip inservice
loadbalance policy Content_Engine_VIP-l7slb
loadbalance vip icmp-reply active
access-group input ALL
interface vlan 3
description Server_Side
ip address 10.0.3.240 255.255.254.0
mac-sticky enable
no shutdown
interface vlan 18
description Client Side Network
ip address 10.0.18.251 255.255.255.0
mac-sticky enable
service-policy input int18
no shutdown
ip route 0.0.0.0 0.0.0.0 10.0.18.1
if I telnet to the vip from my machine 172.16.6.222 it works fine. If I telnet from 10.0.18.30 it works fine. However when I telnet from a machine on the vlan 3 10.0.2.188 it does not work. I would have thought the mac-sticky option would work but it seems to be doing nothing. Any ideas with out using a NAT pool would be great so we can see the originating IP Address.
03-04-2008 09:11 AM
If you are initiating traffic from serverA to a vip that load balances to serverB in that same vlan you will have an asymmetric flow. ServerA is on the same vlan as serverB. Since both servers are in the same subnet, ServerB will ARP for serverA address and send the response directly to serverA. The traffic will never make it back to the ACE. There are a few things you can do:
1. Use NAT to ensure the return traffice makes it back to ACE.
2. Insert HTTP header with client IP address. This only works for HTTP traffic and your application must be able to recognize this header for logging.
3. Use Direct Server Return (DSR). This feature has been committed to ACE 2.0. This will require the servers to be L2 adjacent to the ACE module and you will need to configure the VIP address as a loopback address on the server. Here is CSM documentation that lists some of the limitations with DSR:
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