07-05-2012 12:10 PM - edited 03-07-2019 07:37 AM
I recently started a netowrking position in Columbus, Ohio and thanks to the storm last Friday our networking equipment turned off after our generator ran out of fuel.
Just about a month before, I setup teaming on our 3560 switches. The 3560s that we have in our server room worked normally when power was restored, but the ones in the networking closets did not. I tried rebooting the 3560s first, but I had no success with that. I had to use a console cable and remove the port channels from those switches and the core (4510) switch before I could get them to work right.
We also had a 4507, 3550s, and a couple 3560s with port channels (BUT the running config was NOT saved yet) that booted properly and were in the networking closets.
We backed up the running-configs that morning and after looking over that, the startup and running configs of the switches now, and even testing with a spare 3560 that we have, I see no reason for this to have happened.
Here is the configs for the port channels that I had:
Switch in Server Room (booted fine):
interface Port-channel16
switchport trunk encapsulation dot1q
switchport mode trunk
interface GigabitEthernet0/49
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 16 mode active
interface GigabitEthernet0/50
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 16 mode active
Switch in Networking Closet (had to remove port channels):
interface Port-channel18
switchport trunk encapsulation dot1q
switchport mode trunk
interface GigabitEthernet0/49
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 18 mode active
interface GigabitEthernet0/50
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 18 mode active
I was thinking that the order in which they booted may have effected it, but my testing only produced a problem when I rebooted the 3560 and waited to plug in the fiber cables until after it was finished booting. It was solved by rebooting the 3560 though.
Any ideas on why I had to remove those port channels before I could get it to work properly?
Thanks!
07-06-2012 02:01 AM
Hello Chris,
there isn't enough information to be able to tell something about this issue.
>> The 3560s that we have in our server room worked normally when power was restored, but the ones in the networking closets did not. I tried rebooting the 3560s first, but I had no success with that. I had to use a console cable and remove the port channels from those switches and the core (4510) switch before I could get them to work right.
However, you have been smart in recovering from the issue.
If you had to use console this means the access layer switches could not be reached from in band management, the LACP bundles were not operational with LACP or LACP neighbor state machine stucked. But this is just a wild guess.
Before removing port channel configuration, have you tried to shut the port channel and then to re-enable it? This could give to LACP a chance to restart.
Hope to help
Giuseppe
07-06-2012 02:07 AM
Why don't you disable DTP?
nonegotiate is the command to do this . If your ports are in auto-auto that could be one of the potential issues.
HTH
Alessio
07-06-2012 09:43 AM
I was thinking about shutting down the port channels, but my boss decided to take over. He thought that unplugging one of the uplinks and rebooting the access switches were a better use of our time. That didn't work by the way.
I still have a lot ot learn with Cisco, so I didn't know about DTP. I researched it and the "switchport nonegotiate" command does look promising. I'll test it out.
Thanks. You've been a big help!
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