Forum Discussion

Kai_Wilke's avatar
Kai_Wilke
Icon for MVP rankMVP
Dec 15, 2022
Solved

Dealing with iRule $variables for HTTP2 workload while HTTP MRF Router is enabled

Hi Folks, I like to start a discussion on how to deal with iRule $variables, which are traversing independed iRule events, in combination with HTTP2 workload and HTTP MRF Router enabled (e.g. HTTP2...
application delivery
  • Kai_Wilke's avatar
    Kai_Wilke
    Feb 12, 2023

    Hi Pete,

    Somehow found the cause of the variable glitch an a final workaround for my problem.

    If you set any local variables during the CLIENT_ACCEPTED event then the outlined strange variable beharior happens.

    If you dont set any variable during the CLIENT_ACCEPTED event, then the HTTP_REQUEST event is able to pass variables to the SERVER_CONNECTED and SERVERSSL_* events and you can also pass variable out of those events to the HTTP_REQUEST_RELEASE event.

    Looks like a very annoying bug. I would love to open a new case, but my MVP support contract just has become outdated.... 🤐

    Cheers, Kai

PeteWhite's avatar
PeteWhite
Icon for Employee rankEmployee

You are correct - the important point to note about MRF ( Message Routing Framework) is that client and server flows are in different contexts. This is actually the great strength of the MRF framework - a message could arrive on TCP and depart on UDP to multiple destinations. Loadbalancing is done based on message, not layer 4 connection. See https://clouddocs.f5.com/api/irules/MR.html 

"MR iRule commands operate within a Tcl context associated with the connection flow between the endpoint and the MR proxy. The ingress and egress parts of a message’s journey therefore operate in separate Tcl contexts. The Tcl context contains the Tcl variables and execution state of the currently executing iRule event. Only one iRule event can execute at a time on a connection flow, therefore messages queue to execute their iRule events.

In many MR protocols, messages belong to independent transactions that are carried over the same network connection flow. It is highly desirable for messages sharing a connection flow to execute their iRules independently of other messages. This provides the following advantages and behavior changes:

  • A message does not need to wait for an unrelated message to complete an event in order to execute its own event.
  • Messages sharing a connection flow may exit the flow in a different order than they entered.
  • Tcl variables cannot be overwritten between events by another message."

To answer your question, you can either use the table as you have done, or use the MR::store and MR::restore commands to access clientside and serverside info from the opposite context.  See https://clouddocs.f5.com/api/irules/MR__store.html 

Kai_Wilke's avatar
Kai_Wilke
Icon for MVP rankMVP
Jan 26, 2023

Hey PeteWhite,

finally found some time to experiment with MR_INGRESS and MR_EGRESS event and the MR::store and MR::restore commands.

Unfortunately those two commands are neither able to copy/link a given variable from lets say the "HTTP_REQUEST" event to the "SERVER_CONNECTED" event. And also not from "SERVER_CONNECTED" to lets say "HTTP_REQUEST_RELEASE" event.

SERVER_CONNECTED and SERVERSSL_* behaving slightly weirdo. Could you please double check the information you've provided?

This simple test illustrates the issue... 

 

when CLIENT_ACCEPTED {
	set CON_ID [TMM::cmp_unit][clock clicks]
	set REQ_ID ""
	log local0.debug "$CON_ID|$REQ_ID"
}
when HTTP_REQUEST {
	set REQ_ID [TMM::cmp_unit][clock clicks]
	log local0.debug "$CON_ID|$REQ_ID"
}
when REMAINING_EVENTS {
	log local0.debug "$CON_ID|$REQ_ID"
}

 

Log output: 

 

 tmm1[17801]: Rule <CLIENT_ACCEPTED>: 11674705152203080|
 tmm1[17801]: Rule <HTTP_REQUEST>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <MR_INGRESS>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <LB_SELECTED>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <SERVER_CONNECTED>: 11674705152203080|
 tmm1[17801]: Rule <SERVERSSL_CLIENTHELLO_SEND>: 11674705152203080|
 tmm1[17801]: Rule <SERVERSSL_SERVERHELLO>: 11674705152203080|
 tmm1[17801]: Rule <SERVERSSL_SERVERCERT>: 11674705152203080|
 tmm1[17801]: Rule <SERVERSSL_HANDSHAKE>: 11674705152203080|
 tmm1[17801]: Rule <MR_EGRESS>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <HTTP_REQUEST_RELEASE>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <HTTP_RESPONSE>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <MR_INGRESS>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <MR_EGRESS>: 11674705152203080|11674705152236713
 tmm1[17801]: Rule <HTTP_RESPONSE_RELEASE>: 11674705152203080|11674705152236713

 

Adding MR::store and/or MR::restore wont make any difference. The SERVER_CONNECTED and SERVERSSL_* events wont see the $var added by HTTP_REQUEST... 

Cheers, Kai

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Feb 12, 2023

    Hi Pete,

    Somehow found the cause of the variable glitch an a final workaround for my problem.

    If you set any local variables during the CLIENT_ACCEPTED event then the outlined strange variable beharior happens.

    If you dont set any variable during the CLIENT_ACCEPTED event, then the HTTP_REQUEST event is able to pass variables to the SERVER_CONNECTED and SERVERSSL_* events and you can also pass variable out of those events to the HTTP_REQUEST_RELEASE event.

    Looks like a very annoying bug. I would love to open a new case, but my MVP support contract just has become outdated.... 🤐

    Cheers, Kai