Forum Discussion

Sylvain_85827's avatar
May 16, 2013

iRule redirection using Data Group List not working

Hi,

 

I'm trying to put in place a redirection based on several sources IP host or network adresses. To do such a thing I thought using Data Group List and iRule.

 

Here is the configuration in place:

 

** VS:

 


- Name: Wildcard (0.0.0.0:0)
- Type: Standard
- Pool : Only one node (10.109.1.20:80)
- iRule : myIrule

 

** Data Group List :

 


- Name: _test_Data_Group_List
- Type: Address
- Records:
   (X) Type: Network
   (X) Address: 192.168.109.0
   (X) Mask: 255.255.255.0
   (X) Value: (I entered nothing here)

 

** iRule :

 


- Name: myIrule
- Code:
when CLIENT_ACCEPTED {

    log local0. "remote addr [IP::remote_addr]"

    log local0. "client addr [IP::client_addr]"

    if { [class match [IP::client_addr] equals _test_Data_Group_List] } { node 10.109.1.10 80 }

}


 

 

Basically what I want to demonstrate is that:

 

1/ Witout the iRule, flows are always load-balanced towards 10.109.1.20:80

 

2/ With the iRule, flows are always load-balanced towards 10.109.1.10:80

 

1/ is working fine however when I enable the iRule for 2/, it does not produce the expected behavoir; ie. the traffic is still sent to 10.109.1.20:80 instead of being redirected to 10.109.1.10:80 !

 

In logs I can see no execution errors and that client IP matches the range I defined in the Data Group List:

 

May 16 09:54:57 local/tmm1 info tmm1[4866]: Rule myIrule : remote addr 192.168.109.1

May 16 09:54:57 local/tmm1 info tmm1[4866]: Rule myIrule : client addr 192.168.109.1

Could you please help me to point out where my mistake is? Thank you in advance for your very precious help!

 

With regards.

 

PS: I precise my source IP is 192.168.109.1 and I'm using LTM v10.2.4

 

2 Replies

  • One last precision, if you're using routing domains other than the default one (ie. %0), there is a known issue: http://support.f5.com/kb/en-us/solutions/public/12000/300/sol12301.html?sr=29447417

     

    The SOL includes two work-arounds, both require listing all matches and not a network range. The most scalable and least ugly is the first option presented in the SOL where a list of "matching" addresses is provided in a "String" class instead of an "Address" class.