IP-address based classes support routing domains in v10.1?

Hi Stephan,

If route domain entries in the datagroup isn't working, I'd suggest opening a case with F5 Support. In the meantime, I think you could create the datagroup with a slightly different format and still get this to work.

If all of the entries are in the same route domain, you could omit the route domain from the datagroup, do a check to see if the client IP is in that route domain and if so, use class match to see if there is a match.

If you want to support multiple route domains in the same address type datagroup, you could create separate datagroups for each route domain using the route domain number in the name of the datagroup.

 class 123
class dg_rd123_ip {
   {
      host 10.123.123.80
      network 10.123.123.96/28
   }
}
 class 456
class dg_rd456_ip {
   {
      host 10.123.123.100
      network 10.123.123.96/28
   }
}

You could then strip off the route domain from the client IP if it's there:

when CLIENT_ACCEPTED {
    Check if there is a route domain in the IP::client_addr value
   if {[scan [IP::client_addr] {%[^%]%%%s} ip rdomain] == 2}{
       There was a route domain for the client IP address
       Check if there is a corresponding class
      if {[class exists "dg_rd${rdomain}_ip"]}{
          There is a corresponding class, so check if the client IP is in it
         if {[class match $ip equals "dg_rd${rdomain}_ip"]}{
             Client IP is in the corresponding class
         }
      }
   } else {
       Client IP doesn't have a route domain, so look up against a default route domain datagroup? ...
      if {[class match [IP::client_addr] equals "dg_rd_default_ip"]}{
          Client IP is in the corresponding class
      } 
   }
}

Granted this is a hack, but it should give you a way to support route domains for the scenario until you get a fix from F5.

Aaron

dupe

dupe

 

dupe

Hi Stefan,

 

 

Sorry, that was confusing. The first rule in my last post will work for your scenario. The second part of my post (starting with "I just tested [class search ...]") was just me saying I tried to use a route domain in the datagroup and the native 'class search' command, but found it didn't work. Maybe I should have switched the order of the post.

 

 

Basically, class search in 10.1, doesn't seem to support route domain entries in the class. So you'd need to use a workaround like I added in the first part of the post.

 

 

I'd suggest opening a case with F5 Support on this. I'd be surprised if they didn't already have a CR (and hopefully a fix) for this issue.

 

 

Aaron

The scan command is trying to parse the IP::client_addr output to see if it's in the form of IP address%route_domain. If it is, then the client IP is searched for in a datagroup which has the route domain in the name. If the IP is in that datagroup, then the connection is allowed. For all other cases, the request is dropped.

Within an iRule the [IP::client_addr] command will then be seen as 82.159.83.112%rd?

That's correct. IP::client_addr will return the client IP and route domain if the connection came in on a VLAN with a route domain set.

Here is a version of the iRule with debug logging to show you how it is working:

when CLIENT_ACCEPTED {

   log local0. "[IP::client_addr]:[TCP::client_port]: Connection to [IP::local_addr]:[TCP::local_port]"

    Check if there is a route domain in the IP::client_addr value
   if {[scan [IP::client_addr] {%[^%]%%%s} ip rdomain] == 2}{

      log local0. "[IP::client_addr]:[TCP::client_port]: Parsed $ip and $rdomain"

       There was a route domain for the client IP address
       Check if there is a corresponding class
      if {[class exists "SMTP_whitelist_${rdomain}"]}{

         log local0. "[IP::client_addr]:[TCP::client_port]: Class, SMTP_whitelist_${rdomain}, exists for route domain $rdomain"

  There is a corresponding class, so check if the client IP is in it
         if {[class match $ip equals "SMTP_whitelist_${rdomain}"]}{

            log local0. "[IP::client_addr]:[TCP::client_port]: Found $ip in SMTP_whitelist_${rdomain}, allowing connection."

             Client IP is in the corresponding class
     Exit this event in this rule
     All other cases will be rejected
    return
         }
      }
   }
    If we're still in the iRule, the client isn't allowed, so drop the connection
   log local0. "[IP::client_addr]:[TCP::client_port]: Dropping request."
   drop
}

Aaron

Hi Stefan,

 

 

If you just remove the route domain, you're negating the value of having them defined. The advantage to the iRule example I posted is that it continues to enforce that the client came in on the correct route domain and that they're in the datagroup.

 

 

Aaron

Running 10.1.0 HF2 has this problem. Opened a case, and got the response:

 

"The problem is known, bug ID 337222. It is targeted for fixing in a software release which is due out sometime between January and June 2011."

 

 

The "work around" for now is to NOT use the route domain in the address data group (class) itself. The matchclass function will strip the route domain when it does the search. So if there is a route domain in the class, it will never match. If there is no route domain in the class, then it will match. So place the class in the Common domain so there is no route domain added to the address entries in the address data group. If you must have an exact match to include the route domain, then use a string data group and loose the ability to match on networks.

 

 

I don't believe this update has been completed yet. So if you find that route domain handling in the class commands would be useful for you, please open a case with F5 Support and ask to have your request attached to ID 337222.

 

 

Aaron