Understanding LAG Hash Mode

[bitspiel]

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 utilize if the given packet isn't TCP or UDP? (Think how popular SCTP is nowadays!)

I am asking cause I am trying to reconcile what hash mode parameters I should utilize/configure between my M4100's options and Fedora 33 (specifically the team's runner's configuration for tx_hash) to get a working lacp lag between the two systems.

Thanks for any pointers!

[bitspiel · Accepted solution]

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!

[schumaku]

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.

[bitspiel · Accepted solution]

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!