Strange IPSEC activity over UUNet..
bradipo at xmission.com
Sun May 27 20:59:33 UTC 2001
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
> 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.
2:59pm up 18 days, 17:36, 4 users, load average: 1.07, 1.16, 1.19
More information about the NANOG