Forum Discussion
Persistence profile - How will I use source address affinity based load balancing?
Hi Experts
How will I use source address affinity based persistence profile across different pools having different IP but same port? For example there are two virtual server 1.1.1.1:80 and 2.2.2.2:80.
1.1.1.1:80 has pool members 192.168.1.1:80 and 192.168.1.2:80
2.2.2.2:80 has pool members 172.16.1.1:80 and 172.16.1.2:80
Load balance algorithm is Round Robin.
Will source based persistence work in this case, such that all sessions from same source IP, say x.x.x.x goes to 192.168.1.1:80 and 172.16.1.1:80. Any other session from y.y.y.y should go to the other pool members.
Regards,
Sumanta.
Don't worry, it's a common scenario for me.
Just pay attention that the upstream proxy insert the "X-Forwarded-For" header, or maybe another one "True-Client-IP" or even "X-Client-IP".
If you are just nating using a firewall, I think that the header is not inserted.
I add this peace of code in the example :
set clientip [IP::client_addr]
because you may have situation where there is no "X-Forwarded-For" in the request, so that we can persist also in this scenario.
- Vijay_ECirrus
"Persistence" is about sticking to a common back-end pool. In your case, it is different pool member as the IP of the pool member is different. You can try to use Universal Persistence (UIE) with a specific hash value assigned to groups of pool members but it can get confusing. If you use the same back-end pool members, you can select "Match Across VS" within source IP based persistence.
- Yann_Desmarest_Nacreous
Yes that's possible. Below an example that you may need to adapt to fit your needs :
when HTTP_RESPONSE { persist add uie $clientip } when HTTP_REQUEST { set clientip "" if { [HTTP::header exists "X-Forwarded-For"] } { set clientip [HTTP::header "X-Forwarded-For"] } else { set clientip [IP::client_addr] } persist uie $clientip }
- Hi Yann Thanks for your help on this. Please note that in my case, client IP in incoming session traffic to F5, represents a single IP NAT-ed to different source IPs. For example, different PCs using DHCP enabled IP addresses behind a firewall, but with single public IP, from the firewall. So, the IP header has single IP, but the http XFF header will have different client IPs. Will this at all work? I haven't come across such a complex scenario before.
Yes that's possible. Below an example that you may need to adapt to fit your needs :
when HTTP_RESPONSE { persist add uie $clientip } when HTTP_REQUEST { set clientip "" if { [HTTP::header exists "X-Forwarded-For"] } { set clientip [HTTP::header "X-Forwarded-For"] } else { set clientip [IP::client_addr] } persist uie $clientip }
- Hi Yann Thanks for your help on this. Please note that in my case, client IP in incoming session traffic to F5, represents a single IP NAT-ed to different source IPs. For example, different PCs using DHCP enabled IP addresses behind a firewall, but with single public IP, from the firewall. So, the IP header has single IP, but the http XFF header will have different client IPs. Will this at all work? I haven't come across such a complex scenario before.
Don't worry, it's a common scenario for me.
Just pay attention that the upstream proxy insert the "X-Forwarded-For" header, or maybe another one "True-Client-IP" or even "X-Client-IP".
If you are just nating using a firewall, I think that the header is not inserted.
I add this peace of code in the example :
set clientip [IP::client_addr]
because you may have situation where there is no "X-Forwarded-For" in the request, so that we can persist also in this scenario.
- Hi Yann Thanks. I have noticed one thing that the XFF is present in all http sessions. So this should work for me. I'll try it on Monday and update you. Also, do I need to use One Connect as well? It is given in sol7392: Overview of universal persistence. Again, too complex. Regards, Sumanta.
- Vijay_ECirrusUse OneConnect for any L7 persistence. So, yes use it. https://network-maven.com/2014/10/12/f5-oneconnect/
- Hi All This is giving error while trying to change source based persistence to universal. 01070394:3: HTTP_REQUEST event in rule (/Common/iRule_xff) requires an associated HTTP or FASTHTTP profile on the virtual server (/Common/AFG_XCAP_VS).
- Yann_Desmarest_Nacreous
Don't worry, it's a common scenario for me.
Just pay attention that the upstream proxy insert the "X-Forwarded-For" header, or maybe another one "True-Client-IP" or even "X-Client-IP".
If you are just nating using a firewall, I think that the header is not inserted.
I add this peace of code in the example :
set clientip [IP::client_addr]
because you may have situation where there is no "X-Forwarded-For" in the request, so that we can persist also in this scenario.
- Hi Yann Thanks. I have noticed one thing that the XFF is present in all http sessions. So this should work for me. I'll try it on Monday and update you. Also, do I need to use One Connect as well? It is given in sol7392: Overview of universal persistence. Again, too complex. Regards, Sumanta.
- Vijay_ECirrusUse OneConnect for any L7 persistence. So, yes use it. https://network-maven.com/2014/10/12/f5-oneconnect/
- Hi All This is giving error while trying to change source based persistence to universal. 01070394:3: HTTP_REQUEST event in rule (/Common/iRule_xff) requires an associated HTTP or FASTHTTP profile on the virtual server (/Common/AFG_XCAP_VS).
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com