Forum Discussion

Luca_55898's avatar
Luca_55898
Icon for Nimbostratus rankNimbostratus
Sep 05, 2012

LTM sending TCP resets

This is a tough one...

 

We have a customer who has a VS setup on our LTM - its a very basic setup, just port 80 with the default HTTP profile and SNAT.

 

He is doing some external testing and are seeing the occasional http error with HTTP traffic

 

TCP dumps show lots of TCP retransmissions, out of sequence and resets being sent.

 

When he bypasses the LTM he doesn't see any errors with his testing.

 

Any thoughts here? I know its a bit vague.

 

What can i do on the LTM to try and see why it would be sending TCP resets?

 

config
design
  • Patrik_Jonsson's avatar
    Patrik_Jonsson
    Icon for MVP rankMVP
    Sep 05, 2012
    If for some reason the pool members is down it'll send a reset.

     

    If he has an iRule which chooses the pool and it's unable to match the requirements to choose one it could send a reset.

     

     

    Have you asked him to check the LTM log?

     

     

    Kind regards,

     

    Patrik
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Sep 05, 2012

    > Any thoughts here? I know its a bit vague.

     

     

    You're right, it's a bit vague. It's tough to give you real meaningful feedback without further info. At a high level, I suspect the connection points between the client and the LTM are different than when the client hits the Pool Member directly. If the retrans are between the client and the LTM, and you don't see any retrans between the LTM and the Pool Member, I would start examining the infrastructure between the LTM and the client. I've seen duplex mismatches between switches cause this type of problem lots of times.

     

     

    If you are somewhat skilled with TCP analysis, you should also be able to confirm where the packet loss is occuring. You simply look for individual packets that are sent by the LTM and not received by the client. If you see the LTM sent a packet but it wasn't received, then you need to move down the chain to the next connection point and perform the same test. You can also use this methodology but starting from the client side of the connection. Keep moving down the connection chain (or up, depending on whether you start at the LTM or the client) until you isolate the point where packets are getting dropped.