cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1999
Views
5
Helpful
6
Replies

UDLD normal/aggressive with multiple neighbors

Rolf Fischer
Level 9
Level 9

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

2 Accepted Solutions

Accepted Solutions

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. 

View solution in original post

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

  • what exactly does it mean for a link to be "faulty"
  • what exactly is the "extended period of time"

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

View solution in original post

6 Replies 6

acampbell
VIP Alumni
VIP Alumni

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

!

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/25ew/configuration/guide/udld.html#wp1027441

Try again and test.

Regards,
Alex.
Please rate useful posts.

Regards, Alex. Please rate useful posts.

Rolf Fischer
Level 9
Level 9

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

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. 

Rolf Fischer
Level 9
Level 9

Right, it's fiber. Otherwise the global configuration wouldn't play a role.

Sent from Cisco Technical Support Android App

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.

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

  • what exactly does it mean for a link to be "faulty"
  • what exactly is the "extended period of time"

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

Review Cisco Networking for a $25 gift card