Forum Discussion

CSUC's avatar
Icon for Nimbostratus rankNimbostratus
Jun 14, 2021

Long list of redirections on a Data Group that not always works

Hello everyone,


I need to make a lot of redirections depending on the uri (without a pattern), so I imported a file to a string Data Group and made an irule that checks the uri and make the appropriate redirection only if the uri is in the Data Group.


The problem is that sometimes works and sometimes not.


Is there a limitation on the number of entries in a Data Group that an F5 can manage appropriately? We work with software version BIG-IP v14.1.4 (Build 0.120.11) on a BIG-IP i4600, and the data group has more than 4K entries.


This is the irule:


when HTTP_REQUEST priority 1 {

   set uri [HTTP::uri]

   set pagina [ class lookup $uri redireccions_recercat ]

   #set pagina [ class match $uri ends_with redireccions_recercat ]

   if {$pagina ne ""} {

       HTTP::redirect $pagina

       #HTTP::respond 301 Location $pagina


else {

      set pagina [ class lookup $uri redireccions_recercat_new ]

      if {$pagina ne ""} {

          HTTP::redirect $pagina

          #HTTP::respond 301 Location $pagina



event disable



The second lookup is because the uri sometimes starts with one / and sometimes with // depending on the link, so I make two checks. I tried with a class match, but it did'n work...


That is the best approach? What's the problem with the "class match"?


Thank you so much!


2 Replies

  • 1.For many entries in data groups better use external data group:






    2.Another thing is to enable logging at different level to see if you requests match the irule at different stages:








    3.Also as note with your version you can try to use F5 Local Traffic policies as they support data groups and are less buggy or CPU intensive than iRules:







    4.The final thing is to look the bug tracker if you checked everything like the irule matching the traffic, etc. You searc by "data group" and see if you match a bug:



  • Note that if more than one HTTP request is received on the same connection, only the first will trigger your iRule because you unilaterally disable the HTTP_REQUEST event at the end of your iRule, regardless of whether any redirection occurred or not. Therefore, if a second HTTP request comes in on the same connection, your iRule will not trigger. Unless there is a specific reason to disable the HTTP_REQUEST event, you should probably remove the event disable command.