Forum Discussion

epaalx's avatar
epaalx
Icon for Cirrus rankCirrus
Nov 03, 2016

No clientside connection established

I'm running 12.1.1, vCMP.

I've created a basic iRule that I've attached to a UDP VS:

rule log_udp_conn_details {
 when SERVER_CONNECTED {
  log local0.alert "[virtual] - [IP::client_addr]:[UDP::client_port] -> [clientside {IP::local_addr}]:[clientside {UDP::local_port}] ::: [serverside {IP::local_addr}]:[serverside {UDP::local_port}] -> [IP::server_addr]:[serverside {UDP::remote_port}]"
 }
}

and now, I'm getting in /var/log/ltm:

Nov 3 10:02:14 XX-dc-5250v-1-vcmp-guest-1 err tmm1[17437]: 01220001:3: TCL error: /Common/log_udp_conn_details - no clientside connection established (line 1) invoked from within "IP::client_addr"

Within SERVER_CONNECTED event, is the clientside connection is not already established? Within UDP VS, at what event would clientside connection is established?

  • Hi,

    you can collect client side data in CLIENT_ACCEPTED and server side data in SERVER_CONNECTED:

    when CLIENT_ACCEPTED {
       set sessionLog "[virtual] - [IP::remote_addr]:[UDP::remote_port] -> [IP::local_addr]:[UDP::local_port] ::: "
    }
    
    when SERVER_CONNECTED {
       append sessionLog "[IP::local_addr]:[UDP::local_port] -> [IP::remote_addr]:[UDP::remote_port]"
     log local0.alert $sessionLog
    }
    
  • I was able to execute the iRule without any errors on my v12.1 BIG-IP system using a UDP virtual server. Can you show your virtual server's configuration, please, so that we may see what profiles you may have attached?

     

  • Great... I was sure there was nothing wrong with it.

     

    I don't want to share the VS configuration, but I can tell you that it contains a RADIUS traffic profile.

     

    Since this profile executes Message-based load-balancing (MBLB), I suspect it is the culprit. However, MBLB should only affect server-side, not client-side, so, I cannot account for the error I got.

     

  • The typical client-side/server-side connection flow that you see to with HTTP for example does not occur with RADIUS and other MBLB traffic. I don't begin to know all the ins and out but I know it's very different. There's a great white paper by Lori McVittie here: https://f5.com/resources/white-papers/message-based-load-balancing

    In the meantime, you might simply try saving the client info to a variable on the CLIENT_ACCEPTED event, then referencing the variable on the SERVER_CONNECTED event. I'm not sure if the mapping is accurate but.... Something like this perhaps:

    when CLIENT_ACCEPTED {
        set client_info "[virtual] - [IP::client_addr]:[UDP::client_port] -> [IP::local_addr]:[UDP::local_port]"
    }
    
    when SERVER_CONNECTED {
        log local0.alert "$client_info ::: [IP::local_addr]:[UDP::local_port] -> [IP::server_addr]:[UDP::remote_port]"
    }
    

    You shouldn't have to worry about specifying the "clientside" or "serverside" contexts as the context is built into each event.

  • There's a great white paper by Lori McVittie here ...

     

    It's sort of superseded now by MRF, as per "Migrating MBLB Functionality to MRF Functionality" document. (Although MRF isn't available for RADIUS, yet.)

     

    However, again, the only question I want to know the answer to is - why the error. Either it's intended or unintended consequence of MBLB.