From: Kenneth Wygand (KWygand@customonline.com)
Date: Thu Jul 08 2004 - 20:49:40 GMT-3
Got it 100% now. Told you, you just had to get past my ignorance.
Thanks a million Scott and Tim! :)
Tim - I'll respond back to your question about the "recursive routing through
tunnel" on the other subject thread... :)
Ken
________________________________
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Thu 7/8/2004 6:09 PM
To: Kenneth Wygand; swm@emanon.com; tycampbell@comcast.net;
ccielab@groupstudy.com
Subject: Re: udld on 3550
Ken,
I think you're making this more complicated than it really is.
Look at the different causes which can put a port in the errdisable state.
( See the CR for the command errdisable detect) NOw, go and look at the
documentation for a few of the particular causes.
For example, if you've configured port security and there's a sescurity
violation, this is what happens:
Security Violations
It is a security violation when one of these situations occurs:
.The maximum number of secure MAC addresses have been added to the address
table, and a station whose MAC address is not in the address table attempts
to access the interface.
.An address learned or configured on one secure interface is seen on another
secure interface in the same VLAN.
You can configure the interface for one of three violation modes, based on
the action to be taken if a violation occurs:
.protect-When the number of secure MAC addresses reaches the limit allowed
on the port, packets with unknown source addresses are dropped until you
remove a sufficient number of secure MAC addresses or increase the number of
maximum allowable addresses. You are not notified that a security violation
has occurred.
----------------------------------------------------------------------------
----Note We do not recommend enabling the protect mode on a trunk port. The protect mode disables learning when any VLAN reaches its maximum limit, even if the port has not reached its maximum limit.
---------------------------------------------------------------------------- ----
.restrict-When the number of secure MAC addresses reaches the limit allowed on the port, packets with unknown source addresses are dropped until you remove a sufficient number of secure MAC addresses or increase the number of maximum allowable addresses. In this mode, you are notified that a security violation has occurred. Specifically, an SNMP trap is sent, a syslog message is logged, and the violation counter increments.
.shutdown-In this mode, a port security violation causes the interface to immediately become error-disabled, and turns off the port LED. It also sends an SNMP trap, logs a syslog message, and increments the violation counter. When a secure port is in the error-disabled state, you can bring it out of this state by entering the errdisable recovery cause psecure-violation global configuration command, or you can manually re-enable it by entering the shutdown and no shutdown interface configuration commands. This is the default mode.
**********************************
Notice the last paragraph above. By default, if there's a security violation the port is errdisabled which has the same effect as the port being shutdown. Keep in mind that the whole concept behind errdisable is to prevent a little problem from becoming a big problem. Imagine what would happen to your network if errdisable didn't disable an uldl problem. This would cause all sorts of STP problems and your net would melt down. With errdisable automatically shuting down the port when this is detected, you have a small problem instead of a network meltdown.
To answer your question more directly, it's not that IOS recognizes a port is in errdisable state. Rather, the IOS recognises a problem and, by default, causes the port to go into the errdisable state. If you manually disable errdisable detect, you prevent the IOS from recognising (or acting to limit) a little problem which can lead to big problems.
HTH
----- Original Message ----- From: "Kenneth Wygand" <KWygand@customonline.com> To: <swm@emanon.com>; "ccie2be" <ccie2be@nyc.rr.com>; <tycampbell@comcast.net>; <ccielab@groupstudy.com> Sent: Thursday, July 08, 2004 5:08 PM Subject: RE: udld on 3550
Hey Scott,
Thank you for your explanation, but due to my ignorance, I'm still confused.
Let's say you have a port f0/1 for which you enable "errdisable detect cause". Does this mean that the IOS will "realize" when this port goes to errdisable state, but if "errdisable detect cause" was disabled, that the IOS wouldn't know the port went to errdisable state?
Then if "errdisable recovery" is enabled for that port, the IOS will take the port out of errdisable state when the configured timer expires, or 300 seconds by default. If "errdisable recovery" is disabled for that port, but "errdisable detect cause" is enabled, the IOS will *know* (detect) the errdisable state, but will not recover from it. Is this correct?
If this is not correct, can you please explain with a real-world example of the possible combinations and how the router views each situation as such?
Thanks! :)
Kenneth E. Wygand Systems Engineer, Project Services CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA, Network+, A+ Custom Computer Specialists, Inc. "The only unattainable goal is the one not attempted." -Anonymous
-----Original Message----- From: Scott Morris [mailto:swm@emanon.com] Sent: Thursday, July 08, 2004 4:56 PM To: Kenneth Wygand; 'ccie2be'; tycampbell@comcast.net; ccielab@groupstudy.com Subject: RE: udld on 3550
The 'detect cause' is setting up WHY you would stick a port into an errdiabled state. You can turn the things off which annoy you.
The 'recovery' part is setting up what to do after you have been annoyed.
So by default, the switch likes to annoy you, but not do anything about it! It's all in the perspective!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP, JNCIP, et al. IPExpert CCIE Program Manager IPExpert Sr. Technical Instructor swm@emanon.com/smorris@ipexpert.net http://www.ipexpert.net
-----Original Message----- From: Kenneth Wygand [mailto:KWygand@customonline.com] Sent: Thursday, July 08, 2004 4:27 PM To: ccie2be; Scott Morris; tycampbell@comcast.net; ccielab@groupstudy.com Subject: RE: udld on 3550
Tim,
This is what I was able to find, which confuses me a bit - what is the difference between "errdisable detect cause" (which is enabled by default) and "errdisable recovery" (which is disabled by default)?
<SNIP> "ERRDISABLE DETECT CAUSE" command --------------------------------- errdisable detect cause Use the errdisable detect cause global configuration command to enable error disable detection for a specific cause or all causes. Use the no form of this command to disable the error disable detection feature.
Defaults Detection is enabled for all causes.
"ERRDISABLE RECOVERY" command --------------------------------- errdisable recovery Use the errdisable recovery global configuration command to configure the recover mechanism variables. Use the no form of this command to return to the default setting.
Defaults Recovery is disabled for all causes.
The default recovery interval is 300 seconds. </SNIP>
Kenneth E. Wygand Systems Engineer, Project Services CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA, Network+, A+ Custom Computer Specialists, Inc. "The only unattainable goal is the one not attempted." -Anonymous
-----Original Message----- From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of ccie2be Sent: Thursday, July 08, 2004 4:09 PM To: Scott Morris; tycampbell@comcast.net; ccielab@groupstudy.com Subject: Re: udld on 3550
Unless I'm mistaken ( which happens often), all causes (there are about a dozen or so) of err-disabled are enabled by default.
Isn't that right?
----- Original Message ----- From: "Scott Morris" <swm@emanon.com> To: <tycampbell@comcast.net>; <ccielab@groupstudy.com> Sent: Thursday, July 08, 2004 2:05 PM Subject: RE: udld on 3550
> You may also want to add "errdisable recovery cause udld" to actually enact > it. The interval is simply the timer. > > > Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP, > JNCIP, et al. > IPExpert CCIE Program Manager > IPExpert Sr. Technical Instructor > swm@emanon.com/smorris@ipexpert.net > http://www.ipexpert.net > > > > -----Original Message----- > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > tycampbell@comcast.net > Sent: Thursday, July 08, 2004 8:47 AM > To: ccielab@groupstudy.com > Subject: udld on 3550 > > I have a task that specifies that both switches should be able to determine > whether a physical link defect prohibits bidirectional communication... > > ok..this is udld > > but after that, it says that they should be able to automatically recover > after an hour.... > > would this be "errdisable recovery interval 3600" ? > > just want to make sure.... > > > Thanks! > >
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:50 GMT-3