Forum Discussion

genseek_32178's avatar
genseek_32178
Icon for Nimbostratus rankNimbostratus
Aug 28, 2013

F5 TCP Issue

Hi,

 

We have a destination IP - 1.1.1.1 being accessed via an application from src-172.20.20.1, and there is no delay in response.

 

Now the destination is a VIP behind the LB with 10 pool members. When accessing destn VIP, there seems to be a delay from 2-3ms to 50ms. But when accessing the pool member from the same source, there is no response delay.

 

Not sure how F5 is adding to the delay here, because ping response from source to 1.1.1.1/VIP/pool member is same <2ms.

 

Any insight would be gr8 here?

 

Thanks -genseek

 

10 Replies

  • isn't tcpdump helpful?

     

    Tcpdump with Snat

     

    https://devcentral.f5.com/questions/tcpdump-with-snatanswer78624

     

  • thank you for the response, nitass. There is no snat configured on the VIP virtual.

     

    But before doing tcpdump, want to enquire that is it likely that F5 could be causing the issue here? If yes, in what could it cause issue and what is it that should be seen as causing issue in tcpdump output.

     

  • There are any number of proxy-level functions that can potentially slow down the request/response. Are you offloading SSL? Do you have an iRule applied? Do you have any other protocol-modifying profiles applied to the VIP config? Is there any application logic that may not be able to handle being behind a proxy?

     

    The TCPDUMP will help you to understand WHERE the traffic is slowing down. Run it on the client side AND the server side and compare the flows and timing.

     

  • no ssl offloading happening, no irules. Not sure about application logic.

     

    what is it that should be seen in the output of tcpdump to identify what is causing the slowness? Also, pleas provide the exact syntax of tcpdump for client and server side.

     

  • You're looking specifically at timing - when the packet goes in, when it comes out, when the server returns a response, and when the proxy releases it.

    Assuming you have VLANs labeled "internal" and "external", the following minimal TCPDUMP syntax should get you what you need:

    tcpdump -lnni internal:nnn host [host IP filter] [and other filters]
    
    tcpdump -lnni external:nnn host [host IP filter] [and other filters]
    

    With the differences you're seeing, the source of the delay should be fairly observable in the captures.

  • kevin, am new to fairly new to tcpdump

     

    Can you be more specific with the tcpdump syntax, like, with the IPs that have been given.

     

    src172.20.20.1 VIP - 1.1.1.1 DIP - 1.1.1.10

     

    so i can take the cmd directly and execute on F5.

     

  • From the BIG-IP command line, issue the following to show the TCPDUMP manual:

    man tcpdump
    

    There you'll find all of the syntax you need and some pretty good examples.

    tcpdump -lnni internal:nnn host 1.1.1.1 and host 2.2.2.2
    

    This basically says, take a network capture, without trying to resolve host names and protocol names (-lnn), on the "internal" interface/VLAN (i internal), make the output verbose (:nnn), and filter the traffic so I only see packets coming from or going to host IP 1.1.1.1 and 2.2.2.2.

    Do this on the external interface (client source address to BIG-IP VIP), and on the internal interface (client source if not SNATting or SNAT address to server IP). Do these at the same time in separate windows so that you can see the full packet flow.

  • thank you for the response kevin. Another question..

     

    Isn't the delay in response normal when F5 is in between and client is accessing destination via VIP than when F5 is not in between?

     

  • Isn't the delay in response normal when F5 is in between and client is accessing destination via VIP than when F5 is not in between?

     

    normally it should not be significant.

     

  • To answer your question, yes. It's another hop between client and server, so that would introduce a little delay, but normally I'm talking about milliseconds. If you're seeing significant delays when the proxy is in the middle, you should see that amount of delay coming from the server or from the BIG-IP in your network captures. The idea here is to first isolated what's causing the delay, and then to figure out why.