transparent DNS load-balancing with a Cisco ACE

John Miller johnmill at brandeis.edu
Fri Oct 19 20:04:28 UTC 2012


> IMO, the only boxes which should have IPs in both public and private netblocks should be your firewall/NAT routing boxes.

That's how we usually have our servers set up--the load balancer gets 
the public IPs, the servers get the private IPs, and we use NAT to 
translate between the two.

>> Here's a question, however: how does one get probes working for a transparent LB setup?  If an rserver listens for connections on all interfaces, then probes work fine, but return traffic from the uses the machine's default IP (not the VIP that was originally queried) for the source address of the return traffic.
>
> That's the default routing behavior for most platforms.  Some of them might support some form of policy-based routing via ipfw fwd / route-to or similar with other firewall mechanisms which would let the probes get returned from some other source address if you want them to do so.

Good to know--you'd definitely expect traffic to come back on the main 
interface.  I've considered setting up some iptables rules to make this 
happen, but if I can avoid it, so much the better.  Sounds like this is 
what I need to do, however, if I want both probes and regular requests 
to work.

>> What have people done to get probes working with transparent LB?  Are any of you using NAT to handle your dns traffic?  Not tying up NAT tables seems like the way to go, but lack of probes is a deal-breaker on this end.
>
> The locals around here have the luxury of a /8 netblock, so they can setup the reals behind a LB using publicly routable IPs and never need to NAT upon DNS traffic.  Folks with more limited # of routable IPs might well use LB to reals on an unrouteable private network range behind NAT, but in which case they wouldn't configure those boxes with public IPs.

We're on a /16, so we have plenty of public IPs (though not as many as 
you!) to play with, too.  The choice to NAT has historically been more 
about security than anything else--if something is privately IPed, we've 
got it on a special VLAN as well.

Presumably those reals are still behind a virtual ip address that's also 
public, right?  If that's the case, how do you keep your probes (to the 
IP behind the LB) working, while still sending back regular DNS traffic 
(that was originally sent to the virtual IP) with the VIP as a source 
address?  Seems like you get only one or the other unless you tweak 
iptables/ipfw/etc.

I appreciate the help, Chuck!  Would you mind PMing me or posting your 
configs?  That might be the most useful.

John

-----
Configs:

eth0      Link encap:Ethernet  HWaddr DE:AD:CA:FE:BE:EF
           inet addr:129.64.x.11  Bcast:129.64.x.255  Mask:255.255.255.0

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING NOARP  MTU:16436  Metric:1

lo:1      Link encap:Local Loopback
           inet addr:129.64.x.53 (VIP)  Mask:255.255.255.255
           UP LOOPBACK RUNNING NOARP  MTU:16436  Metric:1

Here's my ACE config (IP addrs deliberately munged):

access-list anyone line 10 extended permit ip any any

probe dns brandeis.edu-dns
   description Query dns servers for brandeis.edu/A
   interval 5
   passdetect interval 10
   domain brandeis.edu
   expect address 129.64.99.138

rserver host dns1
   description dev-level recursive DNS server; running BIND9 in the 
xen-ha-environment.
   ip address 129.64.x.11
   inservice
rserver host dns2
   description dev-level recursive DNS server; running PowerDNS in the 
xen-ha-environment.
   ip address 129.64.x.12
   inservice
rserver host dns3
   description dev-level recursive DNS server; running BIND9 in the 
XenServer environment.
   ip address 129.64.x.13
   inservice
rserver host dns4
   description dev-level recursive DNS server; running PowerDNS in the 
XenServer environment.
   ip address 129.64.x.14
   inservice

serverfarm host dns-recursive
   description Dev-level recursive DNS servers--both BIND and PowerDNS
   transparent
   probe brandeis.edu-dns
   rserver dns1
     inservice
   rserver dns2
     inservice
   rserver dns3
     inservice
   rserver dns4
     inservice

class-map match-all VIP
   2 match virtual-address 129.64.x.53 udp eq domain

policy-map type loadbalance first-match L7SLBPOLICY
   class class-default
     serverfarm dns-recursive

policy-map multi-match L4SLBPOLICY
   class VIP
     loadbalance vip inservice
     loadbalance policy L7SLBPOLICY
     loadbalance vip icmp-reply active

interface vlan 100
   ip address 129.64.x.100 255.255.255.0
   peer ip address 129.64.x.101 255.255.255.0
   no normalization
   access-group input anyone
   service-policy input L4SLBPOLICY
   no shutdown

ip route 0.0.0.0 0.0.0.0 129.64.x.1



More information about the bind-users mailing list