Forum Discussion

CraigD1_147916's avatar
CraigD1_147916
Icon for Cirrus rankCirrus
Aug 21, 2018

VS Order of Precedence When Using iRules

Hoping you guys will help me out here with a couple of questions. I have a defined VS that accepts conns from any src_ip to the dest_ip of the VS on a list of ports as defined in an irule. This works fine.

I need to insert another VS with the same IP and I am trying to use the higher order of precedence as defined by f5 of preferring specific src_IP to dest_IP on any port. I also want to define these source IPs in a data group. I am creating a new VS for this due to a number of different settings being needed on this VS versus the existing VS.

So really, my questions are:

  1. If I configure a VS with a datagroup for source IPs and reference that in an irule, will that take precedence over the other VS that allows ANY source IP but is limited by port ranges as defined in that VS irule. Based on K14800, I think it should, though it doesn't really specify that setting the src_ip port etc by irule plays by the same precedence rules as a static definition in the VS config.

  2. If 1 will work as I understand it, what would the irule look like in the new higher precedence VS? I believe the following will send a RST to any client that doesn't match the DG, when I really just want it to move on to the next best matching VS. 

    when CLIENT_ACCEPTED { 
    if { not ([class match [IP::client_addr] equals SRC_IP_DG])} { 
        reject
   } 
}

application delivery
iRules
LTM

4 Replies

Sort By
  • CraigD1_147916's avatar
    CraigD1_147916
    Icon for Cirrus rankCirrus
    Aug 21, 2018

    Maybe this makes more sense? But will it skip the VS match and move on to the next best matching VS?

    when CLIENT_ACCEPTED { if { not ([class match [IP::client_addr] equals SRC_IP_DG])} { return } }

  • CraigD1_147916's avatar
    CraigD1_147916
    Icon for Cirrus rankCirrus
    Aug 21, 2018

    Well, now I think "when CLIENT_ACCEPTED" is going too deep when I just need to inspect the syn packet and if the src_ip doesn't match the data group, move on to other possible VS matches. FLOW_INIT "seems" more appropriate but the possible actions listed in the irule wiki don't seem to indicated that I can do the above.

     

  • Lee_Sutcliffe's avatar
    Lee_Sutcliffe
    Icon for Nacreous rankNacreous
    Aug 21, 2018

    Hi Craig,

    Order of precedence is processed in a way that processes a more specific match first. So if your virtual server with a datagroup has a /32 destination, it is more specific than a wildcard vs using 0.0.0.0 as the destination. So to answer question one, assuming you have a more specific destination for the first VS, VS: 10.10.10.10:443 will take precedence over 0.0.0.0:443.

    If you reject a connection in the VS that takes precedence, it will not automatically try the next VS. It will issue an RST to the client and when it tries again, will be processed by the same VS (assuming it is using the same connection - source and dest IP/port)

    if you want to send a connection to another VS you can use the 

    virtual
    command like this

    when CLIENT_ACCEPTED { 
    if {!([class match [IP::client_addr] equals SRC_IP_DG])} { 
        virtual OTHER_VS_NAME 
    } 
 }
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Aug 22, 2018

    If you want to manage precedence with an irule, the best way is to use layered virtual server!

    • Create as many virtual servers as you want listening on whatever port and IP address you want, not the real ports and addresses. Make this virtual server listening on NO VLAN.
    • Create a virtual server listening to any source and any port, without default pool.
    • create an irule or even better create a policy with an condition on IP address and an action 
      forward virtual LAYERED_VS_1