Seeing STP in forwarding state isn't necessarily a cause for concern. STP will start running when the port comes up (e.g. after the errdisable recovery timeout) but will wait for an incoming BPDU before entering forwarding state.
UDLD frames are only sent every 15 seconds by default, so may lag behind STP status in normal running. This is assuming that you haven't set STP portfast on that port. Portfast would cause the port to transition to forwarding state without waiting for an incoming BPDU, which would indeed cause undesired traffic flows. To be honest I'm not all that keen on UDLD (it can lead to interesting failure modes if an STP-participating switch doesn't also run UDLD) but if GigE autonegotiate isn't good enough for your purposes you may be forced to use UDLD. -----Original Message----- From: cisco-nsp [mailto:[email protected]] On Behalf Of Victor Sudakov Sent: 17 July 2014 09:15 To: [email protected] Subject: [c-nsp] UDLD enabling port prematurely? Colleagues, I have several pairs of Catalyst 3560E switches connected via third party MUXes (Avara ENT100). When the actual physical medium goes down, the MUXes do not shutdown their Ethernet interfaces (i.e. they have no "link poisoning"). So I need some sort of point-to-point L2 link fault management between the switches. Is UDLD suitable for this purpose? I have experimented a bit with "udld port aggressive" and have found out the following strange thing. When the physical link goes down, UDLD detects this condition and shuts the switch interface down. However, after several minutes, the interface goes up again with "%PM-4-ERR_RECOVER: Attempting to recover from udld err-disable state on Gi0/17". The interface is up even though "Current bidirectional state: Unknown", and seems to be in the STP forwarding state. This does not look good. If a broadcast frame arrives to this port before a BPDU does, there will be a storm and a lot of MAC flapping. Is there a way to keep the port from forwarding traffic until the UDLD state is Bidirectional ? Thanks a lot for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:[email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ “To our Members we're the 4th Emergency Service " This electronic message contains information from AA Corporation Limited or from a member, or members, of its group of companies which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, please delete this e-mail immediately. The contents of this e-mail must not be disclosed or copied without the sender's consent. We cannot accept any responsibility for viruses, so please scan all attachments. No changes to Terms and Conditions of trade can be accepted through e-mail communication. All changes to Terms and Conditions must be in writing evidenced by a director of the company and in hard copy format. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company. The company does not take any responsibility for the views of the author. ” _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
