Forum Discussion

Peter_Lowdon's avatar
Peter_Lowdon
Icon for Altocumulus rankAltocumulus
Feb 23, 2023

Sideband Connection ID

hi f5'ers,

We've encountered a weird problem when upgrading Big-IP from v14 to v16 in conenction with sideband and Node.js.

We have an iRule which opens a sideband connection to the local Node.js instance, streaming an XML string which is then converted to JSOn format and returned to the iRule for further processing.

This all works like a dream in v14, super fast and without issue.

When we upgrade to v16 Big-IP we noticed that 5 minutes after the first sideband connection to Node.js the node.js instance is restarted.  Then 5 minutes after the first sideband connection is received by teh restart Node.js it is restarted again and so on every 5 minutes.  When node.js is restarted there is an interruption in our transformation service which is not really acceptable.

We thought we had found a "workaround" by setting the idle timeout on the TCP profile associated with the virtual server the sideband is connecting from 300 seconds to "indefinite".  This does seem to prevent the Node.js instance from rebooting BUT we noticed the free memory is all used up over an hour or so and there is anotehr event after 75 minutes that also results in transformation service loss.

Whilst investigating this issue tonight I put a line in the iRule to log the connection ID for the sideband connection and came across somethgin weird.

This is the code which creates the new sideband connection and assigns connection identifier variable $conn_id

set conn_id [connect -myaddr [IP::local_addr] -protocol TCP -timeout 5000 -idle 30 -status conn_status VS_CISR_JSON_SIDEBAND_XMLtoJSON1]

BUT if I try and log the variable $conn_id in /var/log/ltm with the command

log -noname local0.info "ConnectionID: $conn_id"

I actuall see
"Connection ID: connect -protocol TCP -myaddr 10.0.31.110 -idle 30 -timeout 5000 /LDL/VS_CISR_JSON_SIDEBAND_XMLtoJSON1"

Is this right?

I was expecting the variable $conn_id to be some sort of numeric identifier which referenced the sideband connection instance, something like "7665e87as778e788778" not the actual string used to create teh sideband connection.

I'm pretty sure this is wher eour problem lies now, the sideband conenction isn't getting closed correctly with the "close $conn_id" command in the iRule so it times out after 300 seconds.

Does anyone else actually use Sideband and if you do what does your connection identifier look like?

Thanks in advance,
Peter

 

3 Replies

  • Peter_Lowdon To me it seems like the correct informaiton logged but your "-protocol" and "-myaddr" seem to be out of order from what your set variable has. My best guess is in the previous version you were feeding those variables for your sideband connection and that was the correct syntax in v14 but now in v16 it isn't. I would recommend rolling back to v14 if you can afford to and creating the same log entry line to see what data you receive so that you can prove this theory. You might also look at your v14 configuration and compare it to your v16 configuration because some differences are bound to exist which could be causing this odd behavior. I have never had the opportunity to deal with sideband connections but this is definitely the route I would take to troubleshoot the issue. You might even create a qkview and open a ticket with F5 so you can upload this qkview and take a look at the iHealth output for your configuration because sometimes iHealth does point you in the right direction.

  • And... as far as I know, you should be entitled to technical support in this case.

    Although F5 support will not help with iRule development (you may buy professional services for that), in the case of an iRule that stops working, or introduces wrong/undesirable behavior, after an upgrade, support may be directly involved.

    /Mike

  • After further investigations I've discovered the problem lies in the closing of the ILX PLugin flow.

    I ran the same ILX Plugin code with the same transaction request with logging enabled in v14 and v16 firmware.

    In the The v14 firmware which works you can see "Flow closed" but in the v16 firwmare log you can see "Flow expired" some time after the flow should have been closed.