BLang's Journal
← Back

2026-08-30

Building a dedicated CML management plane

Building a dedicated management plane for CML was supposed to be an afternoon upgrade. Rebuilding the LAN went as planned. Tracing one DHCP request through two physical NICs, VMware, Linux bridges, and CML turned it into a weekend project—and the reason for this write-up.

The design

I added a second physical NIC to my Windows PC for a dedicated CML management network, then rebuilt the LAN around a managed router, switch, and wireless access point.

VLAN 1
Infrastructure and the CML controller
VLAN 20
IoT devices and their own Wi-Fi SSID
VLAN 99
CML lab-node management

The router and switch carry the VLANs, the access point maps the IoT SSID to VLAN 20, and a dedicated switch port places the second PC NIC directly on VLAN 99.

One PC, two Ethernet cables, and two intentionally separate paths into the same CML VM.

The challenge

CML networking is turtles all the way down. A VLAN 99 DHCP broadcast had to cross the physical switch, the second Windows NIC, a VMware virtual network, a CML vNIC, a Linux bridge, and a CML External Connector before reaching the simulated switch.

Any one of those can drop the frame silently, and none of them tell you which. So I stopped guessing and worked upward — proving one boundary at a time, and refusing to move on until the current one was provably good.

The physical switch

Two port problems, both mine:

  • The router uplink had to carry VLAN 99 tagged while keeping VLAN 1 untagged.
  • The port feeding the CML management NIC had to carry VLAN 99 untagged, with PVID 99.

Then the one that cost me real time: the router uplink's acceptable frame type was set to untagged-only. Tagged VLAN 99 frames were being discarded at the uplink before they reached anything else. Changing it to all opened the path.

VMware

The CML-MGMT-PLANE network was bridged to Wi-Fi instead of the dedicated 2.5 GbE NIC. VMware will happily bridge to whichever adapter it likes and never mention it.

Corrected, the VM's adapters map cleanly: VMnet0 to the infrastructure NIC on VLAN 1, CML-MGMT-PLANE to the dedicated NIC on VLAN 99.

Inside CML

This is where I lost the most time. CML is a Linux box, and it behaves like one.

ens160 is the controller's interface on bridge0. ens32 is the VLAN 99 path, and it had nowhere to go — so I created bridge99 and attached ens32 to it. Then the change that actually mattered: the External Connector was still pointed at bridge0. Moving it to bridge99, connecting sw0 to it, and putting that port in VLAN 99 completed the path.

The last trap is the one that looks like a mistake. I never gave bridge99 an IP address. Three commands tell you whether the plumbing is right: 

ip -br link
ip -br addr
bridge link

The output I was looking for:

ens32     UP
bridge99  UP

ens32 master bridge99 state forwarding

Both interfaces up, ens32 enslaved to bridge99 and forwarding — and neither one holding an address. That absence is not a missing step, it is the proof. The bridge never routed VLAN 99; it transparently carried its Ethernet frames into the lab: 

VMware vNIC → ens32 → bridge99 → CML External Connector → sw0

One last place to get it wrong: the DHCP client belongs on the VLAN 99 SVI, not VLAN 1.

The VLAN configuration was straightforward. Proving every Layer-2 boundary was the real work.

The finished topology

Here is what it looks like under the hood: two physical Ethernet connections, two VMware networks, and two independent paths into CML.

CML dual-NIC network stack

One PC, two physical Ethernet cables, two independent paths into the same CML VM.

Physical connections

AN-210-SW-8-POE physical switch
One router trunk; two separate access ports run to the PC
Ethernet cable A · Infrastructure · VLAN 1 untagged
Physical NIC 1 · Realtek PCIe 5GbEWindows name: INFRA-VLAN1Windows endpoint on 10.10.1.xxx · VMware bridge target: VMnet0
Ethernet cable B · Lab management · VLAN 99 untagged
Physical NIC 2 · Realtek Gaming 2.5GbEWindows name: CML-MGMT-VLAN99Windows endpoint on 10.10.99.xxx · VMware bridge target: CML-MGMT-PLANE

Cable A continues to the CML controller

  1. VMware networkVMnet0Bridged only to the Realtek 5GbE NIC
  2. CML vNICNetwork Adapter 1Linux interface: ens160
  3. Linux bridgeens160 → bridge0bridge0 owns 10.10.1.xxx
  4. DestinationCML controllerWeb GUI · CockpitThe infrastructure path terminates here

Cable B continues through CML to lab nodes

  1. VMware networkCML-MGMT-PLANEBridged only to the Realtek Gaming 2.5GbE NIC
  2. CML vNICNetwork Adapter 2Linux interface: ens32
  3. Linux bridgeens32 → bridge99No IP on ens32 or bridge99Layer-2 frames pass through unchanged
  4. CML connectorExternal ConnectorLabel: CML-MGMT-VLAN99
  5. Lab endpointsw0 · SVI Vlan9910.10.99.xxx/24The lab-management IP lives here
Layer-3 endpointWindows owns one IP on each NIC; bridge0 and sw0's Vlan99 SVI also own IPs.
Layer-2 plumbingVMware networks, ens32, bridge99, and the External Connector carry frames without becoming IP hops.

Cable A carries the infrastructure path to the CML controller. Cable B carries the dedicated VLAN 99 management segment through VMware and CML to the lab nodes. The passthrough components do not need management addresses; the simulated switch owns its address on the Vlan99 SVI.

What's next

DHCP proved the plumbing. Next, I am replacing the temporary leases with static management addresses and turning this design into a reusable CML baseline.

From there, I can push CCNP Enterprise configurations from VS Code, across the bridge, and directly into the lab.

I build it, I break it, I document it, and I make it better.

Follow along

If any of this is useful or interesting, stick around—there is more coming. You can find me on LinkedIn and GitHub.