[j-nsp] Verifying Juniper ECMP

[ryanL]

i've got 6 machines advertising the same /32 at the moment, and bgp is
typically quite stable in this setup.

sorry, i somehow misinterpreted (perhaps too hopefully) that the addition
or removal of _flows_ would potentially cause a rehash, not just the
addition or removal of a physical or logical path. back to the drawing
board i go.


On Sat, Aug 9, 2014 at 9:23 AM, Chris Woodfield <rekoil at semihuman.com>
wrote:

> I've learned that the EX platform only allows 8 equal-cost routes. How
> many proxies are in your setup?
>
> The behavior you're describing should only happen when one of the ECMP
> routes is either withdrawn or a new route is advertised.
>
> Followup question: is the flow-hashing algorithm on the EX platform a
> consistent hash (ring hash)? If so, only flows that were being mapped to
> the withdrawn route, or that would be hashed to the new route, would be
> affected. If it's not a consistent hash, then all flows would be re-mapped
> to new routes whenever there's a change in the available next-hops.
>
> -C
>
> On Aug 9, 2014, at 9:00 AM, ryanL <ryan.landry at gmail.com> wrote:
>
> oh man... this might be the answer to a long standing problem i've been
> having with the EX4500's at my core. they do BGP to a bunch of proxy
> machines (exabgp) that advertise the same /32 (as a VIP). once every so
> often (becoming more often as traffic grows), a TCP packet is forwarded by
> the EX to one of the machines which has no knowledge of the original flow.
> that machine of course sends back a RST and breaks the whole flow.
>
> i've done exhaustive packet captures for juniper on this, thinking that
> somehow the EX was actually duplicating a packet incorrectly out one
> interface. but this stateless ECMP rehash for all flows every time a new
> flow is added or taken away makes a lot more sense to me, and also really
> sucks if true.
>
> case 2014-0123-0781, if anyone at juniper is listening. that case is
> _still_ open.
>
>
>