Hi,
Are there any plans to introduce resilient hashing: https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/resillient-hashing-lag-ecmp.html?
I know ECMP mulitpath needs to land first, but be good to add this to the roadmap. Without, you briefly lose all peering sessions if any BGP peer goes down (or a new one is added).
Thanks.
ECMP hashes changing should not normally affect peering sessions. Sure, if the peering session is over the ECMP link (implying multihop) then different paths would get chosen, but that should not affect the TCP session itself. The case where resilient hashing is more useful is ECMP load balancing of anycast endpoints, but (while I do exactly that) I think it’s a more niche use case.
+1
In a properly designed network, the BGP sessions are all PtP, there’s no multi-hop and therefore there’s no ECMPing for the session itself. Niche feature that isn’t a priority for most professional networking environments.
We’re starting to use RouterOS multipath (v7.22+) with BGP to ECMP towards anycast-style service VIPs (ie, the same prefix being advertised from multiple nodes). In that scenario, resilient hashing will materially improve stability.
This isn’t about keeping the BGP TCP session stable (agree that the session is typically single-path PtP). It’s about data flow stickiness when the ECMP next-hop set changes (peer maintenance/flap/scaling). Without resilient hashing, adding/removing a next-hop can remap a large proportion of existing flows, which can cause disruption for long-lived TCP and UDP traffic.
Resilient ECMP hashing is a common capability on many established routing/switching platforms (eg Cisco, Juniper, Arista, Extreme, Dell, etc) as well as the Linux kernel. It would pair very naturally with RouterOS multipath so be great to include in the roadmap.