Hi, I need help deciding between choosing the best compatible type for the VIP.The needs:Customer-facing VIP that will forward client data to other VIPS. Behind this 'backend' VIP will be a few servers, This architecture is needed to manipulate traffic between two different VIPs on different sites. (to clear a site for maintenance, for example)I debated between Performance (HTTP) and performance L4.No special requirements will be applied to this VIP. I need to record the source IP of the client all the way (XFF), and I need to configure a short TTL for the TCP session without health traffic (requests)All the iRules/LTM will be applied to the backed VIPs. Also, I not sure where is the best place to use the WAF policy for the front/back end VIPThank you all!

Hi, Can you provide more information about your setup? In your front vip, what is exactly needed? How do you choose what backend pool member to send traffic to? Keep in mind that fastl4 and fasthttp come with limitations, for example both don't support waf functionality. Be sure to read this too: https://my.f5.com/manage/s/article/K4707

Hi, the backend VIP is standard and sends the traffic round-robin between the servers.The front VIP should send data to the backend VIPs in his pool. The manipulation will be made by RestAPi to enable/disable the relevant pool member.

MaxMedov It seems like the better purposed device for the first layer would be a GTM or another device that can perform GSLB since it is going to be performing generic forwarding to a pool of VIPs anyway. Having a VIP to balance to VIPs adds unnecessary delay when the only purpose is to send you to multiple destination VIPs.

The VS type to choose is not obvious because it depends on several factors. Generally speaking: Performance L4 is used to forward traffic as fast as possible and the cost is you loose many advanced functionalities which are available on the standard VS. Standard VS is the VS to go to take advantage of all the functionalities that the VS can offer, particularly Layer 7 manipulation and optimization. Since you go up to L7, the cost is most processing and time needed to serve traffic. Peformance HTTP is a type that is used to increase performance for some types of HTTP traffic, it is only relevant when the traffic condtions are optimal, thus it is most likely not efficient for internet facing traffic. With that being said, there are many factors that will let you choose one or another, and using Performance L4 does not guarantee that the overall performance will be better: for example the Compression and Acceleration (cache) profiles that are available on the standard type (and not on the L4) can make the overall user experience better than with L4 VS. On another side, using L4 or performance HTTP VS does not let you associate a WAF policy to the VS, so your backend VS both need to be on an F5 that has the WAF license. So I think you should conduct a global approach (including the GTM option) to decide what to use. Or just test all the possible types and compare the results.

From what I understood here, better to set the Standard profile type on the 'Front-end VIP' and Performance HTTP/L4 on the 'Back-end VIP.' All the traffic manipulation (iRule/LTM and WAF) will be done on the first 'Front-end VIP,' then traffic was local only so I can use Performance HTTP

VIP Type decision | DevCentral

16 Replies

Amine_Kadimi
MVP
Feb 25, 2023
Hi,

Can you provide more information about your setup? In your front vip, what is exactly needed? How do you choose what backend pool member to send traffic to?

Keep in mind that fastl4 and fasthttp come with limitations, for example both don't support waf functionality.

Be sure to read this too: https://my.f5.com/manage/s/article/K4707
- MaxMedov
  Cirrostratus
  Feb 25, 2023
  Hi, the backend VIP is standard and sends the traffic round-robin between the servers.
  The front VIP should send data to the backend VIPs in his pool. The manipulation will be made by RestAPi to enable/disable the relevant pool member.
  - Paulius
    MVP
    Feb 25, 2023
    MaxMedov It seems like the better purposed device for the first layer would be a GTM or another device that can perform GSLB since it is going to be performing generic forwarding to a pool of VIPs anyway. Having a VIP to balance to VIPs adds unnecessary delay when the only purpose is to send you to multiple destination VIPs.
MaxMedov
Cirrostratus
Feb 26, 2023
From what I understood here, better to set the Standard profile type on the 'Front-end VIP' and Performance HTTP/L4 on the 'Back-end VIP.' All the traffic manipulation (iRule/LTM and WAF) will be done on the first 'Front-end VIP,' then traffic was local only so I can use Performance HTTP
- Paulius
  MVP
  Feb 26, 2023
  MaxMedov That is the general concensus if you need iRule and WAF functionality on the front-end VIP but really this should be a GSLB function that points to the back-end so that you are not limiting yourself on either tier if the front-end is really just balancing to multiple virtual servers that perform the same function. Even if they didn't perform the same function you could use different FQDNs to make a DNS decision on where to send requests.
  - MaxMedov
    Cirrostratus
    Feb 27, 2023
    Hi Paulius, I am making the routing decision on R53 geolocation and failover records.
    But I also want to make a routing for the clients who don't accept the changes and keep hardened DNS records or receive a wrong (long TTL) resolution from their ISP.
    The plan is to create a new "customer-facing" VIP, and behind him, the traffic will be routed to the same site or another VIP on another site. (traffic manipulation during the site routes).
    For that design, I want to use RestAPI to enable/disable dedicated VIP in the pool member and send the "stuck" client to the right VIP depends the site route needs.
    Im debating between Perfomance HTTP and L4 and where to configure them better - on the customer-facing VIP or the VIPs behind (backend).
    I using iRules and WAF.
- Amine_Kadimi
  MVP
  Feb 27, 2023
  This sounds like a good approach, all the performance consuming traffic will be handlend in frontend VIP, and backend won't have to do what was already done (waf, compression, ssl, cache...).
  
  Performance L4 sounds OK for its lower impact on processing time unless you need oneconnect to reduce the backend connection table size, which is available in Performance HTTP.
  - MaxMedov
    Cirrostratus
    Feb 27, 2023
    Amine_Kadimi Thank you for your answer!
    On the other hand, we have client smoke scripts that initiate the client path.
    If the backend VIP is without waf, compression, SSL, cache, etc., the result will not be correct enough. To imitate a client, I should send the script to the frontend VIP directly, but it will route me to the next VIP in the Pool when it site routed to another site. (the primary pool member VIP disabled)
    So from that perspective, I need the Backend VIP with all the feathers.
    Front VIP can be standard too, but it will do the same work twice and raise the latency
    In this case, Performance HTTP /L4 will be better on the front VIP.
    Between them, what do you recommend? I should receive all the possible data from the client in the end to collect logs.
MaxMedov
Cirrostratus
Feb 27, 2023
So you say I will not see the source IP of the client on the backend VIPS?
I made a test and set WAF on the backend VIP.
Send GET to the Front VIP, check the WAF logs on the backend VIP, and receive XFF.
I'm unsure about the SSL process. Can you please clarify it for me?
When configuring Performance L4 type, LTM forwards the traffic as 1-4 layers F5 is transparent to the client.
If I need to handle SSL (client profile) on the backend VIP, how its work?
- Amine_Kadimi
  MVP
  Feb 27, 2023
  Yes I said that. Seeing XFF headers in backend logs does not mean they have been inserted by the Performance L4 VS. I'm not aware of your setup and I cannot tell what intermediary server has inserted the headers but if you get them then it's good for you.
  
  For new issues please start a new thread
  - MaxMedov
    Cirrostratus
    Feb 28, 2023
    Thank you Amine_Kadimi !