ECMP with OSPF - how the gateway determines the next-hop

[motiami]

Hello,

We have a setup where a ClusterXL is connected to two ASR routers and OSPF is running.

The ASRs advertise to the cluster default route and the cluster installs these default routes in it's routing table so it has two equal-cost default routes to two different next hops.

The ASRs are used as our internet routers and they perform hide NAT when accessing the internet.

We are now facing an issue where one TCP session is routed towards router 1, gets NATed using that router's hide NAT pool, and at a certain time the CP gateway might choose the 2nd router for the same flow and then it gets a different hide NAT IP and hence the session is being terminated.

Is it possible to set the CheckPoint to maintain the same session to be routed to the same router? how does the CheckPoint determine which default route to use? 

I am reading this article and it says:

(4) Limitations

• "Round robin" next hop algorithm is not supported.
  
  
• "Source hash" next hop algorithm is not supported.
  
  
• "Destination hash" next hop algorithm is not supported.
  
  
• ECMP over OSPF supports up to 8 simultaneous routes.

So, what is then the algorithm that the CheckPoint uses in order to determine the next hop?

[Alex_Ambrose]

Hi,

From sk100502:

Nexthops are selected based on weighted fair queuing. Once the next hop is selected it stays the same as long as entry is in the route cache. Once the entry is deleted from route cache nexthop can change when queried for destination next time.

The route cache mentioned above is a Linux concept and is managed by the kernel. There are some sysctl parameters that tune the behavior of the cache, but changing these is done at your own risk.

[motiami]

Alex, thanks for your reply.

The gateway is getting two default routes with equal cost, so once the gateway choose a specific default route to use for a certain session, how come that in the middle of the session it decide to choose the 2nd default route? The session has not ended..

[Alex_Ambrose]

I'm not an expert with how this particular algorithm is run in the Linux kernel, so this is just speculation.

As far as I can tell, the Linux kernel is not connection-aware when determining these nexthops - it goes purely off the routing cache entries. If the entry corresponding to the connection is garbage collected and has to be re-created, it could change the nexthop mid-session. This could especially be the case if there's a lull in the traffic for a particular session and a large quantity of new cache entries being created at the same time. The cache entry for that session would be considered stale and garbage collected automatically to make room for the new entries.