On Sun, Dec 02, 2007 at 11:11:43PM -0800, Steve Langasek wrote: > In what way are the reports that this has adversely affected Debian mirrors > unsatisfactory? Have there been any reports? I've only seen Josip's second hand comments: ] I'm told that this bug also broke round-robin DNS functionality for ] ftp.us.debian.org/http.us.debian.org. -- http://lists.debian.org/debian-ctte/2007/09/msg00006.html ] I've noticed that security.debian.org, which is composed of three hosts, ] appears to be resolved by apts so that only one of them, steffani, gets ] picked. I can't substantiate this with exact log evidence yet (there's an ] outstanding RT ticket for that), but the system load on that machine is ] consistently high and network speed low, whereas the other two machines ] are practically idling in comparison. ] ] I've also previously noticed that ftp.us.debian.org traffic seems to ] concentrate too much on one host, too, ike.egr.msu.edu, but I've got even ] less evidence there (that and other machines aren't under our control). -- http://lists.debian.org/debian-ctte/2007/11/msg00031.html "I'm told", "I can't substantiate this", and "I've got even less evidence there"... But hey, you can always do an on-paper analysis even without actual data. The names resolve to: http.us/ftp.us: 34.9.37.225 00100010 00001001 64.50.236.52 01000000 00110010 security: 128.31.0.36 10000000 00011111 212.211.132.32 11010100 11010011 212.211.132.250 11010100 11010011 Those compare with the private ranges: 10.0.0.0/32 00001010 ... 172.16.0.0/12 10101100 0001... 192.168.0.0/16 11000000 10101000 The rule9/rule10 ordering means that we take the longest common prefix, then do round-robin. For http.us that would lead to: RR for addresses above 128.0.0.0 (including 192.168/172.16) 100%/0% split for 10.0.0 addresses 100%/0% split for addresses below 64.0.0.0 0%/100% split for addresses above 64.0.0.0 but below 128.0.0.0 For security it gives: RR for addresses below 128.0.0.0 RR for 10.0.0.0 addresses 100%/0%/0% split for addresses below 192.0.0.0 but above 128.0.0.0 100%/0%/0% split for 172.16.. 0%/50%/50% RR split for addresses above 192.0.0.0 0%/50%/50% RR split for 192.168/16 So http.us would be biassed by 10.0.0.0 addresses, but everything else seems fairly balanced, and afaics 10.0.0.0 addresses alone, while, likely to be significant shouldn't be completely dominating. And security.d.o looks like it should be fairly well balanced, though the 212.211.. hosts are sharing each other's load more than 128.31's, so you'd expect a load distribution somewhere between 33%/33%/33% and 50%/25%/25%. Which leaves as conclusions: - there's no available evidence of a problem from Debian server logs - ftp.us, http.us and security.d.o all seem to still be functioning from a user's perspective - the understanding of the issue we've got so far implies that this would only cause fairly minor load balancing problems for the current Debian hosts Cheers, aj
Attachment:
signature.asc
Description: Digital signature