Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
David Robb wrote:
On Wed, 9 Mar 2005, Nathan Ward wrote:
IMO, using cache's in fully transparent mode is a rather broken thing to do, unless you cache on your entire border..
Ever tried to architect a network to do that? :)
We tried. It's easier to deal with the occasional network that breaks.
Really? I imagine that there would be lots of breakage in this area, especially during failures (your's, or other's) or routing that lacks clue. When you are caching fully transparently, do the Foundry's only send the HTTP return packets to the caches if they are part of a cached session? That would limit some problems, but obviously not all, and wouldn't fix this one. How do you detect that there is a problem network? That relies on customers, right? Do they really call and complain enough? I know my Mother would just put any failures like that down to "The Internet is broken again". Why don't you cache semi-transparently? (IE, connections to web servers come from the external IP address of the proxy server). I'm not aware of any real life cases of that breaking things, and as far as I am aware, it's what most NZ providers do.. Feel free to prove me wrong here, of course. -- Nathan Ward
On Wed, 9 Mar 2005, Nathan Ward wrote:
Why don't you cache semi-transparently? (IE, connections to web servers come from the external IP address of the proxy server). I'm not aware of any real life cases of that breaking things, and as far as I am aware, it's what most NZ providers do.. Feel free to prove me wrong here, of course.
It breaks a few places that use the IP address to auth http sessions, apparently some sites don't believe these weird cookie thingies are ready for prime time. SETI(a)Home and some stupid remote mail thing use by a couple of academic sites around NZ break. There was also a "access to paid databases gateway" type thing at one of the universities that broke (although they said they had fixed it). There were a couple of others too, Windows update was one I think. -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.
Simon Lyall wrote:
On Wed, 9 Mar 2005, Nathan Ward wrote:
Why don't you cache semi-transparently? (IE, connections to web servers come from the external IP address of the proxy server). I'm not aware of any real life cases of that breaking things, and as far as I am aware, it's what most NZ providers do.. Feel free to prove me wrong here, of course.
It breaks a few places that use the IP address to auth http sessions, apparently some sites don't believe these weird cookie thingies are ready for prime time.
Hmm. This would be a problem if your requests for the same site were going to different proxy servers. I don't think that happens with Foundys, by default. If it does, it's easily 'fix'-able.
SETI(a)Home and some stupid remote mail thing use by a couple of academic sites around NZ break. There was also a "access to paid databases gateway" type thing at one of the universities that broke (although they said they had fixed it).
There were a couple of others too, Windows update was one I think.
Really? I've done semi-transparently proxying a number of times before, and had no issues with windows update.. My opinion would be that it is easier/better to keep a list of broken sites, rather than a list of broken networks. Customers would be more likely to call to get sites added to this list, and when 'broken' routing is 'fixed' you don't have to go and remove things from the list. -- Nathan Ward
Nathan Ward wrote:
Simon Lyall wrote:
It breaks a few places that use the IP address to auth http sessions, apparently some sites don't believe these weird cookie thingies are ready for prime time.
Hmm. This would be a problem if your requests for the same site were going to different proxy servers. I don't think that happens with Foundys, by default. If it does, it's easily 'fix'-able.
We had an issue at Maxnet that was a site which broke in this manner. Essentially they 'authenticated' the customer off the IP address of the proxy, which using WCCP was reasonably static unless a proxy failed. However, after the initial authentication, it then redirected them to an SSL site on 443/tcp, which obviously was not going through the transparent cache farm, and the customer was (correctly) not configured to use a cache. So the request suddenly came from the customer's IP address. Result: The site would refuse to allow them in. A stupid way of doing it, and we solved the problem by excluding the site from the cache. For the life of me, I can't remember what it was, but I recall the site was black and popular. I think it might have been some games thing.
There were a couple of others too, Windows update was one I think.
Really? I've done semi-transparently proxying a number of times before, and had no issues with windows update..
I've seen no issues with WU either with intercept caching. I _have_ however seen issues with the MSN Gaming Zone when the caches hold old download packages because the file name stays the same and for some stupid reason IIS servers don't always seem to respond properly to If-Modified-Since requests, so the caches happily serve stale data. We had other issues like Simon said earlier, with Universities and High Schools requiring access to certain database sites that did it based on IP address. Oh, and people that don't check the X-Forwarded-For: header and use it need to be shot. (Hi Hotmail!) aj (and if the formatting of this email looks dumb, I blame my webmail client.)
On Wed, 9 Mar 2005, Nathan Ward wrote: Ok, before I start into this reply I'd like to note that I sent you my initial reply offlist and stuck an [offlist] tag in the subject just so it was even more obvious. Sending your reply back to the mailing list is either due to clueless configuration of your mail client, or you're unaware of simple netiquette. However, since we're now forced to turn this into an onlist discussion...
We tried. It's easier to deal with the occasional network that breaks.
Really? I imagine that there would be lots of breakage in this area, especially during failures (your's, or other's) or routing that lacks clue.
I think there are something like 4 networks currently configured for bypassing. It's not that common, since most operators keep an eye on traffic flows on their international links, and would notice the additional load if (for example) different length prefixes were being advertised into the different routing domains.
When you are caching fully transparently, do the Foundry's only send the HTTP return packets to the caches if they are part of a cached session?
Yes.
How do you detect that there is a problem network? That relies on customers, right? Do they really call and complain enough? I know my Mother would just put any failures like that down to "The Internet is broken again".
As with a lot of non physical layer network faults, customers really are the best way to detect them.
Why don't you cache semi-transparently? (IE, connections to web servers come from the external IP address of the proxy server). I'm not aware of any real life cases of that breaking things, and as far as I am aware, it's what most NZ providers do.. Feel free to prove me wrong here, of course.
Oh, there are many many cases where semi transparent caching snaps stuff. Before the source address spoofing was enabled, the bypass list was hundreds of entries - sites that use access lists tied to customer static IPs, sites that expect connections redirected to a secure portal to come from the same origin address, sites that don't like a customer source IP changing as connections are load balanced across multiple caches... Also, the cache server IPs end up in blacklists, abuse tracking is harder (ever tried keeping copies of cache logs for a big network? They're vast) - and very few places look at the X-Forwarded-For header. Plus (yes, there's more!) the caches get DDoSd, as their IP becomes visible - when someone posts to a forum and the IP is logged, it becomes a target. I'd much rather have to filter out traffic destined for a cable modem customer than a cache server. --David
participants (4)
-
Alastair Johnson -
David Robb -
Nathan Ward -
Simon Lyall