North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Strange IPSEC activity over UUNet..
Thus said "Craig Holland" on Fri, 25 May 2001 11:01:24 PDT: > have any problems. Then a couple of days ago, my Ricochet connection > stopped working. The only common denominator is any connection that passes > through UUNet/AlterNet doesn't work. Crazy? I dialup to a Telia pop, no I can confirm that there are problems when routing IPSEC traffic through the UUNet/AlterNet networks. At work, I have setup VPNs between our main corporate offices using FreeS/Wan and the setup run without problems for months. Then a few months ago, the routes that were directing the traffic through the broadwing.net network switched to route through UUNet/AlterNet---this essentially killed all VPN traffic. We have been working with our upstream provider to discover what the problem is, but have not yet been successful at determining the problem. > problem. I dial up to a WorldCom POP, no problem. I connect with a Ricochet > (which goes through UUNet in this case)...broken. I dialup to a UUNet > pop...broken. I don't get it. Yep, same for us. Everything is fine until the route goes through UUNet/AlterNet, at which point it drops to almost nothing. > The client reports that it is receiving fragmented packets, and that it > doesn't have the other fragment in its cache. Its almost like the packets > are getting fragmented, and then some of those fragments are getting lost. This also sounds familiar, but I can't confirm this much yet. This basically means that all the packets will have to be retransmitted, however, it only does that intermittently. I have monitored TCP traffic closely and it seems that the Window Size never changes, and in fact, the outgoing queue for traffic on the port (as displayed with netstat -vatn on linux) is very high and very close to the Window Size. In addition, I am seeing a few TCP retransmits of the packets, so apparently something is taking a long time to ACK. Eventually, the stream stalls and just sits there with a full outbound queue (full window). > I've checked all my MTUs and circuits. I've reduced my MTU on the client to > attempt to stop this from happening. I'm running clean as far as I can tell, > and the good connections through other ISPs tells me my system is working > OK. I've pinged my host from the destination network with large packets and > don't lose any. Does anyone have any idea what this might be about? If Same here. I have attempted to reduce the MTU on all of our interfaces, but it doesn't seem to affect anything. ping shows decent latency and even large ICMP packets go through fine (with the exception of a few). As of yet, I don't have any more information, but I'm sure this is something that will have to be fixed because we just can't go forward with a VPN that transfers at 200bps. Andy -- [-----------[system uptime]--------------------------------------------] 2:59pm up 18 days, 17:36, 4 users, load average: 1.07, 1.16, 1.19