Forum Discussion

MikeG_331443's avatar
MikeG_331443
Icon for Altostratus rankAltostratus
Aug 29, 2018
Solved

LTM Throttling Proxied Connections in 20 second intervals

Does anyone know where I would look for a solution to this issue I'm having? We have an F5 Big-IP LTM setup in a reverse proxy proxy configuration. It receives data or messages pushed over HTTPS from an external SAP system which is then routed to an internal SAP system. The high level is that if the external system sends a batch of messages, say 50, the F5 receives these message as fast as that external system sends them. However, the F5 relays or proxies those messages to the backend SAP system one at a time in intervals of exactly 20 seconds apart. I have not been able to find anywhere where a 20 second send interval is set anywhere in the system. Has anyone see this type of throttle behavior? We're using an almost default TCP profile with the only exceptions being:

 

  • Proxy Buffer Low - 98304 bytes
  • Proxy Buffer High - 131072 bytes
  • Idle Timeout - 1000 seconds
  • Send Buffer - 65535 bytes
  • Receive Buffer - 65535 bytes
  • Keep Alive Interval - 900 seconds
  • Slow Start - Disabled
  • Nagle's Algorithm - Disabled
  • Acknowledge on Push - Enabled

Appreciate any directions you can point me in!

 

  • It turns out this was a faulty OSCP server upstream that was causing certificate checking to fail. The solution was to remove OSCP from our APM access policy until we can find another, better solution. Thanks everyone for the help!

     

6 Replies

  • Hi,

     

    are you sure that is not SAP that send this message every 20s? did you try an trace to check what's happening. TCPDUMP or irule ?

     

    regards,

     

  • Maybe a HTTP profile added to vip it will wait for at least one http message from the client before opening the server side connection.

     

    do a tcpdump with the -p filter to capture both sides of the connection client to vip - f5 to server.

     

    example "tcpdump -nni 0.0:nnnp -s 0 host X.X.X.X and host X.X.X.X"

     

    • MikeG_331443's avatar
      MikeG_331443
      Icon for Altostratus rankAltostratus

      Thanks for replying! We do have an HTTP profile but I'm not sure what you mean by adding it to a vip (did you mean vs?). It uses the default http parent profile and the only option we've enabled is "Insert X-Forwared-For". I dug around in there but can't find anything that would limit each proxied message to exactly 20 seconds.

       

    • KevinA_246454's avatar
      KevinA_246454
      Icon for Cirrostratus rankCirrostratus

      Hi Mike

       

      I have never seen any material from f5 that indicates a delay of 20 seconds per packet, and yes I meant vs. a standard vs with a http profile will result the vs will complete the 3 way handshake with the client and at wait for a http request from the client before opening up the connection on the server side. but even that will surely not cause a 20 seconds delay.

       

      Like I mentioned you can try to do a tcpdump on the f5 with the -p filter does will allow you analyze traffic from both client to vs and f5 to server. you will then be able to see when the f5 receive the 1st syn or http request and the time difference since the request is made to backend server.

       

    • MikeG_331443's avatar
      MikeG_331443
      Icon for Altostratus rankAltostratus

      Thanks Kevin, I will keep trying with the tcpdump and your suggested settings. It's a bit hard to troubleshoot because we can't trigger the event due to the data coming in from an external source on a random schedule. It's definitely odd because it "should" fire everything to the backend as soon as it received but you could set your watch to the 20 second interval, it's that precise. Was hoping it was just a 20s congestion queue setting somewhere I haven't found yet. Thanks for your help!

       

  • It turns out this was a faulty OSCP server upstream that was causing certificate checking to fail. The solution was to remove OSCP from our APM access policy until we can find another, better solution. Thanks everyone for the help!