Comments on: SSL Timeouts and layer 3 infrastructure http://markmaunder.com/2009/ssl-timeouts-and-layer-3-infrastructure/ Thu, 02 Sep 2010 02:33:49 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: SSL Network problem follow-up http://markmaunder.com/2009/ssl-timeouts-and-layer-3-infrastructure/comment-page-1/#comment-794 SSL Network problem follow-up Sat, 24 Oct 2009 18:23:35 +0000 http://markmaunder.com/?p=297#comment-794 [...] now exactly a week since I blogged about my SSL issues over our network. To summarize, when fetching documents on the web via HTTPS from my servers, the connection would [...] [...] now exactly a week since I blogged about my SSL issues over our network. To summarize, when fetching documents on the web via HTTPS from my servers, the connection would [...]

]]> By: Wansa http://markmaunder.com/2009/ssl-timeouts-and-layer-3-infrastructure/comment-page-1/#comment-783 Wansa Thu, 22 Oct 2009 01:39:06 +0000 http://markmaunder.com/?p=297#comment-783 I'am seeing a similar problem using the same network libraries/stack. In my case it is XML-RPC over SSL. I’am seeing a similar problem using the same network libraries/stack. In my case it is XML-RPC over SSL.

]]> By: mark http://markmaunder.com/2009/ssl-timeouts-and-layer-3-infrastructure/comment-page-1/#comment-763 mark Sat, 17 Oct 2009 17:44:41 +0000 http://markmaunder.com/?p=297#comment-763 There is no software or hardware that processes or filters above layer 3 between the machines and workstations I've tested and the open Internet. You can walk up to my switch, plug in, assign yourself a public address and be connected directly to the unfiltered internet. The only thing between you and the rest of the world is the default gateway that routes at layer 3, and the problem still exists. I've also used iperf to simulate client server connections in both directions on both port 443 and 80, and there is no throttling of TCP packets of any kind. My provider says they had a sniffer on the wire and while repro'ing the problem they would see duplicate packets arrive from upstream. I did the same thing and didn't see that, but sound like a clue. Last night we shut off one of the upstream providers (there are about 4 of them) and the problem went away. But I'm not convinced it's that upstream provider because I've seen the problem exist for routes through other providers. it's the strangest thing I've seen. :) There is no software or hardware that processes or filters above layer 3 between the machines and workstations I’ve tested and the open Internet. You can walk up to my switch, plug in, assign yourself a public address and be connected directly to the unfiltered internet. The only thing between you and the rest of the world is the default gateway that routes at layer 3, and the problem still exists.

I’ve also used iperf to simulate client server connections in both directions on both port 443 and 80, and there is no throttling of TCP packets of any kind.

My provider says they had a sniffer on the wire and while repro’ing the problem they would see duplicate packets arrive from upstream. I did the same thing and didn’t see that, but sound like a clue.

Last night we shut off one of the upstream providers (there are about 4 of them) and the problem went away. But I’m not convinced it’s that upstream provider because I’ve seen the problem exist for routes through other providers.

it’s the strangest thing I’ve seen. :)

]]> By: Marcelo Calbucci http://markmaunder.com/2009/ssl-timeouts-and-layer-3-infrastructure/comment-page-1/#comment-754 Marcelo Calbucci Sat, 17 Oct 2009 14:27:23 +0000 http://markmaunder.com/?p=297#comment-754 I'm not an expert... I think this problem might be related to some kind of rule (like outbound firewall) on part 443. I don't think SSL has anything to do with it, but it's TCP problem. Maybe there is a throttling on that port or a bandwidth limit, packet limits, etc. I’m not an expert… I think this problem might be related to some kind of rule (like outbound firewall) on part 443. I don’t think SSL has anything to do with it, but it’s TCP problem. Maybe there is a throttling on that port or a bandwidth limit, packet limits, etc.

]]>