Windows Server Teaming LACP negotiation fails

[Godrick]

TVS682t 4.3.3 & Windows Server 2016

I am trying to directly connect the 10Gb ports and team them. I tried using the directly connected -rr on the qnap side and "simple switch" in the server side. The seemed to work OK (although I didn't test the performance).

I also tried the LACP on the QNAP side (MAC, not MAC+IP), which also (said that it) worked with the "simple switch", but when I set the server mode to LACP it almost immediately says "LACP negotiation failed". (The LACP flavour of teaming works fine for another pair of connections to a Cisco sg350 switch.)

What is the best way of directly connection the server to the switch (mainly for running backups to iscsci Luna on the qnap, file sharing, virtual disk storage, etc)?

[Trexx]

LACP requires an 802.3ad compatible switch, but even then with LACP you will only get 10GbE PER connection/system. LACP will give you greater AGGREGATE throughput from the NAS, but each system is 10GbE.

[schumaku]

What is the best way of directly connection the server to the switch (mainly for running backups to iscsci Luna on the qnap, file sharing, virtual disk storage, etc)?

Hm, switch or a direct connection now?

I also tried the LACP on the QNAP side (MAC, not MAC+IP), which also (said that it) worked with the "simple switch",

The hashing or load balancing method does become active once the links are up ...

but when I set the server mode to LACP it almost immediately says "LACP negotiation failed".

... the LACP handshake does happen immediate on connecting the links res. enabling LACP.

Can't see any advantage for using LACP vs. a switch independent mode.

[Godrick]

Sorry; that should have been directly connecting the server to the qnap (not to the switch).

A bit more playing around and I find that only the directly connected -rr mode seems to work (on the qnap) with simple switch (on the server). The other non lacp modes appear to connect, but copies across the net stall.

It would be good to get lacp going because at least then at least you know that the two sides are talking to each other in a common langyuage.

Yes, you won't get more speed, but you should get more throughput with a thicker pipe.

[schumaku]

It would be good to get lacp going becayhuse at least then at least you know that the two sides are talking to each sResa as asfgdzwwsvzeytvbct other in a common language.

Nope. Same speed capabilities on the "dumb" static trunking modes with policies like RR, XOR, ...