Scaling Out a VIP across the cluster video question

Hi,

 

There is very nice video about spanned VIP and ECMP by Alex Applebaum (ScaleN Part 5: Scaling Out a VIP across the cluster.

 

I think I figured out packet flow but would like to confirm that I am not wrong. It seems that example config is using one leg setup and packet flow is like that:

 

client (10.128.1.1->10.0.0.1) -> Router with ECMP (10.128.255.251 10.1.255.251) -> BIG-IP 1/2/3 external self IP (10.1.50.201/202/203) -> VS (10.0.0.1) -> SNAT (10.0.0.11/12/13) - src ip 10.0.0.11/12/13 dst ip 10.100.30.3 -> Router with ECMP (10.1.255.251 10.100.30.251) -> server (10.100.30.3)

 

Above assumes that 10.1.255.251 is default route on BIG-IP devices.

 

Returning packet follows same path with BIG-IP doing proper address translation.

 

Is above correct?

 

I am not expert in ECMP are so I wonder how TCP connection persistence can be preserved with such config.

 

I assume that only way to not break given TCP session is to always route packets with srcIP:port-dstIP:port via the same BIG-IP - Am I right? If so can it be done on ECMP routers?

 

Then I wonder how to provide persistence at the L7 level?

 

There is one VIP defined that is accepting traffic on all BIG-IP in the cluster. But instance of VIP on each BIG-IP is separate so it is creating own persistence records and this info is not shared between them.

 

So I assume that using persistence based on persistence records (PR) will not work. Example:

 

• First TCP session from IP 10.128.1.1 is directed to BIG-IP1
• BIG-IP1 chooses member and creates PR
• Second TCP session from same IP is directed to BIG-IP3
• BIG-IP3 has not PR for this src IP, so it chooses member (could be the same as on BIG-IP1 but could be other) and creates PR

Persistence for client is broken. Except of course if ECMP router always direct traffic from given IP to the same BIG-IP (so ports are not used for making decisions) - but it could really mess up with load balancing among BIG-IPs in cluster.

 

However persistence based on cookie should work. No matter which BIG-IP will receive HTTP request with bigip cookie it will direct it to member specified in the cookie.

 

But it is solution working only for HTTP. Is there any for other protocols than HTTP? Could CARP work here - I guess that is only one not using PRs?

 

Piotr