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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
