I tested in the lab the aggressive UDLD on copper interfaces on Catalyst 3560 . To test unidirectional link on copper interfaces I didn't connect them directly, as suggested in this forum .I implemented instead a daisy-chain through two different solutions: in the first one I put one third-party switch in the middle, in the second one I put 2x ME-3750 in the middle, and I configured 802.1Q and UDLD tunnelling. In both cases aggressive UDLD seems to work properly: after breaking down the link from one 3560, the other 3560 puts the port in an err-disabled state after the expiration time. The only problem is the recovery procedure: If I issue the "udld reset" on the 3560 that had noticed the failure BEFORE or WITHOUT plugging the cable again on the other 3560, the interface comes back immediately to up state without noticing any error condition, I expected the port would have gone to err-disabled state again because the neighbor is not present and unreachable. Any sugegstion?
I expected the port would have gone to err-disabled state again because the neighbor is not present and unreachable. Any sugegstion?
If you type show udld and refer to the port, you will notice the lack of neighbor information on the output. If there isn't any neighbor that is running UDLD, UDLD won't send any echo and it won't errdisable the port.
The errdisable condition only occurs when there is a neighbor listed under the UDLD output and it's not responding.
BTW, you don't need to type 'udld reset'. You can configure errdisable recovery for UDLD.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...