Re:Service provider story about tracking down TCP RSTs
by bogomipz on Sunday September 02, 2018 @01:02AM
(#17895646)
Sure, I meant when the same 5 tuple is oscillating between different paths which really should not happen.
You mentioned there were plenty other ways to avoid polarization. I would be curious to hear what those are.
Re:Service provider story about tracking down TCP RSTs
by alecbenzer on Sunday September 02, 2018 @08:35AM
(#17896763)
New to most of this but couldn't you just salt the hashes being used per-router?
Re:Service provider story about tracking down TCP RSTs
by bogomipz on Sunday September 02, 2018 @01:53PM
(#17897860)
Yeah I think you could seed each router's hashing with something unique like a mac address hardware ID but you could also just use different hashing at each tier in your network like using source IP + dest IP on one tier and source IP + dest IP + IP protocol on another tier. This should achieve the same result.
Re:Service provider story about tracking down TCP RSTs
by alecbenzer on Monday September 03, 2018 @05:47PM
(#17905086)
Yeah but then you need to keep coming up with new ways of hashing things as you add tiers. It's easier to generate a new salt than it is to figure out a new but still-valid way of hashing the packets.
Re:Service provider story about tracking down TCP RSTs
by bogomipz on Wednesday September 05, 2018 @09:15AM
(#17917586)
Practically speaking this isn't an issue though. You don't see many spine and leaf networks that are deeper than 3 tiers(edge, distribution, ToR) which means one link upstream and one down. It's not like people build networks arbitrarily deep.
The term for unwanted oscillation between different paths is, IIRC, "flapping".
However, when working with ECMP (equal-cost multi path), you actually do want to use all your paths (hence "equal cost") simultaneously (for load-balancing purposes, say). "Polarisation" refers to the unwanted condition when the hash algorithm that decides which path a flow/packet takes is not properly distributing flows/packets across links, leading to underutilisation and/or overutilisation of links/routes.