It's incredibly strange... After testing for the last 24 hours: One thing seems constant encrypted traffic passes without problem (at normal rates of speed). Unencrypted traffic has problems from various networks (even when I try HTTP on different ports). It also seems that it's independent of Windows/IIS. We spent 7.5 hours on the phone with Cisco Friday validating our switches, and our routers. No problems there. Cisco thought it was Code Blue, but my tests using Unix machines are indicating that may not be the case. I've setup a few files to test with (they are all the same ActiveState PERL file): http://www.ware.net:2329/perl.msi and http://www.ware.net/perl.msi and https://store.ware.net/perl.exe <--- This one works for everyone. and http://store.ware.net/perl.exe and http://209.67.152.157/perl.exe <--- Unix Any ideas? -----Original Message----- From: Bruce Pinsky [mailto:bep@whack.org] Sent: Friday, September 07, 2001 12:03 PM To: Nanog; nanog@merit.edu Subject: Re: web pages not loading (from certain networks) but not a routing i ssue. At 9/7/2001 07:52 AM -0700, Nanog wrote:

Ok guys,

Interesting problem that seems to have started on Friday.

Here's the deal, it seems that certain (not all) web pages on various sites we host are not loading for certain customers. It started on Friday with visitors on Verizon DSL waiting forever for pages to load.

Yesterday and today PacBell DSL and some Netcom customers started complaining.

This only seems to occur on HTTP traffic. If we have the visitors try HTTPS the pages load fine (with the normal encryption slowdown).

We've looked at Layers 1-4, and can't see any problems, ping looks great, interfaces and cpus on routers, servers and switches look fine.

It's almost like it's a transparent cache "bug". Anyone know if Inktomi, or any major cache vendors rolled out any new code this week?

For that matter does anyone know what caches Verizon and SBC use for starters?

Other variables: it only seems to occur on IIS based systems (I know I know, no flame wars or suggestions for replacements). Although it's not happening on all of our IIS servers.

Any clues are greatly appreciated.

Do they get any messages or just page hang? I'm thinking of TCP connection resets particularly. I've seen a problem before where there were two parallel paths, one with a cache and one without and during the loading of a webpage the path switches causing the enduser session to stop using the cache and attempt to hit the origin server. Since the origin server is not in session, it resets. ========== bep