Cisco switch port/trunk port config

[Jeff7181]

Anything wrong with this switchport config? This port should be one of two ports configured as a trunk for a VMware host server. Assume the vlan numbers are correct and the port should be forced to 1000/full.

The part I'm unsure of, is the line that just says "switchport" and the line that says "switchport mode trunk." Should that line "switchport" line not be there if it's a trunk port?

Other interfaces are configured this way for other servers which are not having problems, but we had a host go down, and it appeared to be because one of its trunk ports went offline, and for some reason communication stopped rather than just continuing over the remaining trunk port.

I'm not our network admin, and our network admin says the config hasn't changed, but can't/won't comment on whether this configuration is correct to begin with and I need to rule that out as a possible cause in order to continue troubleshooting.

interface GigabitEthernet11/45
switchport
switchport trunk allowed vlan 21,22,31,500,512
switchport mode trunk
switchport nonegotiate
speed 1000
duplex full
end

 

[TheCrackLing]

Some Cisco devices default to ports to "routed" ports, which means you have to tell them to become a switchport with that command.

Everything looks fine about that, as long as the port is up, and the physical connections are good.

 

[Udgnim]

ask the question on http://www.reddit.com/r/networking

you can input "switchport trunk native vlan #," if the native vlan isn't vlan 1

you can input "show int g11/45" to make sure Layer 1 & 2 are up

can check the VMware host server if its port is also forced to 1000/full and has identical trunk settings to g11/45

can check Spanning Tree Protocol (STP) to see if g11/45 is in a blocked state and then start figuring out why it's blocked and how to unblock it

can check port security but I'm not sure if setting up port security is standard with trunked links.

can shutdown the g11/45 interface then turn it back on with some debug commands (STP related or anything else that might produce good info) running

you should ask your network admin before you do some of this stuff (shut / no shut g11/45 interface, debug commands, & configure native vlan)

just my random guesses. don't really have the background to confidently say.

 

[Jeff7181]

Thanks guys.

 

[Lemieux66]

Did you get this working?

I would suggest removing the speed and duplex commands and make sure the host is configured for auto as well. I find it better to let copper gigabit auto-negotiate.

Troubleshoot layer 1 then 2.

 

[Jeff7181]

Did you get this working?

I would suggest removing the speed and duplex commands and make sure the host is configured for auto as well. I find it better to let copper gigabit auto-negotiate.

Troubleshoot layer 1 then 2.

Someone else is troubleshooting it now. I'm more of a storage guy so I let them take over. I don't know if they'll actually find anything. Hopefully they'll test disconnecting and reconnecting the two trunk ports before putting it back into production.

 

[spidey07]

Two ports? Then the server may have moved it's active connection to the other switchport and it's possible the trunking isn't identical on that one or the native vlan isn't correct. Any NIC redundancy or teaming involved?

 

[Cooky]

The config you posted should work just fine.
Here what I'd do though if I were in charge of this network:
1. implement port-channel to the ESX host if my hardware allows it (stack, VSS, vPC, or what have you)
2. turn on trunk-fast (something like spanning-tree portfast trunk)
This will definitely eliminate the blocking-listening-learning phase if there's SPT reconvergence event.

As far as speed & duplex are concerned, either hard-code or auto-negotiate would work.
RFC for 1GigE calls for auto-negotiate, but I've seen hard-code work just fine.

 

[Comblues]

The config you posted should work just fine.
Here what I'd do though if I were in charge of this network:
1. implement port-channel to the ESX host if my hardware allows it (stack, VSS, vPC, or what have you)
2. turn on trunk-fast (something like spanning-tree portfast trunk)
This will definitely eliminate the blocking-listening-learning phase if there's SPT reconvergence event.

As far as speed & duplex are concerned, either hard-code or auto-negotiate would work.
RFC for 1GigE calls for auto-negotiate, but I've seen hard-code work just fine.

Sound advice.