How DLDP works

When two devices are connected through an optical fiber or a network cable, enable DLDP to detect unidirectional links to the neighbor. The following illustrates the unidirectional link detection process in two cases:

• Unidirectional links occur before you enable DLDP.

  Figure 7: Cross-connected fibers

As shown in Figure 7, before you enable DLDP, the optical fibers between Device A and Device B are cross-connected. After you enable DLDP, the four ports are all up and in unidirectional state, and they send RecoverProbe packets. Take Port 1 as an example to illustrate the unidirectional link detection process.

1. Port 1 receives the RecoverProbe packet from Port 4, and returns a RecoverEcho packet.

2. Port 4 cannot receive any RecoverEcho packet from Port 1, so Port 4 cannot become the neighbor of Port 1.

3. Port 3 can receive the RecoverEcho packet from Port 1, but Port 3 is not the intended destination, so Port 3 cannot become the neighbor of Port 1.

The same process occurs on the other three ports. The four ports are all in unidirectional state.

• Unidirectional links occur after you enable DLDP.

  Figure 8: Broken fiber

As shown in Figure 8, Device A and Device B are connected through an optical fiber. After you enable DLDP, Port 1 and Port 2 establish the bidirectional neighborship in the following way:

1. Port 1 that is physically up enters the unidirectional state and sends a RecoverProbe packet.

2. After receiving the RecoverProbe packet, Port 2 returns a RecoverEcho packet.

3. After Port 1 receives the RecoverEcho packet, it examines the neighbor information in the packet. If the neighbor information matches the local information, Port 1 establishes the neighborship with Port 2 and transits to bidirectional state. Port 1 then starts the Entry timer and periodically sends Advertisement packets.

4. After Port 2 receives the Advertisement packet, it establishes the Unconfirmed neighborship with Port 1. Port 2 then starts the Echo timer and Probe timer, and periodically sends Probe packets.

5. After receiving the Probe packet, Port 1 returns an Echo packet.

6. After Port 2 receives the Echo packet, it examines the neighbor information in the packet. If the neighbor information matches the local information, the neighbor state of Port 1 becomes Confirmed. Port 2 then transits to bidirectional state, starts the Entry timer, and periodically sends Advertisement packets.

The bidirectional neighborship between Port 1 and Port 2 is now established.

After that, when Port 2's Rx end fails to receive signals, Port 2 is physically down and enters the Inactive state. Because Port 2's Tx end can still send signals to Port 1, Port 1 stays up. After the Entry timer for Port 2 expires, Port 1 starts the Enhanced timer and Echo timer, and sends a probe packet to Port 2. Because Port 1's Tx line is broken, Port 1 cannot receive the Echo packet from Port 2 after the Echo timer expires. Port 1 then enters the unidirectional state, and sends a Disable packet to Port 2. At the same time, Port 1 deletes the neighborship with Port 2, and starts the RecoverProbe timer. Port 2 stays in Inactive state during this process.

When an interface is physically down, but the Tx end of the interface is still operating, DLDP sends a LinkDown packet to inform the peer to delete the relevant neighbor entry.

When multiple devices are connected through a hub, enable DLDP on all interfaces connected to the hub to detect unidirectional links among the neighbors. When no Confirmed neighbor exists, an interface enters the unidirectional state.

As shown in Figure 9, Device A through Device D are connected through a hub, and enabled with DLDP. When Ports 1, 2, and 3 detect that the link to Port 4 fails, they delete the neighborship with Port 4, but stay in bidirectional state.