* Per-flow IPv4 ECMP
@ 2015-09-28 8:57 Matthew Dupre
2015-09-28 13:48 ` roopa
0 siblings, 1 reply; 4+ messages in thread
From: Matthew Dupre @ 2015-09-28 8:57 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
I'm interested in the Linux kernel's support for per-flow IPv4 ECMP (i.e. consistent path selection based on a hash of the connection tuple). I'd been led to believe[1] that this depended on the route cache, which was removed in 3.6.
However, I tested a route with multiple next hops on a 3.10 and 3.13 kernel, and ECMP was per-flow! Obviously I'm pleased that this was the case, but I'd like to understand why this is supported, and whether I can rely on it in future.
Could anyone give me a little clarification on whether this is now supported by some means other than the route cache, and whether that support is intended to be continued?
Thanks,
Matt
[1]: http://bird.network.cz/pipermail/bird-users/2014-February/008873.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Per-flow IPv4 ECMP
2015-09-28 8:57 Per-flow IPv4 ECMP Matthew Dupre
@ 2015-09-28 13:48 ` roopa
2015-09-29 12:35 ` Peter Nørlund
0 siblings, 1 reply; 4+ messages in thread
From: roopa @ 2015-09-28 13:48 UTC (permalink / raw)
To: Matthew Dupre; +Cc: netdev@vger.kernel.org, pch
On 9/28/15, 1:57 AM, Matthew Dupre wrote:
> Hi,
>
> I'm interested in the Linux kernel's support for per-flow IPv4 ECMP (i.e. consistent path selection based on a hash of the connection tuple). I'd been led to believe[1] that this depended on the route cache, which was removed in 3.6.
>
> However, I tested a route with multiple next hops on a 3.10 and 3.13 kernel, and ECMP was per-flow! Obviously I'm pleased that this was the case, but I'd like to understand why this is supported, and whether I can rely on it in future.
>
> Could anyone give me a little clarification on whether this is now supported by some means other than the route cache, and whether that support is intended to be continued?
>
This is being worked on currently by Peter Nørlund
https://lwn.net/Articles/657431/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Per-flow IPv4 ECMP
2015-09-28 13:48 ` roopa
@ 2015-09-29 12:35 ` Peter Nørlund
2016-06-17 18:45 ` Jean He
0 siblings, 1 reply; 4+ messages in thread
From: Peter Nørlund @ 2015-09-29 12:35 UTC (permalink / raw)
To: roopa; +Cc: Matthew Dupre, netdev@vger.kernel.org
On Mon, 28 Sep 2015 06:48:09 -0700
roopa <roopa@cumulusnetworks.com> wrote:
> On 9/28/15, 1:57 AM, Matthew Dupre wrote:
> > Hi,
> >
> > I'm interested in the Linux kernel's support for per-flow IPv4 ECMP
> > (i.e. consistent path selection based on a hash of the connection
> > tuple). I'd been led to believe[1] that this depended on the route
> > cache, which was removed in 3.6.
> >
> > However, I tested a route with multiple next hops on a 3.10 and
> > 3.13 kernel, and ECMP was per-flow! Obviously I'm pleased that
> > this was the case, but I'd like to understand why this is
> > supported, and whether I can rely on it in future.
> >
> > Could anyone give me a little clarification on whether this is now
> > supported by some means other than the route cache, and whether
> > that support is intended to be continued?
> >
> This is being worked on currently by Peter Nørlund
> https://lwn.net/Articles/657431/
Hi,
AFAIK if you create a socket on the machine having the multipath route,
each socket will seemingly be mapped to particular path, and it will
behave as per-flow. But if you use the machine as a router, each packet
is forwarded independently, potentially hitting different paths each
time.
Best Regards
Peter Nørlund
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-06-17 18:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-28 8:57 Per-flow IPv4 ECMP Matthew Dupre
2015-09-28 13:48 ` roopa
2015-09-29 12:35 ` Peter Nørlund
2016-06-17 18:45 ` Jean He
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.