09-22-2017 12:35 AM - edited 03-08-2019 12:08 PM
Lately we have been having problems with a port that is part of a port-channel that puts itself in suspend.
now that part isn't really the problem as we know the reason why it does that, the problem is that we have to do some extra work when the issues that put the port in suspend are over and the port rejoins the port channel.
so my question is, can a port auto recover when it's put itself in suspend state, or does the port need to be manually be put in shut/no shut?
Solved! Go to Solution.
09-22-2017 12:43 AM
Hi
check your errdisable recovery you can set it to recover itself using that like below options on my switch
(config)#errdisable ?
detect Error disable detection
flap-setting Error disable flap detection setting
recovery Error disable recovery
#sh errdisable recovery
Recovery Status Timer Status
--------------- ------------
udld Disabled
bpduguard Disabled
security-violation Disabled
channel-misconfig Disabled
vmps Disabled
pagp-flap Disabled
dtp-flap Disabled
link-flap Disabled
l2ptguard Disabled
psecure-violation Disabled
gbic-invalid Disabled
dhcp-rate-limit Disabled
mac-limit Disabled
unicast-flood Disabled
storm-control Disabled
arp-inspection Disabled
loopback Disabled
link-monitor-failure Disabled
oam-remote-failure critical-event Disabled
oam-remote-failure dying-gasp Disabled
oam-remote-failure link-fault Disabled
dot1ad-incomp-etype Not supported
dot1ad-incomp-tunnel Not supported
mvrp Not supported
transceiver-incomp Not supported
packet-buffer Not supported
inline-power Not supported
09-22-2017 12:43 AM
Hi
check your errdisable recovery you can set it to recover itself using that like below options on my switch
(config)#errdisable ?
detect Error disable detection
flap-setting Error disable flap detection setting
recovery Error disable recovery
#sh errdisable recovery
Recovery Status Timer Status
--------------- ------------
udld Disabled
bpduguard Disabled
security-violation Disabled
channel-misconfig Disabled
vmps Disabled
pagp-flap Disabled
dtp-flap Disabled
link-flap Disabled
l2ptguard Disabled
psecure-violation Disabled
gbic-invalid Disabled
dhcp-rate-limit Disabled
mac-limit Disabled
unicast-flood Disabled
storm-control Disabled
arp-inspection Disabled
loopback Disabled
link-monitor-failure Disabled
oam-remote-failure critical-event Disabled
oam-remote-failure dying-gasp Disabled
oam-remote-failure link-fault Disabled
dot1ad-incomp-etype Not supported
dot1ad-incomp-tunnel Not supported
mvrp Not supported
transceiver-incomp Not supported
packet-buffer Not supported
inline-power Not supported
09-22-2017 01:04 AM
awesome, I'll do some research into this!
But this I can work with.
Thx for the feedback!
09-22-2017 01:07 AM
09-22-2017 04:46 PM - edited 09-22-2017 04:49 PM
I have seen through my own eyes how someone enabled UDLD and also auto-recovery of this kind of fault on a 6807 running BGP. The link went into UDLD error-disabled state a few times and the chassis crashed.
Use error-disable recovery with caution and care. Exercise common sense is mandatory.
NOTE:
Error-disable state is not an enemy but your friend. This tells a network admin that something is definitely wrong. If the link(s) go into this state, one must investigate and fix it. There is no reason why link(s) would go into error-disable for no apparent reason.
09-24-2017 11:48 PM
Update:
A port can and will recover from an suspend state without human intervention.
The problem was our carrier damaged a cable that was part of a port channel.
As soon as they fixed it, it pulled itself out of suspend, this was not due to UDLD, but due to LACP.
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