Forum Discussion

Pedro_Haoa_7122's avatar
Pedro_Haoa_7122
Historic F5 Account
Aug 19, 2017

iRules Optimization for MAC filtering with Data Groups (If/else)

Hello Everyone,

I'm trying to figure out an optimized version of the following (currently working) iRules, in order to validate via Machine Info, the incoming MAC Address from different customers to a BIG-IP APM Access Policy.

The iRules have been validated in version 12.1 and 13. Any advice/recommendation will be welcome.

Here we have an example of the LTM Data Groups deployed:

pedro.haoa@(f5chile)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm data-group one-line
ltm data-group internal MACGRP_1001_external_chile { records { F4:15:63:11:22:33 { } F4:15:63:11:22:34 { } F4:15:63:11:22:35 { } } type string }
.
.(Output Omitted)
.
ltm data-group internal MACGRP_1370_external_chile { records { F4:15:63:44:55:66 { } F4:15:63:44:55:67 { } F4:15:63:44:55:68 { } } type string }
.
.(Output Omitted)
.
ltm data-group internal MACGRP_2001_external_bolivia { records { 00:23:E9:22:33:44 { } 00:23:E9:22:33:44 { } 00:23:E9:22:33:44 { } } type string }
.
.(Output Omitted)
.
ltm data-group internal MACGRP_2350_external_bolivia { records { 00:23:E9:55:66:77 { } 00:23:E9:55:66:78 { } 00:23:E9:55:66:79 { } } type string }
.
.(Output Omitted)
.

And here we have two iRules to validate more than 700 different Data Groups:

 BIG-IP APM Event
when ACCESS_POLICY_AGENT_EVENT priority 410 {
 Access Policy Branch Filter
if { [ACCESS::policy agent_id] eq "macgrp" } {
 Variables for LAN/WLAN Interfaces
    set mac0 [ACCESS::session data get "session.machine_info.last.net_adapter.list.\[0\].mac_address"]
    set mac1 [ACCESS::session data get "session.machine_info.last.net_adapter.list.\[1\].mac_address"]
 Variable to reduce data along the iRule due to the 64k limit.
    set s session.logon.custom.macgrp
 if/else statements to validate the MAC addresses contained within each data group
if {[class match $mac0 eq MACGRP_1001_external_chile]||[class match $mac1 eq MACGRP_1001_external_chile]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACGRP_1002_external_chile]||[class match $mac1 eq MACGRP_1002_external_chile]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACGRP_1003_external_chile]||[class match $mac1 eq MACGRP_1003_external_chile]} {ACCESS::session data set $s 1}
.
.(Output Omitted)
.
elseif {[class match $mac0 eq MACGRP_1369_external_chile]||[class match $mac1 eq MACGRP_1369_external_chile]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACGRP_1370_external_chile]||[class match $mac1 eq MACGRP_1370_external_chile]} {ACCESS::session data set $s 1}
} }

Second iRule (Split mode):

 BIG-IP APM Event
when ACCESS_POLICY_AGENT_EVENT priority 420 {
 Access Policy Branch Filter
if { [ACCESS::policy agent_id] eq "macgrp" } {
 Variables for LAN/WLAN Interfaces
   set mac0 [ACCESS::session data get "session.machine_info.last.net_adapter.list.\[0\].mac_address"]
   set mac1 [ACCESS::session data get "session.machine_info.last.net_adapter.list.\[1\].mac_address"]
 Variable to reduce data along the iRule due to the 64k limit.
   set s session.logon.custom.macgrp
 if/else statements to validate the MAC addresses contained within each data group
if {[class match $mac0 eq MACGRP_2001_external_bolivia]||[class match $mac1 eq MACGRP_2001_external_bolivia]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACGRP_2002_external_bolivia]||[class match $mac1 eq MACGRP_2002_external_bolivia]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACGRP_2003_external_bolivia]||[class match $mac1 eq MACGRP_2003_external_bolivia]} {ACCESS::session data set $s 1}
.
.(Output Omitted)
.
elseif {[class match $mac0 eq MACGRP_2349_external_bolivia]||[class match $mac1 eq MACGRP_2349_external_bolivia]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACGRP_2350_external_bolivia]||[class match $mac1 eq MACGRP_2350_external_bolivia]} {ACCESS::session data set $s 1}
elseif {[class match $mac0 eq MACADM_CHECK]||[class match $mac1 eq MACADM_CHECK]} {ACCESS::session data set $s 1}
} }

Cheers!

2 Replies

  • Josiah_39459's avatar
    Josiah_39459
    Historic F5 Account

    Instead of checking existence, wouldn't it be better to make a giant key->value pair datagroup and have the MAC searched (key) returned the number of the group matched (value).

     

    • Pedro_Haoa's avatar
      Pedro_Haoa
      Ret. Employee

      It could be.

       

      This approach is worse because it's heavier to process. But I think this way is better in terms of management, segmentation and granularity.

       

      Can you add more details with an example?