Forum Discussion
mrege
Altocumulus
AltocumulusVIP-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...
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
Admin
Admini'm asking internally if anyone else has insights
Brandon_
Employee
EmployeeIn 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.
mregeBrandon_ 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
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/286897if 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.