On Thu, Feb 3, 2011 at 1:53 PM, River Tarnell r.tarnell@ieee.org wrote:
In article AANLkTikpg8sDNmGWKN2xMW2AGqok1gdYUiOPF7QbMrKm@mail.gmail.com, Brion Vibber brion@pobox.com wrote:
There's no reason to NAT between the squid proxies and apaches -- they
share
a private network, with a private IPv4 address space which is nowhere near being exhausted.
I almost said this, but we do have Squids in esams, which has only a /24; and from what I've heard, probably won't be getting any more space, ever. So depending on how many Squids are added in the future, communication between esams and sdtpa could be fun.
(The obvious fix there is to use IPv6 for that...)
IIRC the Amsterdam proxies connect to the Tampa proxies on the internet, not directly to the back-end Tampa Apaches on the internal network.
Something NAT-ish actually shouldn't hurt here, since the Amsterdam proxy addresses are whitelisted and thus skipped over for IP tracking -- we'd still have the original requestor's native IPv4 or IPv6 address in the X-Forwarded-For, and it won't matter if we see a particular proxy's IP or the proxy cluster's NAT IP on the other end.
I'm not sure offhand how the cache-clearing signals are working these days, so not sure if that'd be affected (notifications from MediaWiki that particular pages have been updated and their URLs must be purged from cache need to be delivered to all our front-end proxies; this at least used to be done with local-network multicast and a proxy that rebroadcasted the multicast over in Amsterdam; if it still works like that then I don't think it'll be too affected).
-- brion