Network Device Self-Recovery via Neighbor LLDP Relay

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In cloud network management, network devices often lose connection to the management device due to configuration changes, leading to unintentional disconnection and requiring physical intervention for re-establishment, resulting in downtime and increased administrator intervention.

Innovation Solution

A method where a network device with an active connection to a management device can use a neighboring device to restore connection by sending and receiving Link Layer Discovery Protocol (LLDP) messages and configuration changes, allowing the device to re-establish communication without requiring a fixed IP address or altering existing connectivity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If network devices are configured remotely via cloud network management, then administrator accessibility and management flexibility are improved, but connection stability and reliability deteriorate due to unintentional disconnections requiring physical intervention

Engineering Contradiction:

Improveadministrator accessibilityVSAvoidconnection stability

Core Design Contradiction:

Ease of operationVSReliability

Solution Approach 1:

A neighboring network device acts as an intermediary to relay LLDP messages and configuration data between the isolated device and the management device. When a device loses connection to the management device, the neighboring device forwards management traffic through its active connection, enabling remote reconfiguration without physical intervention and restoring connectivity while maintaining cloud management accessibility

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs preliminary configuration actions by pre-establishing LLDP message exchange mechanisms and neighboring device relationships before connectivity failures occur. The neighboring device is pre-configured to recognize and relay traffic for isolated devices, enabling automatic recovery without requiring physical administrator intervention when disconnections happen

Inventive Principle:

Principle #10Preliminary action

2Reliability

If physical intervention is required to re-establish connection, then connection reliability is improved, but downtime and operational efficiency deteriorate

Engineering Contradiction:

Improveconnection re-establishmentVSAvoiddowntime

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

The network device performs self-service by automatically detecting connection failures through LLDP message timeouts, identifying neighboring devices capable of relaying traffic, and reconfiguring itself using configuration data received through the neighboring device. This automated self-recovery process eliminates the need for physical administrator intervention, reduces downtime, and maintains connection reliability without sacrificing productivity

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The system implements feedback mechanisms where the isolated device continuously monitors for LLDP messages from the management device. When messages are not received, the device triggers a recovery sequence by utilizing the neighboring device as a relay, receives configuration updates, and verifies connection restoration. This closed-loop feedback system ensures reliable reconnection while minimizing downtime through automated responses to connectivity status changes

Inventive Principle:

Principle #23Feedback

3Reliability

If configuration changes are applied to restore connection, then connectivity reliability is improved, but risk of further disconnection deteriorates

Engineering Contradiction:

Improveconnectivity restorationVSAvoidrisk of further disconnection

Core Design Contradiction:

ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The neighboring device serves as a protected intermediary that relays configuration changes from the management device to the isolated device. This indirect configuration path isolates the affected device from direct management traffic that might cause further disconnections, while still enabling necessary configuration updates through the stable neighboring device connection

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs preliminary validation and staged application of configuration changes through the neighboring device relay. Configuration data is first received and validated by the neighboring device, then selectively applied to the isolated device in controlled steps, reducing the risk of erroneous configurations causing further disconnections while still restoring necessary connectivity

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS10992528B2Configuring network devices

Publication Date: 2021.04.27 HEWLETT PACKARD ENTERPRISE DEV LP

AI summary

Example implementations relate to configuring network devices. For example, a network device includes a controller module to receive a link layer discovery protocol (LLDP) message from a second network device in response to determining that connection to a management device has failed. The controller module is to send a second LLDP message to the second device, where information contained is the second LLDP message is routed to the management device by the second device. The controller module is further to receive configuration changes from the management device and connect to the management device based on the configuration changes, where the configuration changes are routed by the second device.