Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On Thu, Feb 15, 2018 at 12:56 AM, David Ahern wrote: > On 2/14/18 3:45 PM, Or Gerlitz wrote: >> how the various systems you are dealing with do with traffic that involves >> ipv6 extension headers? what about environments with GRE? in ipv4 GRE >> fabrics are just broken for ECMP, in ipv6 they can fly with flow label but >> will crash again with L4 hash. > If you like your ecmp hash algorithm, you can keep your ecmp hash algorithm. > This gives users a choice; it is not a requirement to move from L3 only > to L4. Further, this makes IPv6 on par with IPv4 with a choice between > L3 and L4 and allows users to decide what works best for them. Looking in the code for tunnels e.g in the vxlan xmit path (but I believe this is the case for other UDP tunnels as well), a call is made to generate the source udp port as the hash of the overlay tuple regardless if we are on v4/v6. Next, when it comes to ipv6, the kernel computes the flow label which effectively takes into account the inner header.
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On 2/14/18 3:45 PM, Or Gerlitz wrote: > On Tue, Feb 13, 2018 at 5:21 PM, David Ahern wrote: >> On 2/13/18 5:42 AM, Ido Schimmel wrote: >>> On Tue, Feb 13, 2018 at 01:03:14PM +0200, Or Gerlitz wrote: On Tue, Feb 13, 2018 at 2:05 AM, David Ahern wrote: > Hardware supports multipath selection using the standard L4 5-tuple > instead of just L3 and the flow label. In addition, some network > operators prefer IPv6 path selection to use the 5-tuple. The HW supports using flow label and AFAIK that is the preferred approach by the community (?) > To that end, add support to IPv6 for multipath hash policy so a question comes up if/what are the disadvantaged to support 5-tuple. E.g Tom was commenting that such DPI is problematic when multiple IPv6 header extensions are used. >> >> Pros and cons to both approaches (L3 only or L4). We (Cumulus Networks) >> use L4 5-tuple hash for both IPv4 and IPv6. When I asked around various >> experts all of them gave me a puzzled look as to why I was asking the >> question. Basically, the unanimous response was of course it is an L4 hash. > > how the various systems you are dealing with do with traffic that involves > ipv6 extension headers? what about environments with GRE? in ipv4 GRE > fabrics are just broken for ECMP, in ipv6 they can fly with flow label but > will crash again with L4 hash. > If you like your ecmp hash algorithm, you can keep your ecmp hash algorithm. This gives users a choice; it is not a requirement to move from L3 only to L4. Further, this makes IPv6 on par with IPv4 with a choice between L3 and L4 and allows users to decide what works best for them.
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On Tue, Feb 13, 2018 at 3:16 PM, Or Gerlitz wrote: > [...] note we have two ends to deal with here (1) generation (2) usage > > E.g if the kernel generates flow label but uses source port we have > inconsistent > environment. Problem is that the generation and usage typically don't happen > on the same network point. David, what's your thinking here? e.g for overly networks environments
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On Tue, Feb 13, 2018 at 5:21 PM, David Ahern wrote: > On 2/13/18 5:42 AM, Ido Schimmel wrote: >> On Tue, Feb 13, 2018 at 01:03:14PM +0200, Or Gerlitz wrote: >>> On Tue, Feb 13, 2018 at 2:05 AM, David Ahern wrote: Hardware supports multipath selection using the standard L4 5-tuple instead of just L3 and the flow label. In addition, some network operators prefer IPv6 path selection to use the 5-tuple. >>> >>> The HW supports using flow label and AFAIK that is the preferred approach >>> by the community (?) >>> To that end, add support to IPv6 for multipath hash policy >>> >>> so a question comes up if/what are the disadvantaged >>> to support 5-tuple. E.g Tom was commenting that such DPI is problematic >>> when multiple IPv6 header extensions are used. > > Pros and cons to both approaches (L3 only or L4). We (Cumulus Networks) > use L4 5-tuple hash for both IPv4 and IPv6. When I asked around various > experts all of them gave me a puzzled look as to why I was asking the > question. Basically, the unanimous response was of course it is an L4 hash. how the various systems you are dealing with do with traffic that involves ipv6 extension headers? what about environments with GRE? in ipv4 GRE fabrics are just broken for ECMP, in ipv6 they can fly with flow label but will crash again with L4 hash.
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On 2/13/18 5:42 AM, Ido Schimmel wrote: > On Tue, Feb 13, 2018 at 01:03:14PM +0200, Or Gerlitz wrote: >> On Tue, Feb 13, 2018 at 2:05 AM, David Ahern wrote: >>> Hardware supports multipath selection using the standard L4 5-tuple >>> instead of just L3 and the flow label. In addition, some network >>> operators prefer IPv6 path selection to use the 5-tuple. >> >> The HW supports using flow label and AFAIK that is the preferred approach >> by the community (?) >> >>> To that end, add support to IPv6 for multipath hash policy >> >> so a question comes up if/what are the disadvantaged >> to support 5-tuple. E.g Tom was commenting that such DPI is problematic >> when multiple IPv6 header extensions are used. Pros and cons to both approaches (L3 only or L4). We (Cumulus Networks) use L4 5-tuple hash for both IPv4 and IPv6. When I asked around various experts all of them gave me a puzzled look as to why I was asking the question. Basically, the unanimous response was of course it is an L4 hash. > > Tom is much more qualified to answer this, but I think the problem is > that the flow label isn't always set. Also, apparently some devices > change the flow label mid flow. See: > > "At Fastly, this hashing is performed by an Ethernet switch ASIC, and to > avoid breakage, the IPv6 hashing function must not include the flow > label. As in IPv4, the hash function includes the source and destination > information in the L3 and L4 headers." > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > https://www.youtube.com/watch?v=b0CRjOpnT7w > https://pc.nanog.org/static/published/meetings/NANOG71/1531/20171003_Jaeggli_Lightning_Talk_Ipv6_v1.pdf >
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On Tue, Feb 13, 2018 at 2:42 PM, Ido Schimmel wrote: > On Tue, Feb 13, 2018 at 01:03:14PM +0200, Or Gerlitz wrote: >> On Tue, Feb 13, 2018 at 2:05 AM, David Ahern wrote: >> > Hardware supports multipath selection using the standard L4 5-tuple >> > instead of just L3 and the flow label. In addition, some network >> > operators prefer IPv6 path selection to use the 5-tuple. >> >> The HW supports using flow label and AFAIK that is the preferred approach >> by the community (?) >> >> > To that end, add support to IPv6 for multipath hash policy >> >> so a question comes up if/what are the disadvantaged >> to support 5-tuple. E.g Tom was commenting that such DPI is problematic >> when multiple IPv6 header extensions are used. > > Tom is much more qualified to answer this, but I think the problem is > that the flow label isn't always set. Also, apparently some devices > change the flow label mid flow. See: OK. But note we have two ends to deal with here (1) generation (2) usage E.g if the kernel generates flow label but uses source port we have inconsistent environment. Problem is that the generation and usage typically don't happen on the same network point.
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On Tue, Feb 13, 2018 at 01:03:14PM +0200, Or Gerlitz wrote: > On Tue, Feb 13, 2018 at 2:05 AM, David Ahern wrote: > > Hardware supports multipath selection using the standard L4 5-tuple > > instead of just L3 and the flow label. In addition, some network > > operators prefer IPv6 path selection to use the 5-tuple. > > The HW supports using flow label and AFAIK that is the preferred approach > by the community (?) > > > To that end, add support to IPv6 for multipath hash policy > > so a question comes up if/what are the disadvantaged > to support 5-tuple. E.g Tom was commenting that such DPI is problematic > when multiple IPv6 header extensions are used. Tom is much more qualified to answer this, but I think the problem is that the flow label isn't always set. Also, apparently some devices change the flow label mid flow. See: "At Fastly, this hashing is performed by an Ethernet switch ASIC, and to avoid breakage, the IPv6 hashing function must not include the flow label. As in IPv4, the hash function includes the source and destination information in the L3 and L4 headers." https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ https://www.youtube.com/watch?v=b0CRjOpnT7w https://pc.nanog.org/static/published/meetings/NANOG71/1531/20171003_Jaeggli_Lightning_Talk_Ipv6_v1.pdf
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
Hi David,
On Mon, Feb 12, 2018 at 04:05:55PM -0800, David Ahern wrote:
> Hardware supports multipath selection using the standard L4 5-tuple
> instead of just L3 and the flow label. In addition, some network
> operators prefer IPv6 path selection to use the 5-tuple. To that end,
> add support to IPv6 for multipath hash policy similar to
> bf4e0a3db97eb ("net: ipv4: add support for ECMP hash policy choice").
> The default is still L3 which covers source and destination addresses
> along with flow label and IPv6 protocol.
>
> A separate sysctl is added for IPv6, allowing IPv4 and IPv6 to use
> different algorithms if desired.
>
> The first 2 patches modify the IPv4 variant so that at the end of the
> patch set the ipv4 and ipv6 implementations are direct parallels.
>
> Patch 3 refactors the existing rt6_multipath_hash in preparation for
> adding the policy option.
>
> Patch 4 renames the existing netevent to have IPv4 in the name so ipv4
> changes can be distinguished from IPv6 if the netevent handler cares.
>
> Patch 5 adds the L4 hash support.
>
> Patch 6 adds the hook for the netevent to the spectrum driver to update
> the ASIC.
>
> Patch 7 removes no longer used code.
Thanks for working on this.
I've yet to review the patches, but I did test them. The good news is
that the offloaded path works as expected. Different flows (random UDP
destination port, zero flowlabel) are hashed to different nexthops. With
the default policy all the flows are hashed to the same nexthop.
However, it seems that the kernel isn't spreading the traffic as
expected and the same nexthop is always hit. I'll look into it later
this week when I have some more time.
Thanks!
Re: [PATCH RFC net-next 0/7] net/ipv6: Add support for path selection using hash of 5-tuple
On Tue, Feb 13, 2018 at 2:05 AM, David Ahern wrote:
> Hardware supports multipath selection using the standard L4 5-tuple
> instead of just L3 and the flow label. In addition, some network
> operators prefer IPv6 path selection to use the 5-tuple.
The HW supports using flow label and AFAIK that is the preferred approach
by the community (?)
> To that end, add support to IPv6 for multipath hash policy
so a question comes up if/what are the disadvantaged
to support 5-tuple. E.g Tom was commenting that such DPI is problematic
when multiple IPv6 header extensions are used.
> similar to bf4e0a3db97eb ("net: ipv4: add support for ECMP hash policy
> choice").
> The default is still L3 which covers source and destination addresses
> along with flow label and IPv6 protocol.
>
> A separate sysctl is added for IPv6, allowing IPv4 and IPv6 to use
> different algorithms if desired.
