LLDP-based In-Band Management VLAN
in OpenWiFi Controller

In enterprise campus network lifecycle management, deployment efficiency during Day 0 (device planning and onboarding) and Day 1 (initial configuration deployment) directly affects the delivery cycle and operational costs of the entire network project. Traditional campus network deployment relies heavily on on-site manual intervention by network engineers. Without efficient automated provisioning, engineers must log in to each switch through the console port and perform pre-configuration, or use a controller to onboard devices through a highly constrained, sequential process. This traditional hierarchical onboarding model creates a clear architectural bottleneck: the core switch must be brought online first. Only after the controller identifies the core and deploys the configuration for the aggregation interfaces can the aggregation switches establish their uplinks and come online. Similarly, access switches and wireless access points (APs) must wait until the aggregation layer is fully configured before they can attempt to join the network. This serial onboarding process, which depends on the physical hierarchy of the switches, is highly inefficient in large modern campuses with dozens of buildings and hundreds or even thousands of interconnected devices. Controller-side topology operations are also cumbersome, significantly increasing the deployment and operational complexity for users.

Community SONiC was originally designed for hyperscale data centers. Its underlying architecture assumes the following conditions:

• Comprehensive Out-of-Band (OOB) management network support: Each switch in a data center connects to a dedicated, physically separate management network through a physical management port such as eth0. Image downloads, configuration deployment, and status monitoring are all handled through the OOB network without consuming the data-plane links.
• Symmetric and flat Clos topology: The network typically has only two or three layers, such as Leaf-Spine, with no complex Layer 2 loops or dynamic handoff and negotiation requirements between devices at different layers.

When deployed in campus networks, the native Zero Touch Provisioning (ZTP) mechanism reveals a significant architectural mismatch:

To address this bottleneck, Asterfusion introduced a Self-Negotiating Management VLAN solution that replaces static configuration dependencies with dynamic topology awareness. This article focuses on its operational logic and performance in real-world campus network scenarios.

The core architecture of this solution is to establish an in-band management path without relying on any OOB network, even when the physical links have no configuration. It uses the standard LLDP protocol (IEEE 802.1AB) as the control mechanism. Management VLAN information is carried in an Organizationally Specific TLV and propagated between Layer 2 adjacent devices. Combined with a locally deployed automation state machine, this mechanism establishes a temporary Layer 2 in-band management channel across all physical ports in parallel. This allows all devices across the network to come online in a single provisioning cycle.

According to the IEEE 802.1AB specification, LLDP supports Organizationally Specific TLVs (Type = 127) for extending vendor-specific management functions. Asterfusion uses its OUI (60:EB:5A) and defines a custom TLV with Subtype = 1. When transmitted over the link, this custom TLV carries two core types of control information:

1. Temporary Management VLAN ID: Indicates that a downstream switch with no configuration should place the interface into a unified Layer 2 in-band management broadcast domain. The default VLAN ID is 4094.
2. Distance Field: Indicates the logical topology distance between the transmitting device and the core gateway/controller.

In complex campus topologies, such as dual-homed access networks, triangular rings, and multi-branch tree topologies, arbitrary cable connections can easily cause management traffic to oscillate across multiple paths. To address this issue, the Asterfusion state machine locally implements a shortest-path election algorithm based on the LLDP Distance field.

When an unconfigured switch boots, its local service continuously scans and listens for LLDP packets on all physical data ports. Let P_active denote the set of active interfaces that have received Asterfusion custom LLDP packets. The device calculates its minimum logical distance to the core control node as follows:

Here, D_neighbor(p)  represents the Distance field carried in the neighbor’s LLDP packet received through physical interface . If the device is directly connected to a Spine/Core switch and the received neighbor Distance is 0, the locally calculated  D_local is 1.

When an uplink fails or a dual-homed topology switches paths, the local state machine immediately recalculates the D_neighbor value for all active ports in the HashMap. It then dynamically converges to the next-best path within a very short period:

This mechanism eliminates the need for users or installers to identify specific physical interfaces during deployment. Cables can be connected without predefining port roles, while the management path automatically converges toward the core node. This improves the robustness of the underlying topology.

The entire self-negotiation and in-band management channel construction process is controlled by the local state machine in a closed loop. No manual onboarding scripts are required. The standard process consists of four technical stages:

1. Spine/Core Anchoring and Triggering: The network engineer only needs to log in to the core switch for the initial configuration. The engineer configures the default route and IP addressing rules for controller connectivity, such as a static route or an uplink interface (uplink ethernet 1 ip address A.B.C.D/mask gw A.B.C.D). The corresponding DHCP pool is also created on the core switch. Downstream physical ports are assigned to the temporary management VLAN, such as VLAN 4094, and a static IP address is assigned to its Layer 3 interface within the DHCP subnet. After lldp transmit mgmt-vlan is enabled on the core device, the switch acts as the anchor node and starts sending LLDP packets containing the Asterfusion custom TLV to downstream devices.

2. Empty-Config Check: On downstream aggregation and access switches, the system starts the background service during boot. The service checks whether the device is in a clean, factory-default state with no configuration. Once the device is confirmed to be unconfigured and receives an Asterfusion custom LLDP packet through any physical data port, the state machine immediately enters the temporary management channel construction process.

3. Layer 2 Interface Conversion and RSTP-First Loop Prevention: In an unknown physical topology, blindly placing all physical ports of an unconfigured device into the same VLAN can easily create loops and trigger a destructive broadcast storm. To address this deployment challenge, the local state machine follows a strict loop-prevention-first configuration sequence. RSTP (Rapid Spanning Tree Protocol) is enabled first to break network loops and maintain network connectivity during blind cabling.

After all devices establish the temporary management channel through LLDP-based cascading negotiation and successfully come online on the controller, the controller pushes the production configuration to each device based on the network-wide deployment template. This includes production VLANs, trunk ports, BGP/OSPF routing protocols, ACL security policies, and other configuration items.

The mgmt-vlan-service continuously monitors configuration changes. Once it detects that the production configuration pushed by the controller has been successfully applied, the service starts a graceful exit process. It automatically and transparently removes the interface bindings associated with the temporary VLAN 4094 and restores the physical ports to the Trunk or Access roles defined by the production configuration. The temporary service then releases its system resources and exits cleanly. This enables a seamless transition to the Day-1 production configuration without traffic interruption.

The Self-Negotiating Management VLAN provisioning solution is essentially a scenario-specific architectural redesign for Day 0/Day 1 campus network lifecycle management. It addresses the limitations of community SONiC ZTP in hierarchical, multi-level Layer 2 campus topologies. By using LLDP, a lightweight protocol natively supported by most network devices, as the control-plane mechanism, the solution enables the entire network to come online in a single provisioning cycle. It also removes the dependency of network automation on a dedicated OOB management network.

As open-source white-box network operating systems expand into specialized vertical markets, supporting data-plane and control-plane features such as PoE and 802.1X is only part of the requirement. They also need scenario-specific innovation in the management plane and full-lifecycle automated provisioning. This is essential for making open networking practical in complex campus environments, with faster deployment and simpler operations.