<p dir="ltr"><br>
On 3 May 2016 1:41 PM, "Tony Wicks" <<a href="mailto:tony@wicks.co.nz">tony@wicks.co.nz</a>> wrote:<br>
><br>
> Load balancing, health checking, security inspection, and extreme ease in adding/removing servers as desired with little effort. See there is a point.<br>
><br>
> </p>
<p dir="ltr">Other than security inspection, got all the rest with a BGP anycast setup, and it took no more than a few hours to develop and build the load balancing/fail over capability. Didn't care what was in customers DNS server lookups, so didn't need "security".</p>
<p dir="ltr">Used our BGP customer communities to weight the announcements of the pair of anycast addresses announced by each DNS server via Quagga, assigned and advertised them from a dummy interface, with a health check script that downed the dummy interface withdrawing the BGP announcements when health failed. Each server itself had a separate unicast IP address so you can login to fix it. Removing server was as as easy as 'ip link set dummy0 down'.</p>
<p dir="ltr">Scale up by scaling out, putting pairs of servers closer to a smaller set of users with the same pair of anycast addresses.</p>
<p dir="ltr">We wouldn't have got the "perfect" load balancing the a LB may have given us, however going by the cacti query graphs we were running, we'd have to have put effort into measuring it to find out how good it was or wasn't. IOW, it was quite good enough.</p>
<p dir="ltr">The only thing we got burnt on was at the time Centos had *two* places to change the Linux connection table tracking capacity, and we only knew of one of them. After getting caught with that, we just bypassed connection tracking completely for all port 53 packets in and out - we didn't need or want stateful firewalling for that traffic.</p>
<p dir="ltr">I'm happy to buy of the shelf vendor kit when they can do it cheaper and/or better than me, but have a think about how hard the problem really is, what you really need and what you might be able to compromise a bit on, and you may have more funds for the Christmas party.</p>
<p dir="ltr">I don't know what LBs cost at the time, probably at least $2k each, and we'd have needed two. Our solution probably cost no more than $400 in staff time, achieving the same result.</p>
<p dir="ltr">><br>
> From: Bill Woodcock [mailto:<a href="mailto:woody@pch.net">woody@pch.net</a>] <br>
> Sent: Tuesday, 3 May 2016 3:38 PM<br>
> To: Tony Wicks <<a href="mailto:tony@wicks.co.nz">tony@wicks.co.nz</a>><br>
><br>
> Cc: <a href="mailto:paul%2Bausnog@oxygennetworks.com.au">paul+ausnog@oxygennetworks.com.au</a>; <a href="mailto:ausnog@lists.ausnog.net">ausnog@lists.ausnog.net</a><br>
> Subject: Re: [AusNOG] ISP DNS Options<br>
><br>
> <br>
><br>
> Ugh. I always say, when you can replace a middlebox with a patch-cord, always do so. What advantage is the middlebox supposed to confer here, versus not having one?<br>
> <br>
><br>
> -Bill<br>
><br>
> <br>
><br>
><br>
> _______________________________________________<br>
> AusNOG mailing list<br>
> <a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
> <a href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
><br>
</p>