Forum Discussion

kuhn_52743's avatar
kuhn_52743
Icon for Nimbostratus rankNimbostratus
Sep 14, 2009

"Address In Use" TCL Error

Hi,

 

 

This may be a silly error as I am new to iRules.

 

 

Attempting to route a connection to a specific pool member from within an RTSP_REQUEST event.

 

 

The TCL statement is:

 

 

pool PACK_33382_72.46.235.131_554_POOL member $pool_member

 

 

In the above, $pool_member contains the IP address of the server that the connection should be routed to.

 

 

When that executes, I get this error message:

 

 

Sep 14 14:45:13 tmm tmm[2095]: 01220001:3: TCL error: pv_irule_fcs_1 - Address in use (line 1) invoked from within "pool PACK_33382_72.46.235.131_554_POOL member $pool_member"

 

 

I also tried adding a port to the "pool" command, to make it explicit, with the same result. Then I tried hard coding the ip address of the pool member instead of using the variable substitution, e.g. I did --

 

 

pool PACK_33382_72.46.235.131_554_POOL member 10.122.87.76

 

 

-- but I still get the same error.

 

 

One other note - this pool only has one member right now, but later will have more so I need to route to a specific host.

 

 

Any ideas? Thanks...

 

 

Scott

 

  • I've attached the text of the iRule.

     

     

    There's a lot of stuff in there that may be confusing, but look for the text "*** Address in use error next line ***"

     

    and it's the line after that which generates the error.

     

     

    Basically all I've done is looked in a hash table to pull out the address that I want to send the connection to (the IP address of the pool member) and then use the "pool" command to try to do so.

     

     

    Thanks,

     

    Scott
  • I am not sure if this information is going to help or not but just in case...

     

     

    here is a few thing to note about RTSP feature in BIG-IP

     

    - RTSP uses TCP as a transport. BIG-IP may make a load balancing decision at beginning of connection (or when client send first RTSP message)

     

    - RTSP feature in BIG-IP is not designed to support per message switching... (for example, when client make RTSP connection to server, client may send DESCRIBE message, wait for response then send SETUP, and so on...) All messages from client will go to one server.

     

    (BIG-IP is designed to support per message switching for some protocols such as SIP)

     

     

    there might be a way to do message switching in the middle of connection by using LB::detach. I never try so I can't tell. (however, after running LB::detach, existing server connection will be disconnected)

     

    see http://devcentral.f5.com/wiki/default.aspx/iRules/LB__detach.html

     

    and http://devcentral.f5.com/wiki/default.aspx/iRules/LDAPProxy.html

     

    for more information about LB::detach

     

     

    Nat
  • Nat,

     

    i think you may be onto something - my irule tried to route the connection after the client sends DESCRIBE, but what may be happening is the client had already sent OPTIONS on the RTSP connection and already been load balanced.

     

    In my case, there is only a single server in the pool, so it would be the same server, but maybe once it's been load balanced then the "pool" command is bound to throw the error in any case.

     

    I'll check it out and report the results back here. Thanks much for your input.

     

     

    Scott

     

  • Update:

     

     

    Nat's post led me to understand what was happening. I was indeed attempting to use the 'pool' command to route a connection that had already been routed. So I worked around it by checking at the beginning to see if the connection already was established to a pool member, and not using 'pool' again if that was the case.

     

     

    In order to check whether a connection already had an established server connection, I use [IP::server_addr]. My original plan was that if it comes back as zero, it's not routed to a server yet. That doesn't work because if it's not part of an established connection, it throws an exception. I didn't expect that, because the documentation says it will just return 0 if no connection is established. So instead, I use the "catch" statement to catch an error if no server side exists.

     

     

    Scott