Solved

ECMP Hush Bucket

  • 22 November 2018
  • 1 reply
  • 213 views

Hello everyone,

Can someone clarify for me why the hashing algorithm isn't bound the original flow to the original "Hush Bucket" once the ECMP route come back to live?
My logic says that the input values for the hashing algorithm is the same as before, thus point to the same egress port.

Thanks 🙂
icon

Best answer by Eric Pulvino 27 November 2018, 05:10

https://docs.cumulusnetworks.com/display/DOCS/Equal+Cost+Multipath+Load+Sharing+-+Hardware+ECMP

Our docs here do a pretty good job of spelling out what is occurring.

Normal hashing is not resilient to link/next-hop failures and not resilient to link re-additions.
Whenever a link/next-hop dies it could impact all flows headed to the destination.
Similarly whenever a new next-hop is added (or re-added) back to the group all flows in flight are subject to modification. Normal hashing provides the least possibility of polarization due to the fact that the hash allocations are always being optimized both when next-hops come and go.

Resilient hashing is resilient only to link/next-hop failures but NOT resilient to link re-additions due to the nature of the way the algorithm is implemented. When in the failed link/next-hop state it is possible that hash polarization could manifest for the hash-buckets which were previously supporting the failed next-hop. Resilient hashing is not a default behavior, if it is useful to your environment it can be enabled as needed.
View original

1 reply

Userlevel 5
https://docs.cumulusnetworks.com/display/DOCS/Equal+Cost+Multipath+Load+Sharing+-+Hardware+ECMP

Our docs here do a pretty good job of spelling out what is occurring.

Normal hashing is not resilient to link/next-hop failures and not resilient to link re-additions.
Whenever a link/next-hop dies it could impact all flows headed to the destination.
Similarly whenever a new next-hop is added (or re-added) back to the group all flows in flight are subject to modification. Normal hashing provides the least possibility of polarization due to the fact that the hash allocations are always being optimized both when next-hops come and go.

Resilient hashing is resilient only to link/next-hop failures but NOT resilient to link re-additions due to the nature of the way the algorithm is implemented. When in the failed link/next-hop state it is possible that hash polarization could manifest for the hash-buckets which were previously supporting the failed next-hop. Resilient hashing is not a default behavior, if it is useful to your environment it can be enabled as needed.

Reply