[c-nsp] 256s cyclics in GRE?

[Andre Beck]

Hi Dave,

On Tue, Dec 27, 2005 at 08:27:00AM -0500, Dave Temkin wrote:
> What is the keying/data timeout set to on the IPSec tunnels in the PIX?

That of course has been the first thought here, too. But they are way
larger than 256s and cannot be the problem anyway, as there is no loss
at all through the IPsec VPN itself, only through the GRE tunnels that
are established on top of the IPsec VPN. It also wouldn't really explain
the synchronicity of the effect since the SAs are timing out more or less
randomly after the system is up for some months. The PIX has been my
first suspect, but after days of testing and monitoring I'm now confident
it's completely innocent.

We've also changed the connection of the PIX to some other switch to
rule out an odd effect there - without change. I'm now pretty sure this
is a glitch in the 3745 router that terminates all the GRE tunnels at
the central site. Seems opening a TAC case would be the natural next
step here...

Odd enough, I meanwhile got another 3745 with a strange tendency to drop
certain packets when just doing silly routing between the two 100Base.
The packets that fail to make it seem to trigger the loss by content, at
least that's what my sniffer suggests - and the fact that it breaks TCP
connections after some hundred MiBytes have traveled over them. The
receiver is desperately ACKing for a certain segment he never saw, the
transmitter is repeatedly resending it, but it still doesn't turn up at
the receiver - finally the transmitter (Windows) tells me a lie about
"connection reset by peer" which is not true as there was no RST. It
probably bailed out on the ACK storm from the receiver that tried to
ACK an old segment over and over again...

Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-