Forum Discussion

mrege's avatar
mrege
Icon for Altocumulus rankAltocumulus
Sep 12, 2023
Solved

VIP-targeting-VIP solution using Standard and performance L4 VS

Is it possible to configure following decrypted application traffic processed in performance L4 virtual server where in the CLient facing Standard virtual server will be performing SSL offloading fu...
application delivery
SSLtraffic
VIP-targetting-VIP
  • Brandon_'s avatar
    Brandon_
    Sep 12, 2023

    In that scenario since the standard virtual server is terminating TLS the traffic still all needs to be handled by the first tmm. The fastest path is to just let it do its job and forward the traffic.

    Forwarding it to a second virtual server starts another handshake (w/ TCP) between two tmm’s where the second makes a load balancing decision, so essentially you’re adding unnecessary overhead by forwarding just to have a load balancing decision made at the second virtual server. 

    This is a good reference article. https://my.f5.com/manage/s/article/K8082#l4

    The FPGA is in the dataplane on ingress and egress from the switch (iSeries for example) or is the network interface on rSeries. Therefore if the first tmm terminating TLS has to process the traffic, it's being released down to the FPGA for forwarding on egress already.

JRahm's avatar
JRahm
Icon for Admin rankAdmin

Hi mrege that's a good question. You can certainly use vip-to-vip to fan application traffic among different needs on backend virtuals, but once all that data is already in TMM, I'm not quite sure it would save CPU to push it back down to the hardware at that point, even if it could (which would need to be tested.) Also, you can certainly use an iRule, but a policy works as well and keeps logic in native objects:

ltm policy vip-to-vip {
    controls { forwarding }
    last-modified 2023-09-12:09:44:17
    requires { http }
    rules {
        fwding-vip {
            actions {
                0 {
                    forward
                    select
                    virtual /Common/testapp-vip
                }
            }
        }
    }
    status published
    strategy first-match
}
JRahm's avatar
JRahm
Icon for Admin rankAdmin
Sep 12, 2023

i'm asking internally if anyone else has insights

  • Brandon_'s avatar
    Brandon_
    Icon for Employee rankEmployee
    Sep 12, 2023

    In that scenario since the standard virtual server is terminating TLS the traffic still all needs to be handled by the first tmm. The fastest path is to just let it do its job and forward the traffic.

    Forwarding it to a second virtual server starts another handshake (w/ TCP) between two tmm’s where the second makes a load balancing decision, so essentially you’re adding unnecessary overhead by forwarding just to have a load balancing decision made at the second virtual server. 

    This is a good reference article. https://my.f5.com/manage/s/article/K8082#l4

    The FPGA is in the dataplane on ingress and egress from the switch (iSeries for example) or is the network interface on rSeries. Therefore if the first tmm terminating TLS has to process the traffic, it's being released down to the FPGA for forwarding on egress already.

    • mrege's avatar
      mrege
      Icon for Altocumulus rankAltocumulus
      Sep 12, 2023

      Brandon_ So essentially, the VIP-targetting-VIP solution would not work from standpoint  of bringing CPU utilization down and processing in FPGA when clubbed with performance L4 VS 

      The usage of  VIP-targetting-VIP solution would only work from functionality standpoint of application traffic redirection based on matching condition ?

      • Brandon_'s avatar
        Brandon_
        Icon for Employee rankEmployee
        Sep 12, 2023

        mrege correct.

        Check out the multi-layer firewall solution lab we've done for Agility. https://clouddocs.f5.com/training/community/firewall/html/class1/module1/module1.html

        Because VIP targeting creates a new TCP connection you can terminate TLS and forward the traffic based on some form of L7 information and attach a different L3/4 firewall policy to each secondary virtual. /login and /admin can have different firewall policies for example.

        But for say an AWAF policy you can just attach those based on LTM policies similar to the example that JRahm suggested rather than forwarding to a second virtual server.