05-30-2013 12:55 AM - edited 03-07-2019 01:38 PM
Hi All
I have recently iinherited a new network. I currently have a core switch which is 2 x 3750's stacked. I have 16 2960 switches that are connected to
the core. There are 2 uplink from each switch to the core. 1 link going into one of the switches in the stack and another up link going in to the other.
All but 2 switches have been grouped in to port channel groups. I went to group the links on switch 13 on the core side. I created the port-channel 13
I then added the links channel-group 13 mode on.
On doing this the network went crazyy and the Core started to see all the portchannels as down down, and their physical links. Upon doing this I reversed
my config changes, and I got all the switches back up by power cyclying them.
Please could someone shed some light on this. I have atched the Core config. Is this a STP or security issue ?
Many thanks
05-30-2013 01:08 AM
Hello
Do the access layer switches have any other interconnects with other switches apart from the core?
res
Paul
Please don't forget to rate any posts that have been helpful.
Thanks.
05-30-2013 01:28 AM
Hi James, I quickly skimmed through the config and want to highlight a couple of things...
Some of the portchannels are configured like this
interface Port-channel4
switchport access vlan 500
switchport trunk encapsulation dot1q
switchport mode trunk
Maybe this is due to historical reasons but I would take out the switchport access vlan 500 command. If its meant to be the native vlan then please correct this via 'switchport trunk native vlan x' instead.
I also noticed the 'channel-group x mode on'
I would recommend using a protocol to negotiate the etherchannel, perhaps LACP or PAGP. So kindly investigate this, it would prevent loops etc... whereas with mode on - its an etherchannel unconditionally and can easily create loops of all sorts.
This config on certain ports may be a recipe for disaster and most definitely
interface GigabitEthernet2/0/17
switchport access vlan 500
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 12 mode on
spanning-tree portfast
This is what happens when enabling spanning-tree portfast under this interface:
SW1(config-if)# spann portfast
%Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc… to this interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet0/1 but will only
have effect when the interface is in a non-trunking mode.
Since in the configuration on certain ports this is the case and probably an increased chance of creating a bridging loop. The interface is configured as an access port and trunk the same time, along with portfast.
As to the reason why all etherchannels started going down, maybe because of such loop, its very difficult to tell as it could have been a wide range of factors. (did you get any logs for when this happened?) might give us some clues.
I will take a guess to say that it may have been a loop of some sort or perhaps caused several interfaces to go to err-disable state.
If i was in your situation I would take some time to correct each and every portchannel, I would just have a basic simple configuration like this (using LACP as it is standardized) e.g.
interface portchannel 1
description *** EXAMPLE *** Po1 ***
switch trunk encapsulation dot1q
switchport trunk native vlan 500
switchport mode trunk
!
interface GigabitEthernet 1/0/1
switch trunk encapsulation dot1q
switchport trunk native vlan 500
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet 1/0/2
switch trunk encapsulation dot1q
switchport trunk native vlan 500
switchport mode trunk
channel-group 1 mode active
Hope this helps
Please rate useful posts & remember to mark any solved questions as answered. Thank you.
05-30-2013 04:28 AM
I would take some time to discover the L2 topology.look at the CAM tables and CDP neighbors to verify the access switches are not interconnected. I would take that opportunity to see if any other 'rogue' switches are connected to the access layer by some users.
Sent from Cisco Technical Support iPad App
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