Forum Discussion

DP's avatar
DP
Icon for Nimbostratus rankNimbostratus
Feb 17, 2016

Node selection for non-HTTP traffic

I've setup a standard VS with no HTTP profile applied, only TCP. The protocol I'd like to load balance is custom and TCP-based.

There's 1 iRule applied which I've based on this: https://devcentral.f5.com/codeshare/proxy-protocol-receiver

The application sends the correct PROXY header information which is confirmed in the logging.

I want to be able to route the TCP connection / data based on the client's source IP. I've tried adding the following 2 commands (not at the same time of course) under the "TCP::release" command to direct at a specific pool member:

pool Test_Pool member $dstaddr 2626

node "$dstaddr:2626"

I've added additional logging when certain events are triggered. The number after the event name is randomly generating when a client connects to track each connection. A session ID basically.

The issue is the node/port in the LB_SELECTED event, which is the correct one, doesn't match the SERVER_CONNECTED event and the connection fails.

: 57527607 CLIENT_ACCEPTED: 192.168.2.96:59381

: 57527607 TCPVER: TCP4 - SRCIP: 192.168.3.16 - DSTIP: 192.168.2.104 - SRCPORT: 64566 - DSTPORT: 2727

: 57527607 LB_SELECTED: 192.168.2.104:2626

: 57527607 SERVER_CONNECTED: 192.168.2.137:2626

The server should connect back to itself but on a different port. This is because I'll be doing further manipulation of the TCP data in the future but just trying to get the basic load balancing working for now.

Any ideas what might be going on here?

Cheers.

application delivery
iRules
LTM

2 Replies

  • VernonWells's avatar
    VernonWells
    Icon for Employee rankEmployee
    Feb 18, 2016

    Ordinarily, the server-side connection is initiated at the completion of the client-side three-way handshake, so the order of events should be:

    1. CLIENT_ACCEPTED
    2. LB_SELECTED
    3. SERVER_CONNECTED
    4. CLIENT_DATA

    Since you execute the 

    node
    command in CLIENT_DATA, this may raise LB_SELECTED again, but it would have no effect, since the server-side is already connected. Try performing an LB::detach before the 
    node
    command.

  • DP's avatar
    DP
    Icon for Nimbostratus rankNimbostratus
    Feb 18, 2016

    Hi Vernon.

    I tried your suggestion of adding a 

    LB::deatch
    after the 
    TCP::release
    and before the 
    node
    or 
    pool
    command but the same issue occurred.

    I added more logging to track down what events fire and when.

    The server is chosen, that is LB_SELECTED fires, after 

    TCP::release
    is executed. 
    LB::detach
    and then 
    node
    or 
    pool
    didn't seem to have any effect on the LB server decision.

    I then removed the 

    LB::detach
    and both 
    node
    or 
    pool
    commands and added 
    LB::reselect node $dstaddr 2626
    to the LB_SELECTED event and everything now works correctly.

    So my summary sequence of events / commands is:

     - No server chosen

     - No server chosen

    TCP::release

     - A server from pool chosen

    LB::reselect node $dstaddr 2626

     - Correct server is chosen. 192.168.2.104 in example above.

    TCP data flow

    Another thing I tried was 

    TCP::collect 5 0
    in the CLIENT_ACCEPTED event.

    That caused the SERVER_CONNECTED event to fire in the CLIENT_ACCEPTED event and the 

    LB::detach
    and then 
    node
    or 
    pool
    worked as expected.

    However the client application expects a server banner to proceed and the SERVER_CONNECTED event doesn't fire for the new, correct server IP until data is received from the client. Therefore the connection stalls because the client never sends any more data while waiting for the server banner.

    Thanks.