I've just bought a GS324T and while waiting for the delivery, I've been reading up on a few things in the manual. Unfortunately the manual doesn't tell me, what I want to know.
I wasn't able to see which xmit_hash_policy the switch supports for IEEE 802.3ad LACP. The static settings suggest that all of them are supported, even though only the single layer options are listed.
So which of the following are really supported?
layer2
layer2+3
layer3+4
Model: GS324T|NETGEAR® S350 Series 24-Port Gigabit Ethernet Smart Managed Pro Switch with 2 SFP Ports
This reads like some other industry standard switch LACP load balancing distribution for the traffic flowing out over the LAG.
This is what the S350 Series offers:
===
From the Hash Mode menu, select the load-balancing mode for a port channel (LAG):
1 Src MAC, VLAN, EType, incoming port. This mode uses the source MAC address, VLAN, EtherType, and incoming port that are associated with the packet.
2 Dest MAC, VLAN, EType, incoming port. This mode uses the destination MAC address, VLAN, EtherType, and incoming port that are associated with the packet.
3 Src/Dest MAC, VLAN, EType, incoming port. This mode uses the source and destination MAC addresses, VLAN, EtherType, and incoming port that are associated with the packet. This is the default mode.
4 Src IP and Src TCP/UDP Port Fields. This mode uses the source IP address and source TCP or UDP port value that are associated with the packet.
5 Dest IP and Dest TCP/UDP Port Fields. This mode uses the destination IP address and destination TCP or UDP port value that are associated with the packet.
6 Src/Dest IP and TCP/UDP Port Fields. This mode uses the source and destination IP addresses and source and destination TCP or UDP port values that are associated with the packet.
Note: The switch balances traffic on a port channel (LAG) by selecting one of the links in the channel over which packets must be transmitted. The switch selects the link by creating a binary pattern from selected fields in a packet and associating that pattern with a particular link.
There is no dependency on how each side of a LAG does the load balancing, so not really a question of compatibility.
Actually there is when using LACP 802.ad. I must not specify a transmit hash policy that is not supported by the switch. If I specify layer 2+3, but the switch is only a layer 2 switch, there will be problems.
It is mentioned in several guides and setup instructions when setting up LAG via LACP. A while back I came across this one (item 5) when investigating LAG on QNAP. Yes, I know, QNAP is not reallly the pinnacle of trustworthiness, but this is just one example and there are other publications and articles.
This reads like some other industry standard switch LACP load balancing distribution for the traffic flowing out over the LAG.
I'm not entirely sure I follow. Usually you connect a computer to a switch and the computer's OS uses bonding drivers to setup link aggregation. In Linux the bonding driver supports different modes. One of those modes is IEEE 802.3ad Dynamic link aggregation (802.3ad, LACP). LACP itself supports the load balancing policies I have mentioned earlier. (Actually 2 more modes are supported since this commit in the Linux kernel in 2013.) Using a load balancing policy that is not supported by the switch is a big no-no.
I'm not sure, if you can call IEEE 802.3ad LACP "some other industry standard".
While I appreciate your answer, you've pasted the static modes I also mentioned earlier. And you've interpreted them the same way I did.
Here's the thing: the switch I'm talking about (GS324T) is capabable of L2/L2+/L3 according to the documentation and specs, yet it also supports L4 for LACP? There's a discrepancy I can't reconcile. That's why I asked my question in the first place.
The hash does define on how the "same" type of traffic (as per the config selection options) is assigned _to_ the LAG outgoing port member. There is nothing specific required on the peer switch and it's LAG config.
Look, when wearing the QNAP hat (I have probably one of the largest external QNAP lab up here), I'm doing the same like the QNAP documentation people do - I try not to push people to configure things which might not work at the end of the day. The point is that (according to my knowledge and experience), any switch with an 802.3ad LACP LAG config will handle the packets coming over the individual LAG link members. There is no magic or whatever added ... it continues with "just" plain L2 - and no "matching" config must be set on the "receiving" LAG side.
Usually you connect a computer to a switch and the computer's OS uses bonding drivers to setup link aggregation. In Linux the bonding driver supports different modes. One of those modes is IEEE 802.3ad Dynamic link aggregation (802.3ad, LACP). LACP itself supports the load balancing policies I have mentioned earlier. (Actually 2 more modes are supported since this commit in the Linux kernel in 2013.) Using a load balancing policy that is not supported by the switch is a big no-no.
Afraid, you seem to wildly mixing up link aggregation modes (which requires to be the same on both peers on the aggregated link) with the hash mode the switch or host does use internally to distribute or keep similar kinds of traffic on the same port.
Here's the thing: the switch I'm talking about (GS324T) is capabable of L2/L2+/L3 according to the documentation and specs, yet it also supports L4 for LACP? There's a discrepancy I can't reconcile. That's why I asked my question in the first place.
Well, according your "logic" already L3 is off the GS324T capabilities - the ability to allow quick path IP4 inter-VLAN switched routing does not make it a L3 switch ... in my view, these S350 Switch series L2+ switches, where the "+" makes up of certain L2/L3/L4 features like IPv4 inter-VLAN routing, L2/L3/L4 Access control lists, and then again L2/L3/L4 hash policies for LACP LAGs. This is it.
Afraid, you seem to wildly mixing up link aggregation modes (which requires to be the same on both peers on the aggregated link) with the hash mode the switch or host does use internally to distribute or keep similar kinds of traffic on the same port.
I don't mix up anything. I can only know what I've read in articles, books, and what I learned back in university. And when articles say that the switch must support the transmit hash policy, how should I know that all these articles are wrong? (I pasted the link to the QNAP article as an example.)
Well, according your "logic" already L3 is off the GS324T capabilities - the ability to allow quick path IP4 inter-VLAN switched routing does not make it a L3 switch ... in my view, these S350 Switch series L2+ switches, where the "+" makes up of certain L2/L3/L4 features like IPv4 inter-VLAN routing, L2/L3/L4 Access control lists, and then again L2/L3/L4 hash policies for LACP LAGs. This is it.
Once again, I can only gather information from documentation on that switch. e.g. The website states that the switch can do 256 VLANs and has no inter-VLAN switched routing. The website does not even say anything about L2/L3/L4. The datasheet on the other side mentions L2/L3/L4 when it comes to ACLs and QOS only. It also says 64 VLANs. It does not say anything about inter-vlan routing.
So what is it? 256 or 64 VLANs? Inter-VLAN switched routing is not possible according to the website, but you say it is. There's conflicting info all over the place. I am not trying to be difficult here, but a few things just don't add up.
One more thing. You never set a transmit hash policy on a switch, when you use dynamic LACP. This is only done on the machine that is connected to that switch. You only choose a transmit hash policy on the switch when using static LACP on the switch.
No idea, have no switches from this family at hand - I'm not Netgear. Something is inconsistent, probably later spec change which have not made it to the data sheet?
You never set a transmit hash policy on a switch, when you use dynamic LACP. This is only done on the machine that is connected to that switch. You only choose a transmit hash policy on the switch when using static LACP on the switch.
From wally brain ... a dynamic LACP LAG does classically use an XOR MAC hash, just like the XOR static LAG known from Linux hosts (among others). There is nothing wrong implementing an additional L2+L3 or a L3+L4 policy on top on either a host, or on a switch, for either static or dynamic LACP LAG - as it's applied to the outgoing traffic
Well, I can, and I do .... It's the host as well as the network admin's freedom to configure each LAG in each direction with a policy in place the way he think it's the best where I can. Being on a server, on a NAS, on a host, or on a LAG interconnecting two switches.
