F5 XC and how to keep the Source IP from changing with customer edges!
Old applications sometimes do not accept a different IP address to be used by the clients during the session/connection. How can make certain the IP stays the same for a client?
The best will always be the application to stop tracking users based on something primitive as an ip address and sometimes the issue is in the Load Balancer or ADC after the XC RE and then if the persistence is based on source IP address on the ADC to be changed in case it is BIG-IP to Cookie or Universal or SSL session based if the Load Balancer is doing no decryption.
As an XC Regional Edge has many ip addresses it can connect to the origin servers adding a CE for the legacy apps is a good option to keep the source IP from changing for the same client HTTP requests during the session/transaction.
Before going through this article I recommend reading the links below:
F5 Distributed Cloud – CE High Availability Options: A Comparative Exploration | DevCentral
F5 Distributed Cloud - Customer Edge | F5 Distributed Cloud Technical Knowledge
- RE to CE cluster of 3 nodes
The new SNAT prefix option under the origin pool allows no mater what CE connects to the origin pool the same IP address to be seen by the origin. Be careful as if you have more than a single IP with /32 then again the client may get each time different IP address. This may cause "inet port exhaustion " ( that is what it is called in F5BIG-IP) if there are too many connections to the origin server, so be careful as the SNAT option was added primary for that use case.
There was an older option called "LB source IP persistence" but better not use it as it was not so optimized and clean as this one.
- RE to 2 CE nodes in a virtual site
The same option with SNAT pool is not allowed for a virtual site made of 2 standalone CE. For this we can use the ring hash algorithm.
Why this works? Well as Kayvan explained to me the hashing of the origin is taking into account the CE name, so the same origin under 2 different CE will get the same ring hash and the same source IP address will be send to the same CE to access the Origin Server. This will not work for a single 3-node CE cluster as it all 3 nodes have the same name.
I have seen 503 errors when ring hash is enabled under the HTTP LB so enable it only under the XC route object and the attached origin pool to it!
- CE hosted HTTP LB
In XC with CE you can do do HA with 3-cluster CE that can be layer2 HA based on VRRP and arp or Layer 3 persistence based bgp that can work 3 node CE cluster or 2 CE in a virtual site and it's control options like weight, as prepend or local preference options at the router level.
if a CE can't reach the origin servers in the origin pool it should stop advertising the HTTP LB IP address through BGP.
For those options Deploying F5 Distributed Cloud (XC) Services in Cisco ACI - Layer Three Attached Deployment is a great example as it shows ECMP BGP but with the BGP attributes you can easily select one CE to be active and processing connections, so that just one ip address is seen by the origin server.
When a CE gets traffic by default it does prefer to send it to the origin as by default "Local Preferred" is enabled under the origin pool.
In the clouds like AWS/Azure just a cloud native LB is added Infront of the 3 CE cluster and the solution there is simple as to just modify the LB to have a persistence.
