NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Understanding LAG Hash Mode
Per the user manual, some of the various supported M4100 LAG hash modes can utilize the TCP/UDP port of the packet in the overall hash's calculation. My query is what does the hashing scheme util...
Thanks for the response, but SCTP was just an arbitrary protocol I picked because it isn't UDP nor TCP.
My confusion is/was on what will the hashing algorithm "do" when handed a non UDP/TCP packet?
Apparently, cause I have things working, if the given packet isn't UDP/TCP, the algorithm does not incorporate the protocol part into the the hash.
Consequently, I was able to get my Fedora team based lacp to interoperate with my M4100 switch utilizing a configuration of:
team.config: { "runner": { "name": "lacp", "tx_hash": [ "ip", "tcp", "udp" ], "active": true, "fast_rate": true, "agg_select_policy": "lacp_prio" }, "link_watch": { "name": "ethtool" } }Be sure to set the switch's lacp configuration as not static, hash mode as "6 Src/Dest IP and TCP/UDP Port fields."
Something noteworthy for those finding this post afterthefact: my switch is behind my firewall and is encountering only IPv4 traffic. The aforementioned "ip" tx_hash directive is documented, by Red Hat, as handling both IPv4 and IPv6 values. Given my taffic patterns, I can not attest to a working solution with IPv6 as the Netgear documentation does not overtly state support for IPv6 (see page 198 of the M4100 10.0.2 user manual).
Good luck to all and happy trails!
Wouldn't the proper approach be using SCTP multihoming for each host instead of adding a non-controlled system like port trunking which is outside of the SCTP coverage?
This is what (in my understanding) the Oracle friends do with SCTP, this is what RSerPool does implement on top of SCTP, and what Microsoft does for large scale deployments of SMB (not using SCTP, simply IP) for example.
Thanks for the response, but SCTP was just an arbitrary protocol I picked because it isn't UDP nor TCP.
My confusion is/was on what will the hashing algorithm "do" when handed a non UDP/TCP packet?
Apparently, cause I have things working, if the given packet isn't UDP/TCP, the algorithm does not incorporate the protocol part into the the hash.
Consequently, I was able to get my Fedora team based lacp to interoperate with my M4100 switch utilizing a configuration of:
team.config: {
"runner": {
"name": "lacp",
"tx_hash": [
"ip",
"tcp",
"udp"
],
"active": true,
"fast_rate": true,
"agg_select_policy": "lacp_prio"
},
"link_watch": {
"name": "ethtool"
}
}
Be sure to set the switch's lacp configuration as not static, hash mode as "6 Src/Dest IP and TCP/UDP Port fields."
Something noteworthy for those finding this post afterthefact: my switch is behind my firewall and is encountering only IPv4 traffic. The aforementioned "ip" tx_hash directive is documented, by Red Hat, as handling both IPv4 and IPv6 values. Given my taffic patterns, I can not attest to a working solution with IPv6 as the Netgear documentation does not overtly state support for IPv6 (see page 198 of the M4100 10.0.2 user manual).
Good luck to all and happy trails!
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
