Ian Young wrote:
> Roberts A.L. wrote:
>> loop which strangely resulted in
>> only some of the metadata servers' IPs being unreachable.
> The various metadata servers are in colos spread around the UK for
> resilience. So I'm not very surprised that a route to one of them might
> get lost while the route to another might be untouched.
There's another possible cause of this kind of thing that came to light
during discussions with another federation member today. I thought it
might be useful to post a description here in case anyone else is
debugging a similar solution in the future.
We recently added an IPv6 AAAA record for one of the metadata
distribution (and WAYF) machines. That shouldn't affect sites with
working IPv6 connectivity, and it shouldn't affect sites with no IPv6
connectivity... but if you have IPv6 that isn't working, this might be
one of the only things that will break. The symptom in this case is
that although some (non-IPv6-aware) applications like wget can fetch
metadata with no problems, IPv6 aware applications (lynx, curl, the
Shibboleth SP) might see a delay of a few minutes while the IPv6
connection times out before the application backs off and tries one of
the IPv4 addresses...