Forum Discussion

Piotr_Lewandows's avatar
Piotr_Lewandows
Icon for Altostratus rankAltostratus
Dec 07, 2017

Local Traffic Policy and iRule events

Hi,

I was reading some post about order of execution, in other words if Local Traffic Policy (LTP) executes before or after iRule.

Seems that answer is both 🙂

Scenario:

  • VS with all ports allowed
  • LTP with TCP port is not equal to any of 80; 443 and action Reset traffic
  • iRule with CLIENT_ACCEPTED, HTTP_REQUEST, ACCESS_SESSION_STARTED events (actually few more are in iRule)

Without any mods to iRule effect is like that:

  • All commands in CLIENT_ACCEPTED are executed
  • LTP is triggered to reset traffic (log action is performed, so I can see it triggers)
  • All commands in HTTP_REQUEST are performed
  • No command in ACCESS_SESSION_STARTED is executed
  • RST-ACK is send to client
  • CLIENT_CLOSED event is triggered

So LTP is not preventing CLIENT_ACCEPTED and HTTP_REQUEST events to be triggered but disables other events and resets connection.

I can understand why CLIENT_ACCEPTED is triggered but why HTTP_REQUEST? And why using only matching at TCP connection in LTP causes LTP parameter $1 have http included?

I am as well setting variable via LTP. From logging it is obvious that this variable is not yet created when CLIENT_CONNECTED event is executed but it is when HTTP_REQUEST triggers.

So for some events iRule is executed first for other LTP. Main question is why LTP allows HTTP_REQUEST to be triggered at all? Matching and actions in LTP are only for TCP protocol not HTTP.

Reason I am asking is that I planned to use LTP to limit traffic to specified ports but seems it is not a good solution. Seems that it has to be performed in iRule at least when there is some code to be executed in CLIENT_ACCEPTED as there is no way to disable this event anyhow - or maybe there is?

Implementation of Reset traffic is a bit weird. It is using TCP RST for that even if it is still allowing HTTP request to be processed. I understand that LTP is targeting HTTP traffic handling but then instead of TCP RST we should be able to use HTTP respond to more gracefully end client connection.

I am able to disable HTTP_REQUEST by setting variable in LTP and checking it in HTTP_REQUEST but not in CLIENT_ACCEPTED.

That could be avoided if LTP would not allow HTTP_REQUEST to be triggered.

I guess that limiting traffic for all port VS is then possible in two ways:

  • AFM policy
  • iRule

Or there is some other way?

Piotr

devops
http_request
iRules
LTM
ltp
order of execution
reset traffic
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Dec 07, 2017

    LTP events trigger before same Irule event, but LTP action doesn't prevent Irule event.

     

    I already shared a workaround to prevent Irule execution when LTP action is redirect.

     

    You can try if LTP reset action return a different value in command [POLICY::targets]

     

  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Dec 08, 2017

    I can understand why CLIENT_ACCEPTED is triggered but why HTTP_REQUEST? And why using only matching at TCP connection in LTP causes LTP parameter requires { http tcp } have http included?

     

    I had the same strange behavior... LTP is a feature to replace HTTP-CLASS in versions before 13.0.

     

    In version 11.X, we could select manually policy requirements, since version 12.0, this is done automatically and some requirements are wrong:

     

    • http is always enabled
    • when we want to add a condition on SSL sever name, it requires ssl-persistence and not clientssl...