ACE20 - connections to VIP from behind LB rejected

[imanassypov]

Hi,

I have the following scenario:

- routed mode ace

- 2xDNS rservers behind VIP A

- 2xweb servers on same subnet as DNS above, behind VIP B

web server queries towards VIP A never hit the interface. For that matter, if I try to hit "VIP B:80" from any of the two web servers - I get an active reset packet.

Is this the expected behavior? Is there a way to make rservers talk to their own virtual ips?

Thanks!

[asharmav]

Hi ,

This is not possible, VIP is  a virutal ip address to face the external world and not for the internal servers to talk to . Why do you want the both servers to talk to each other ? If you have a common subnet they should be able to reach each other directly without needing to go to ACE.

What are you trying to achieve. ?

Regards

Abijith Sharma

Cicso PDI Team

www.cisco.com/go/pdihelpdesk

[pablo.nxh]

Hi there,

This is actually a perfectly feasible scenario and actually really common; for example when web servers need to reach database servers or in your case DNS servers, the VIP is not strictly tie to the external interface, the VIP can be wherever you wanted to be as long as your design permits it. The only change you need to take into account for this requirement is that you need NAT in order to avoid asymmetic routing as all the servers are in the same subnet.

Here is a config sample of how this is accomplished:

Your VIP is on VLAN 20 let's say while servers are sitting on VLAN 10:

class-map match-any WWW

  2 match virtual-address 20.20.20.10 tcp eq www

class-map match-any DNS

  2 match virtual-address 20.20.20.10 udp eq 53

You need to create a new class-map to match the servers that will be NAT'd; you may also want to permit the entire subnet.

class-map match-any Servers

  2 match source-address 10.10.10.11 255.255.255.255

  3 match source-address 10.10.10.12 255.255.255.255

  4 match source-address 10.10.10.13 255.255.255.255

  5 match source-address 10.10.10.14 255.255.255.255

LB is your policy used to LB in vlan 20:

policy-map multi-match LB

  class WWW

    loadbalance vip inservice

    loadbalance policy Web

    loadbalance vip icmp-reply active

  class DNS

    loadbalance vip inservice

    loadbalance policy Domain

    loadbalance vip icmp-reply active

Here you will create a new policy for NAT exclusively and match the class to NAT the servers:

policy-map multi-match NAT

  class Servers

    nat dynamic 9 vlan 10

Finally under your server VLAN apply both policies and configure the NAT pool as described using an available IP from VLAN 10.

interface vlan 10

  ip address 10.10.10.1 255.255.255.0

  access-group input any

  access-group output any

  nat-pool 9 10.10.10.20 10.10.10.20 netmask 255.255.255.0 pat

  service-policy input NAT

  service-policy input LB

  no shutdown

This should do the trick

HTH

__ __

Pablo

[imanassypov]

Hi Pablo,

Thank you very much for an extensive post.

I am looking through your config - it is very similar to what I have tried but yet different where are applying both the LB and the NAT policy on the server side interface.

My understanding was that application of the LB policy, and hence the VIP, determines the place where the arp entry is created for that VIP. In your scenario - when you apply the LB to 'server' interface vlan 10, are you not going to experience issues with clients trying to access that same VIP? I think it can lead to some instability, where if you server is the first one to initiate a connection in the egress direction, your next-hop router would cache the VIP's arp locally and the next arriving client request would get routed properly to the VIP. However, if the client is the first one to initiate a connection to VIP, the request may not be routed properly...

[imanassypov]

Okay,

I just labbed this setup, and I think I was correct in my assumptions. To get the traffic flowing reliably in both directions, the LB policy has to be applied to *both* server and client SVI's, something like:

interface vlan 10

  description *SERVER*

  ...

  nat-pool 9 10.10.10.20 10.10.10.20 netmask 255.255.255.0 pat

  service-policy input NAT

  service-policy input LB

interface vlan 20

  description *CLIENT*

  ...

  service-policy input LB

[pablo.nxh · Accepted solution]

Hi there,

Yup I think I forgot to mention that you don't need to remove the LB policy from the client VLAN... you just need to add it again but this time under the server VLAN.

Did you get it working with the example provided?

__ __

Pablo

[imanassypov]

yes, confirmed to be working with the example provided.

Thanks for your assistance!