Unidirectional Link

    Unidirectional Link


    Unidirectional links are the links for which either one of the transmission path has failed but not both. Cisco implementations have different mechanisms to detect unidirectional links and avoided the impact caused by them. The mechanisms are as below

      • UDLD – Unidirectional link detection, a Cisco preparatory L2 messaging protocol.
      • STP loop Guard –
      • Bridge assurance –
      • RSTP/MST dispute mechanism.



    Unidirectional Link  Detection (UDLD)


        UDLD is cisco proprietary Layer 2 messaging protocol (RFC 5171) designed to detect unidirectional links and prevent the impact. It serves an echo mechanism between the pair of devices by sending UDLD messages. Devices on both ends of the link must support UDLD in order for the protocol to successfully identify unidirectional links and for a prompt corrective action to be taken. UDLD can run on both fiber optic and twisted pair copper links.


    2.1.b (ii) -- UDLD.jpgFor UDLD packet capture follow Click Here



    Why UDLD needed:

    An unidirectional link is a condition on switch ports where a link remains in the up state but the interface is not passing traffic. UDLD is a lightweight protocol that can be used to detect and disable one-way connections before they create dangerous situations such as Spanning Tree loops or other protocol malfunctions.

        • A typical occurrence of this happens on GBIC interfaces or Small Form-Factor Pluggable (SFP) modules malformed where either RX or TX not working , or two ends connected via some dumb devices making port state up up.
        • When there is unidirectional link, one end of the link (the one in blocking state) will not receive BPDUs and when BPDUs are not received on the blocked ports, they will transition through the STP states and start forwarding – when they shouldn’t. This can eventually cause instability on the network or bridging loops to occur.


    What UDLD Do:

    If UDLD detects and declares a port as unidirectional link, it will err-disable the port.

        • UDLD uses echoing mechanism to detect the unidirectional links.
        • UDLD actively monitors a port to see if the link is truly bidirectional.
        • UDLD keeps the acquired information of the neighbors in a cache table.
        • UDLD sends "hello" packets (also called "advertisements" or "probes") at regular interval (15 seconds) on every active interface to keep each device informed about its neighbors.  When a hello message is received, it is cached and kept in memory at most for a defined time interval, called "holdtime" or "time-to-live" or “timeout value”, after which the cache entry is considered stale and is aged out.
        • If a new hello message is received when a correspondent old cache entry has not been aged out yet, then the old entry is dropped and is replaced by the new one with a reset time-to-live timer.
        • If UDLD messages suddenly ceased arriving, switch will try to reconnect its neighbor eight times and if this attempt fails take actions based on UDLD operation mode.
        • Whenever an interface gets disabled and UDLD is running or UDLD is disabled on an interface, or the device is reset, all existing cache entries for the interfaces affected by the configuration change are cleared, and UDLD sends at least one message to inform the neighbors to flush the part of their caches.  This mechanism is meant to keep the caches coherent on all the connected devices.

    How UDLD detect unidirectional links:

    Using UDLD messages each switch advertises its identity and port identifier pair as the message originator and hold-down timer and list of all neighboring switch and port pairs heard on the same port. Using these information UDLD protocol determines a port as unidirectional if below conditions or symptoms explicitly meet and will err-disable the port irrespective to the mode of operation.


      1. Both UDLD enabled switch ports discover each other by exchanging hello messages sent to well-known MAC address 01:00:0C:CC:CC:CC. Each switch sends its own device ID (normally device Serial number) along with the originator port ID and timeout value to its peer. Additionally, the receiving switch echoes back the ID/port pair of its neighbor. If the sending switch does not hear back the exact id/pair combination on sending port from neighbor peer within the holdtime expires, the port is suspected to be unidirectional.
      2. If UDLD message arriving from a neighbor contains the same ID/port originator pair as used by receiving switch this indicates a self-looped port and marked as unidirectional.
      3. If a switch port has detected a single neighbor bit that neighbor’s UDLD message contains more than one ID/port pair in list of detected neighbors , this can happen in shared media and an issue in UDLD’s capability to provide full visibility between all connected devices ( as UDLD meant to be work on point to point connections).


    Note: - Sudden loss of UDLD messages arriving on a port is not the explicit UDLD detection condition; this is just a presumption that link might unidirectional and in this respects the two UDLD protocol operational/functional modes Normal and Aggressive differs on the reactive action taken.



    UDLD operational/functional modes:

    Normal Mode:-  In normal mode, unidirectional link detection process is always based on information received in UDLD messages from the neighbor: whether it's the information about the proper neighbor identifications or the information about the absence of such proper identifications.  Hence normal mode determinations are always based on gleaned information from messages so this is "event-based".

      • If UDLD identifies that unidirectional symptoms as stated above explicitly matched, then it will put switch-port in err-disabled state.


      • If normal UDLD mode is active on switch :--In condition of sudden cease of UDLD messages arriving on a port from neighbor, switch will
        • Try to reconnect its neighbor eight times and if this attempt also fails UDLD take NO ACTION upon failure , i.e. A port which stopped receiving UDLD message will remain up
        • Generate a syslog message that message loss from neighbor.

    Aggressive Mode:-  In aggressive mode loss of UDLD messages from neighbor assumed to be a meaningful network event in itself and are a symptom of a serious connectivity problem.Because this type of detection can be event-less, and lack of information cannot always be associated to an actual malfunction of the link,this mode is optional and is recommended only in certain scenarios (typically only on point-to-point links where no communication failure between two neighbors is admissible).

      • If UDLD identifies that unidirectional symptoms as stated above explicitly matched, then it will put switch-port in err-disabled state.


      • If aggressive UDLD mode is active on switch :--In condition of sudden cease of UDLD messages arriving on a port  from neighbor, switch will
        • Try to reconnect its neighbor eight times and if this attempt also fails UDLD will put that port in err-disabled state.


    Note: - The difference between normal and aggressive mode lies on the action taken when there is sudden loss of incoming UDLD messages from neighbor switch; that is if the explicit symptoms match in both mode port is err-disabled and n case of implicit symptom only aggressive mode err-disables the port.



    UDLD timers:

      • During the initial peer detection phase messages are exchanged at the maximum possible rate of one (1) per second.
      • In case if the link is not deemed to be other than bidirectional, switch tries to resynchronize the port and send messages in every 7 seconds.
      • In case if the link is determined as bidirectional (i.e. steady-state transmissions) messages are sent every user-configurable value between 7 to 90 seconds. The default implementation is 15 seconds.


    Note: - UDLD is not supposed to be used on ports connected to untrusted devices or incapable devices; hence, it should be disabled on such ports.



    UDLD Configuration:


    • UDLD is disabled by default.
    • It can be configured globally (enables UDLD only on fiber-optic ports) or per-interface basis.


    Enable UDLD Globally (only enables on fiber-optic interfaces)

    SW(config)#udld {enable | aggressive} | message-time seconds}


    enable - Enables UDLD in normal mode; default mode


    aggressive - Enables UDLD in aggressive mode.


    message-timer - 7 to 90 seconds. Period of time between probe messages on ports that are in advertisement phase and are determined to be bidirectional.


    Enable UDLD per-interface basis

    SW(config-if)#udld port [aggressive]


    aggressive - Enables UDLD in aggressive mod, if aggressive not defined enables normal mode. Overrides global config for fiber interface



    Automatic port state recovery configuration from UDLD action:

    A time-based recovery mechanism can be configured if a port has been put into err-disabled state by UDLD.


    SW(config)#errdisable recovery cause udld

    enables recovery timer

    SW(config)#errdisable recovery interval interval

    specifies recovery timer


    Note: - Port is simply enabled and no further UDLD processing is done on that port until neighbor has returned and port has changed to bidirectional mode at least once.

    Manual port state recovery from UDLD action:


    SW#udld reset

    Manually reset all interfaces shut down by UDLD.

    SW(config-if)#no shutdown

    Manually reset by making port down and Up.


    Verification Command:


    SW#show udld

    Verify UDLD entries for all interfaces

    SW#show udld interface-id

    Verify UDLD entry for specific interfaces




    ~~~~~ ***** ~~~~~


    Any suggestions to improve the content of this document are most most welcome ...



    Deben Bhattarai

    BenStdyNet - The Quick PICK | Network All the Way