Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

What actually happens when virtual is called from an iRule?

Consider two virtual servers, VS1 and VS2, with iRules IR1 bound to VS1 and IR2 bound to VS2.

If IR1 has...

when HTTP_REQUEST { 
    log local0.info "start IR1" 
    virtual VS2;  
    log local0.info "end IR1"         
}

...and IR2 has...

when CLIENT_ACCEPTED {
    log local0.info "in IR2:CLIENT_ACCEPTED"     
}
when HTTP_REQUEST { 
    log local0.info "in IR2:HTTP_REQUEST" 
}

...what actually happens when I browse to VS1?

  1. Does the iRule processing hit the virtual call in IR1 and call into IR2?

    • if so, does it call into the same event in IR2 that it was at in IR1 (i.e. into HTTP_REQUEST, or does it start again, i.e. at CLIENT_ACCEPTED)
    • would processing return to the code in IR1 after the virtual call?
  2. Or does it proxy a separate, intermediate web request to VS2?

    • if so, what state is retained from the original request to VS1
    • does anything process the code after the virtual call?

Or does something else happen, entirely?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi candcgroup,

the virtual command basically used the specified VS instance as a pool member. The connection flow would be CLIENT <-> FrontEndVS <-> BackEndVS and vice versa.

Use the Virtual Server and iRule setup below to see the involved OSI layers and iRule events in action to serve a single GET request. The log file at the buttom shows you the order of the individual iRule events on both Virtual Servers...

[root@f501:Active:Standalone] config # tmsh 
root@(f501)(cfg-sync Standalone)(Active)(/Common)(tmos)# load sys config merge from-terminal
Enter configuration. Press CTRL-D to submit or CTRL-C to cancel.
ltm virtual VS_FrontEnd {
    destination 172.22.17.223%1:https
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        clientssl {
            context clientside
        }
        serverssl {
                    context serverside
        }
        http { }
        tcp { }
    }
    rules {
        iRule_FrontEnd
    }
    source 0.0.0.0%1/0
    translate-address enabled
    translate-port enabled
}
ltm virtual VS_BackendEnd {
    destination 172.22.17.224%1:https
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        clientssl {
            context clientside
        }
        http { }
        tcp { }
    }
    rules {
        iRule_BackEnd
    }
    source 0.0.0.0%1/0
    translate-address enabled
    translate-port enabled
}
ltm rule iRule_FrontEnd {
when CLIENT_ACCEPTED {
    log local0.debug "Client [IP::client_addr]:[TCP::client_port] connected to VS_FrontEnd on [IP::local_addr]:[TCP::local_port]."
    virtual VS_BackendEnd
}
when CLIENTSSL_HANDSHAKE {
    log local0.debug "Client [IP::client_addr]:[TCP::client_port] esatblished TLS Channel with VS_FrontEnd on [IP::local_addr]:[TCP::local_port]."
}
when HTTP_REQUEST {
    log local0.debug "Client [IP::client_addr]:[TCP::client_port] requested URI = [HTTP::uri]."
}
when SERVER_CONNECTED {
    log local0.debug "VS_FrontEnd using [IP::local_addr]:[TCP::local_port] is connecting to VS_BackEnd on [IP::remote_addr]:[TCP::remote_port]."
}
when SERVERSSL_HANDSHAKE {
    log local0.debug "VS_FrontEnd using [IP::local_addr]:[TCP::local_port] established TLS Channel with VS_BackEnd on [IP::remote_addr]:[TCP::remote_port]."
}
when HTTP_REQUEST_SEND {
    log local0.debug "VS_FrontEnd using [IP::local_addr]:[TCP::local_port] is forwarding the HTTP request to VS_BackEnd on [IP::remote_addr]:[TCP::remote_port]."
}
when HTTP_RESPONSE {
    log local0.debug "VS_FrontEnd using [IP::local_addr]:[TCP::local_port] got a HTTP response from VS_BackEnd on [IP::remote_addr]:[TCP::remote_port]"
}
when HTTP_RESPONSE_RELEASE {
    log local0.debug "VS_FrontEnd using [IP::local_addr]:[TCP::local_port] is forwarding the HTTP response to Client on [IP::client_addr]:[TCP::client_port]"
}
}
ltm rule iRule_BackEnd {
when CLIENT_ACCEPTED {
    log local0.debug "VS_FrontEnd using [IP::client_addr]:[TCP::client_port] connected to VS_BackEnd on [IP::local_addr]:[TCP::local_port]."
}
when CLIENTSSL_HANDSHAKE {
    log local0.debug "VS_FrontEnd using [IP::client_addr]:[TCP::client_port] esatblished TLS Channel with VS_BackEnd on [IP::local_addr]:[TCP::local_port]."
}
when HTTP_REQUEST {
    log local0.debug "VS_FrontEnd using [IP::client_addr]:[TCP::client_port] requested URI = [HTTP::uri]."
        log local0.debug "Sending HTTP response to VS_FrontEnd on [IP::client_addr]:[TCP::client_port]."
        HTTP::respond 200 content "OK"
}
}Loading configuration...
root@(f501)(cfg-sync Standalone)(Active)(/Common)(tmos)# quit
[root@f501:Active:Standalone] config # tail -f /var/log/ltm
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <CLIENT_ACCEPTED>: Client 172.21.92.19%1:52406 connected to VS_FrontEnd on 172.22.17.223%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <CLIENTSSL_HANDSHAKE>: Client 172.21.92.19%1:52406 esatblished TLS Channel with VS_FrontEnd on 172.22.17.223%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <HTTP_REQUEST>: Client 172.21.92.19%1:52406 requested URI = /.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <SERVER_CONNECTED>: VS_FrontEnd using 172.21.92.19%1:52406 is connecting to VS_BackEnd on 172.22.17.224%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_BackEnd <CLIENT_ACCEPTED>: VS_FrontEnd using 172.21.92.19%1:52406 connected to VS_BackEnd on 172.22.17.224%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <SERVERSSL_HANDSHAKE>: VS_FrontEnd using 172.21.92.19%1:52406 established TLS Channel with VS_BackEnd on 172.22.17.224%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <HTTP_REQUEST_SEND>: VS_FrontEnd using 172.21.92.19%1:52406 is forwarding the HTTP request to VS_BackEnd on 172.22.17.224%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_BackEnd <CLIENTSSL_HANDSHAKE>: VS_FrontEnd using 172.21.92.19%1:52406 esatblished TLS Channel with VS_BackEnd on 172.22.17.224%1:443.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_BackEnd <HTTP_REQUEST>: VS_FrontEnd using 172.21.92.19%1:52406 requested URI = /.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_BackEnd <HTTP_REQUEST>: Sending HTTP response to VS_FrontEnd on 172.21.92.19%1:52406.
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <HTTP_RESPONSE>: VS_FrontEnd using 172.21.92.19%1:52406 got a HTTP response from VS_BackEnd on 172.22.17.224%1:443
Mar 18 16:40:26 f501 debug tmm1[12155]: Rule /Common/iRule_FrontEnd <HTTP_RESPONSE_RELEASE>: VS_FrontEnd using 172.22.17.223%1:443 is forwarding the HTTP response to Client on 172.21.92.19%1:52406
^C
[root@f501:Active:Standalone] config # 

Note: If you look carefully to the resulting log file of this demo setup, you will notice that the FrontEnd Virtual Server will even negotiate a TLS channel with the BackEnd Virtual Server. So better make sure the FrontEnd Virtual Server does not utilize a ServerSSLProfile and the BackEnd Virtual Server does not utilize a ClientSSLProfile.

Cheers, Kai

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Using the iRules you provided, this is the log output that I got: Image Text It seems like the entire event is processed before the connection is moved to the new virtual server. Once the virtual server moves over the connection, it reconstructs the connection and fires off the appropriate event, including the CLIENT_ACCEPTED event.

0