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

[mrege]

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 function using irule redirect.

#irule on standard server for redirect
when CLIENTSSL_DATA {
virtual performance_l4_VS
}

The intention here is to offload the application load balancing to eVPA hardware acceleration.

Will this reduce the load on the CPU usage, assuming this will be processed in FPGA?

[JRahm]

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]

i'm asking internally if anyone else has insights

[Brandon_ · Accepted solution]

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]

@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_]

@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.

[mrege]

@Brandon_ 

Just to provide some background on the post,

We have an application for which we initially utilized performance l4 VS to offload the traffic to ePVA but later we had to encrypt the traffic using TLS. 

So the traffic load was moved from Performance L4 VS to a standard VS  for SSL termination (newer requirement)

As soon as we moved the traffic to Standard VS, We started observing spike in CPU usage as standard VS traffic is processed in CPU under TMM process.

Hence was reviewing the VIP-targetting-VIP solution by @JRahm 
https://community.f5.com/t5/technical-articles/lightboard-lessons-vip-targeting-vip/ta-p/286897

if it can be used to address the similar setup by clubbing Standard VS (processing SSL/TLS) and performance L4 VS (performing Load balancing and source_ip persistence) to reduce CPU load.

[Brandon_]

Ah. I see. VIP targeting will not be of any value here.

I would suspect that your additional CPU might be due to your ciphers not being hardware accelerated. If you're running older hardware some of the chipsets don't support newer ciphers and therefore might be processed in general purpose CPU. This K article lists which ones are accelerated by version and by platform.

https://my.f5.com/manage/s/article/K13213 

The clientssl profile statistics for your virtual server can likely help you with that research as well.

You can sometimes re-order the ciphers to prefer ciphers that are hardware accelerated. A lot of modern browsers also tend to order preferring newer ciphers but that might buy you some breathing room for a bit. This can help you there.

https://my.f5.com/manage/s/article/K01770517

If those don't help, you might want to reach out to your friendly neighborhood SE or open a support case to maybe help diagnose where the additional load is coming from and possible options.

[mrege]

@Brandon_  
The Ciphers are definitely offloaded to the hardware. I could see them populated in the "Offload" field for various ciphers for the VS as you mentioned in your screenshot.
We are aware of the load of the CPU dataplane due to application traffic on the even numbered cores . Just wanted to see if it can be offloaded to Hardware (FPGA) somehow😀 with some VS (Performance L4) magic as it was doing prior to encryption.

But seems like to perform SSL termination on Bigip, Standard VS is necessary.

Thanks for your help and providing insight needed to debunk the VIP-targeting-VIP possibility for this issue.

[Brandon_]

Unfortunately no such voodoo. 🙂

[PSFletchTheTek]

Hi @Brandon_ ,

To ask a possibly stupid question, if the performance L4 pushes the tls to hardware.

Could you not set a performance L4 as the front VS to do the decrypt, then set a standard VS behind that with NO SSL Client SSL profile.

It might still be putting load on the TMM, but it might be lower? Or have a missed the point here?

[Brandon_]

@PSFletchTheTek 

https://my.f5.com/manage/s/article/K12015

Virtual servers capable of performing SSL decryption/encryption

If you want the BIG-IP system to decrypt and/or encrypt SSL traffic, you must define the following virtual server type:

• Standard

  The standard virtual server is the only virtual server type that can be associated with Client SSL and Server SSL profiles, and perform SSL decryption and/or encryption. If you want the BIG-IP system to decrypt and/or encrypt SSL traffic, you must import the SSL certificates to the BIG-IP system and configure a standard virtual server and appropriate SSL profile.

As you can see below there is no configuration option for clientssl on anything other than a standard virtual server. But in your scenario, the FPGA fast-path forwarding would happen before TLS termination which needs to be done by tmm. The FPGA and crypto chipsets are different hardware components within a BIG-IP. And tmm pushes the crypto operations to the specialized hardware for offload.

  

[PSFletchTheTek]

Thanks for the explaination, I "thought" that performance L4 had the ssl client/server config in it.
But i'm corrected. I was thinking of HTTP Profiles!

[mrege]

Thanks @JRahm @Brandon_