07-14-2011 01:06 PM
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!
Solved! Go to Solution.
07-15-2011 09:24 AM
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
07-14-2011 01:27 PM
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
07-14-2011 09:26 PM
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
07-15-2011 06:32 AM
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...
07-15-2011 09:02 AM
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
07-15-2011 09:24 AM
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
07-15-2011 09:30 AM
yes, confirmed to be working with the example provided.
Thanks for your assistance!
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