08-21-2012 01:16 AM - edited 03-07-2019 08:27 AM
Hi,
we're running 4 c4500 Switches at 2 sites connected to each other via Layer-2 crypto boxes and VPLS in a point-to-multipoint configuration which ist completely transparent (it's more or less like connecting them via a Hub - every switch sees the other 3 ones as neighbors).
Our basic configs have udld globally enabled in aggressive mode.
I wanted to disable that for the interfaces (routed ports) to the crypto boxes, because I don't want them in ErrDisabled for 5 minutes if there are connectivity problems in the VPLS-cloud (every switch also had 3 UDLD neighbors because of the P2MP configuration).
In if-config mode I could do this simply with "udld port disable", but I thougt it would be better to run normal mode (not aggressive) to have the chance to use the UDLD show-commands. So I configured "udld port" for the affected interfaces.
interface GigabitEthernet1/2
udld port
!
Parts of the show-command:
! P2MP port to crypto-box
Interface Gi1/2
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
(...)
! standard port with default config
Interface Gi2/1
Port enable administrative configuration setting: Follows device default
Port enable operational state: Enabled / in aggressive mode
(...)
I was very suprised to discover that one interface still goes into ErrDisable state after discovering an UDLD error:
%UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/2, unidirectional link detected
%PM-4-ERR_DISABLE: udld error detected on Gi1/2, putting Gi1/2 in err-disable state
Now I'm puzzled: Did I misunderstand the difference between normal and aggressive mode? Or is something's wrong with my configuration?
IOS version: 12.2(54)SG
Thanks,
Rolf
Solved! Go to Solution.
08-21-2012 11:47 PM
What I don't understand is why it ends up in errdisable state when it's configured in normal mode.
You've configured UDLD on BOTH sides right?
If the answer is yes, then I'd recommend you enable link logging "logging enable link" on the interface to determine if you have a potential issue with this link.
By the way, this link is fibre optic, right?
If not, UDLD is good if you have fibre. I wouldn't recommend UDLD on a copper link.
08-24-2012 01:17 AM
Hello Rolf,
I have not originally participated in this thread as the behavior was unclear also to me. I know the RFC you are quoting and I am aware of the statement that the normal mode will shut down the link after "it is faulty for an extended period of time". However, there is no clear definition of
Moreover, this statement seems to be in slight conflict with the description of the normal mode in the following document:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009477b.shtml
It specifically states: "In normal mode, if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state."
Now what's the truth?
Best regards,
Peter
08-21-2012 05:39 AM
Rolf,
If your interface G2/1 is using fibre then :-
!
interface g2/1
udld disable
!
If your interface G2/1 is using copper then :-
!
interface g2/1
no udld enable
!
Try again and test.
Regards,
Alex.
Please rate useful posts.
08-21-2012 09:11 AM
Alex,
thanks for your reply.
How go disable it on a per-port basis I know.
What I don't understand is why it ends up in errdisable state when it's configured in normal mode.
Sent from Cisco Technical Support Android App
08-21-2012 11:47 PM
What I don't understand is why it ends up in errdisable state when it's configured in normal mode.
You've configured UDLD on BOTH sides right?
If the answer is yes, then I'd recommend you enable link logging "logging enable link" on the interface to determine if you have a potential issue with this link.
By the way, this link is fibre optic, right?
If not, UDLD is good if you have fibre. I wouldn't recommend UDLD on a copper link.
08-22-2012 01:22 AM
Right, it's fiber. Otherwise the global configuration wouldn't play a role.
Sent from Cisco Technical Support Android App
08-24-2012 12:40 AM
After some additional reading I've to admit that I really misunderstood the difference of normal mode and aggressive mode. I thought shutting down happens only in a.m., but RFC 5171 says:
".... In other words, normal mode will shut down a port only if it can explicitly determine that the associated link is faulty for an extended period of time."
Thanks again for the replies.
08-24-2012 01:17 AM
Hello Rolf,
I have not originally participated in this thread as the behavior was unclear also to me. I know the RFC you are quoting and I am aware of the statement that the normal mode will shut down the link after "it is faulty for an extended period of time". However, there is no clear definition of
Moreover, this statement seems to be in slight conflict with the description of the normal mode in the following document:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009477b.shtml
It specifically states: "In normal mode, if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state."
Now what's the truth?
Best regards,
Peter
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