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/msg6.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 1001
64.50.236.520100 00110010
security:
128.31.0.36 1000 0001
212.211.132.32 11010100 11010011
212.211.132.250 11010100 11010011
Those compare with the private ranges:
10.0.0.0/32 1010 ...
172.16.0.0/12 10101100 0001...
192.168.0.0/16 1100 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
signature.asc
Description: Digital signature
