05-23-2013 07:25 AM - edited 03-07-2019 01:31 PM
I have a 2690 stack, with g1/0/49 and g2/0/49 going into port-channel1. g1/0/50 and 2/0/50 going into port-channel2. In each case, one of the interfaces is up; however, the second interface is up/down(suspended). I have verified the configurations on both ends. The 2960 stack is connecting into a 4503 as a distribution layer switch, with L3 liscensing. Prior to placing this into a production environment, this setup worked in the lab, which is a controlled environment. This makes me lean towards the cabling at the site.
2960 switch interface configurations:
interface GigabitEthernet1/0/49
description FRB to DSS1
switchport trunk native vlan 4042
switchport mode trunk
switchport nonegotiate
channel-group 1 mode active
end
interface GigabitEthernet2/0/49
description FBR to DSS1
switchport trunk native vlan 4042
switchport mode trunk
switchport nonegotiate
channel-group 1 mode active
end
interface Port-channel1
description L2 to DSS1
switchport trunk native vlan 4042
switchport mode trunk
switchport nonegotiate
end
4503 switch interface configurations:
interface GigabitEthernet2/6
description trunk to Scrubber Control Bldg
switchport trunk native vlan 4042
switchport trunk allowed vlan 5,300-302,500,600-602,700,701,805,900-902
switchport mode trunk
channel-group 3 mode active
spanning-tree guard root
end
interface GigabitEthernet2/5
description trunk to Scrubber Control Bldg
switchport trunk native vlan 4042
switchport trunk allowed vlan 5,300-302,500,600-602,700,701,805,900-902
switchport mode trunk
channel-group 3 mode active
spanning-tree guard root
end
interface Port-channel3
description L2 to scrubber-control
switchport
switchport trunk native vlan 4042
switchport trunk allowed vlan 5,300-302,500,600-602,700,701,805,900-902
switchport mode trunk
end
Having a second set of eyes may point out some glaring deficiency. Please let me know if anyone can find anything. Again, I am personally leaning towards a cabling issue. The cable guys swear it has to be something in the configuration.
Solved! Go to Solution.
05-23-2013 08:50 AM
I just re-created your scenario and was only able to make it work by blowing away the config and building it back up command by command. Default your physical interfaces and delete the port-channels on both sides. Add the physical interfaces to the port channel and then work inside of po1. Start by setting it up as a trunk, change your native vlan, prune your trunks using allowed vlans, add your guard root, then finally add nonegotiate. Make sure your port-channel stays up the whole time. It will re-negotiate a couple times throughout the process. My configuration did not work when I just slapped in your config. It had to be done in a particular order. Start with the simple stuff, then work your way up.
05-23-2013 07:34 AM
The first thing that jumps out at me is the "switchport nonegotiate" being on one side and not the other. That will typically result in a unidirectional link.
05-23-2013 07:51 AM
In the past, I've had nonegotiate turned up on both ends, but prevented the links from coming up. If I pull it off the downstream switch, it links up fine. That was the reasoning for leaving it off. I've checked the logs for the messages telling me why it went to suspended, but those didn't register in the log, only the protocol down message is there.
05-23-2013 07:55 AM
What is the physical setup of the layer 1 here, fiber, copper, media converters?
Have you tried removing the nonegotiate from both ends?
05-23-2013 08:04 AM
it's Mulimode fiber, 50 micron
I have removed it from both sides, reset the interfaces with no change in status.
05-23-2013 07:46 AM
I would add 'switchport trunk allowed vlan 5,300-302,500,600-602,700,701,805,900-902' on po1 on the 2960, too.
05-23-2013 07:56 AM
I was told to remove it because it was a security violation.
05-23-2013 07:59 AM
Port channels need to have matching native VLANs and allowed VLANs on both sides or you'll end up with suspended members. It has nothing to do with security. Work with whoever told you it was a "security violation" and find out why.
05-23-2013 09:01 AM
The reasoning is if someone was able to get on the network, they would have the vlan structure from the access layer switch. My arguement is if we have someone plugged into our switch and they were able to access it we have bigger problems. So I've added the the "Allowed VLAN" statement on both ends, shut the interfaces, rebuilt the port-channel, and turned the interfaces back up. I then removed the switch nonegotiate, rinsed and repeated and no change.
05-23-2013 08:50 AM
I just re-created your scenario and was only able to make it work by blowing away the config and building it back up command by command. Default your physical interfaces and delete the port-channels on both sides. Add the physical interfaces to the port channel and then work inside of po1. Start by setting it up as a trunk, change your native vlan, prune your trunks using allowed vlans, add your guard root, then finally add nonegotiate. Make sure your port-channel stays up the whole time. It will re-negotiate a couple times throughout the process. My configuration did not work when I just slapped in your config. It had to be done in a particular order. Start with the simple stuff, then work your way up.
05-23-2013 09:56 AM
Thank you!!!
05-23-2013 08:58 AM
Configs much match on both sides . You manually pruned one side by using the vlans allowed command so you must do the same on the other side. Also i would match the spanning tree guard root on both sides.
05-23-2013 09:12 AM
Can't do the root guard on both ends. That won't turn out good. The access layer will automatically block STP from the upstream.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide