Stickiness for Load-Balanced Flows

Starting in Contrail Networking Release 23.2, CN2 supports flow stickiness. Flow stickiness helps minimize flow remapping across equal-cost multipath (ECMP) groups in a load-balanced system.

Traditional ECMP load-balances traffic over a number of available paths toward a destination. When one path fails (scale-down) or a new path gets added (scale-up), the traffic gets reshuffled over the available number of paths. Flow stickiness reduces the flow being remapped and retains the flow with the original path when the ECMP group's member change. When a flow is affected by a member change, the vRouter reprograms the flow table and rebalances the flow.

Figure 1 shows an example of a flow remapping scenario that occurs when a new member is added to a 3-member ECMP load-balancing system.

In this example, a flow request is sent to IP address: 172.16.0.20. Because this three members group have the virtual IP address: 172.16.0.20, the vRouter sends the request to pod1 based on the flow hash calculation. When a new member (pod4) is added to the same virtual IP group, the request is diverted and redirected to pod4 based on the flow hash recalculation.

Flow stickiness reduces the flow being remapped and retains the flow with the original path to pod1 through the new member (pod4). If adding pod4 affects the flow, the vRouter reprograms the flow table and rebalances the flow with pod1.

Table 1 shows the expected results for normal hash and flow stickiness for scale-up and scale-down scenarios.

Table 1: Expected Results: Members Added or Deleted from an ECMP Group

Example Scenario	Normal (Static) Hash Result	Flow Stickiness Result
ECMP group size is 3.	Based on the flow hash, traffic is directed to pod1.	Based on the flow hash, traffic is directed to pod1.
Adding one more pod to the same service. ECMP group size is 4.	Flow redistribution is possible and traffic can be redirected to another pod.	Traffic continues to be directed to pod1.
Deleting one pod from same service. ECMP group size is 2.	Flow redistribution is possible and traffic can be redirected to another pod.	Unless pod1 is deleted, traffic continues to be directed to pod1. If pod1 is deleted, the session must be reinitiated from client.

Note:

Flow stickiness is only supported for an ECMP flow before and after scale up (stickiness is not maintained when scaling up from one pod to multiple pods). We recommend that you add at least two pods to an ECMP group and then scale up.