setting up a Trunk port from switch to a server

[john-birkett]

I'm trying to connect a Trunk port using fiber from a 3850 switch to a server using fiber.  the following is how i configured the port and the port-channel group:

description ntnx 1-3

switchport trunk allowed vlan xx

switchport mode trunk

switchport  trunk native vlan xx

switchport nonegotiate

channel-group xx mode on

int port-channelxx

description ntnx 1-3

swithchport trunk allowed vlan xx

swithchport mode trunk

switchport trunk native vlan xx

storm-storm-control broadcast level 80.00
storm-control multicast level 80.00

the fiber port is showing suspended and i do the shut no shut commands and nothing happens.

not sure what i did wrong

[Royalty]

Hi @john-birkett,

It is probably because there is a mismatch in configuration between the physical interface(s) and the port-channel (etherchannel) interface. The configuration of both needs to align. Would you please be able to post the full output of 'show run' for the physical interface(s) and the logical port-channel interface?

If you were to issue 'show etherchannel detail' it should show a reason amongst the output on the line "Probable reason"

If there is a misconfiguration in the running-config I would suggest adding the configuration of storm-control to the physical interfaces, or remove storm-control from the port-channel, how ever you desire.

Hope that helps.

[john-birkett]

it doesnt show that.

[Royalty]

Would you please be able to post the full output of 'show run' for the physical interface(s) and the logical port-channel interface, as well as a 'show etherchannel detail'. Also, can I ask what version of IOS-XE version the 3850 is running?

[M02@rt37]

Hello @john-birkett 

On server side, is it LACP 802.3ad configured ?

"mode on" mean forced Etherchannel with no negotiation. That only works if both sides are statically bundling the links and sending frames exactly as expected...

If server is in LACP, do channel-group xx mode active

[Royalty]

It's a good point actually and can agree it is better practice to use a negotiation protocol for the establishment of a LAG/Etherchannel. There's also a high chance the server is configured with LACP.

It may be worth noting that when using forced Etherchannel with "mode on" the switch has no awareness of the remote-end or whether the configuration on the remote-end will work. It would display the physical ports as successfully bundled in the Etherchannel, as opposed to suspended, even with a mismatch of LAG settings between the endpoints of the links.