NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
802.3ad xmit_hash_policy GS324T
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 s...
What's your real concern here?
There is no dependency on how each side of a LAG does the load balancing, so not really a question of compatibility.
tessus wrote:
- layer2
- layer2+3
- layer3+4
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.
===
In my reading, 1..3 are L2, 4..6 are L3+L4.
Thanks for your reply.
schumaku wrote:What's your real concern here?
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.
schumaku wrote: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.
tessus wrote: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.
tessus wrote: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.
schumaku wrote: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.)
schumaku wrote: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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
