Forum Discussion

MaxMedov's avatar
Icon for Cirrostratus rankCirrostratus
Feb 25, 2023

VIP Type decision

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 VIP

Thank you all!

16 Replies

  • 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:

    • MaxMedov's avatar
      Icon for Cirrostratus rankCirrostratus

      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's avatar
        Icon for MVP rankMVP

        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.

  • 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's avatar
      Icon for MVP rankMVP

      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's avatar
        Icon for Cirrostratus rankCirrostratus

        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.

    • 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's avatar
        Icon for Cirrostratus rankCirrostratus

        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.

  • 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?


    • 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