My Access switches trunk ports goes to Err-Disabled periodically.

[nomansafdar]

I have a network with 2 core switches and 15 access switches. 

Now the problem is my access switches trunk ports go to err-disabled mode once a week or once in two weeks. Please, someone, suggest what could be the reason.

[Leo Laohoo]

Ports are never "err-disable" in the core switch?

The ports in "err-disable" are always in the access switch's trunk ports?  

Are the ports in a Trunk port or are they in an Etherchannel?

[marce1000]

 - As stated use show logging command on the involved devices in order to find the reason for err-disable.

 M.

[nomansafdar]

Hello @Leo Laohoo ,
i have found a port in err-disable and when i check the reason it shows me below.

Gi0/48 CONN-CORE-SW2 err-disabled loopback

but the other trunk port on the same switch is up at the same time.

[MHM Cisco World]

One thing make me suspicions,

Mtu one side 9000

Other side 1500

Why this different, can you check this point.

Check if the buffer is full.

[nomansafdar]

@MHM Cisco World what to check in buffer i mean i don't have much idea about that?

[MHM Cisco World]

Hi friend,

mtu 9000 to 1500 this issue here but 

since core support L3 which make fragments hence the collisions happened, you see many collisions happened for different mtu size.

collisions can put the interface in errdisable status.

so first 

match mtu in your network,

check if the collision counter increase any more

this is issue here.

[marce1000]

              >.... what could be the reason

 -> Check the logs when this happens.

 M.

[Georg Pauwen]

Hello,

if your access switches support that feature, globally enable:

3560(config)# errdisable recovery cause all

then check the logs for entries such as the one below (this should tell you the cause of the err-disable):

%PM-4-ERR_RECOVER: Attempting to recover from secure-violation err-disable state on gigabitethernet0/47

[marce1000]

                             >....3560(config)# errdisable recovery cause all

@Georg Pauwen I would not recommend that before the real cause of the problem is known. Otherwise you may end up in chasing the root-problem forever.

 M.

[Georg Pauwen]

@marce1000 The idea of configuring this is to actually find the root cause, as the generated log message should tell you the cause...

[marce1000]

            - The 'initial logs' of the issue will tell the same.

 M.

[Leo Laohoo]

---

@nomansafdar wrote:

Gi0/48 CONN-CORE-SW2 err-disabled loopback

---

Loopback.  Yup, I was afraid this was the trigger.  

Update the IOS of your core switch.  Inspect the cables used.  

[MHM Cisco World]

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCea46385

As Mr.Leo mention the loopback is happened when interface receive the frame it send, BUT please read the bug detail you must find the root of problem. 
STP is run here and must detect loop in network, but I think that collision "frame less than" and MTU mismatch is the root of problem.