Forum Discussion

ChrisA_15714's avatar
ChrisA_15714
Icon for Nimbostratus rankNimbostratus
Mar 16, 2011

How to turn on Destination Address Affinity persistence

Hi .... I'm brand new to F5. We are running an GTM/LTM 1600 on v10.2. I'm having a problem where a user is going to a site ( ) and he gets there but the authentication fails. It only happens when the traffic is passing through the F5. I opened a ticket with F5 support and the engineer suggests I "turn on Destination Address Affinity persistence on the VIP" to see if that resolves the problem. I have no idea where to look or what to do, or if this change could break something. Any help would be appreciated. Thank you. Chris.
  • Destination Address Affinity Persistence:

     

     

     

    Destination Address Affinity Persistence, also known as sticky persistance, directs requests for a certain destination IP address to the same server, regardless of which client made the request.

     

     

    This type of persistence provides the most benefits when load balancing caching servers. A caching server intercepts web requests and returns a cached web page if it is available. In order to improve the efficiency of the cache on these servers, it is necessary to send similar request to same server repeatedly. You can use the destination address affinity persistence type to cache a given web page on one server instead of on every server in array. This saves the other servers from having to duplicate the web page in their cache, wasting memory.

     

     

     

    I don't think your problem is going to be resolved by this. Recheck the VLAN configuration of your F5 and run a TCPDUMP on internal/external interfaces to see what's happening at packet level.
  • What's behind your VIP? Are you load balancing gateways or proxies or something? Sounds like this is outbound traffic so I'm assuming so? You can configure destination address persistency from the resources tab of your VIP but if the user can't connect at all going through the F5, I doubt that's the issue.

     

     

    Can you explain more about the type of VIP? Performance Layer 4? Standard? Forwarding?
  • Thank you alabaster & Chris. I appreciate your help. I'm afraid you will need to go very slowly with me. Users on our network are initiating a web connection to the destination url. The users can get to the destination site okay but cannot authenticate. The F5 Engineer reviewed the tcpdumps from the F5 device and suggested setting up the destination addr persistence affinity to see if it works. We have two F5 devices: each one sits in front of a different ISP (for ISP redundancy). One unit shows status "Active" and the other one shows status "Standby". By VIP I assume you are referring to Local Traffic > Virtual Servers: Virtual Server List. We have an outbound HTTPS (443) forwarder defined with type "Performance (Layer 4)" and protocol "fastl4_long_idle". We have an outbound HTTP (80) forwarder defined the same way. We also have a generic outbound forwarder that is set up as type "Forwarding (IP)" and protocol "fastl4_long_idle". So I'm guessing I need to set up another forwarder for 8443 traffic, restricting to the destination IP. Am I on the right track? Is this change fairly innocuous?
  • Great overview Chris! That helps a lot.

     

     

    F5 LTMs will use the most specific Virtual Server that matches your request. So, since you don't currently have a forwarder setup for 8443, it'll use the generic one.

     

     

    Could you do me a favor? Via the GUI, select your HTTPS (443) Forwarder Virtual Server. Near the top of the screen, you should find a "Resources" tab. From that tab, you should be able to see whether there's a "persistence profile" enabled.

     

     

    Creating a forwarder for tcp:8443 should indeed be simple enough. Is there a specific reason you're interested in restricting it to a particular IP instead of simply mirroring your HTTPS443 VIP?
  • Glad to hear that Chris - Our of curiosity - did you have persistence enabled for your HTTPS (443) Forwarder?
  • Yes, there is a virtual server outbound_https_forwarder which has the Default Persistence Profile defined as Custom_Dest_Persist. This profile has a parent of dest_addr (which has destination address affinity set) but also has "Mirror Persistence", "Match across services" and "Match across virtual servers" checked. The prof. svcs. eng. from F5 set all that up, so I'm not sure why he had to create a custom profile and check those options. The virtual server I set up just points to the dest_addr profile that has destination address affinity set without those other boxes checked.