Netforge.ai Docs
Open the app →
Docs/Guide/Console & OOB Management

Console & OOB Management

Console cabling to terminal servers; dedicated mgmt ports, VRF and IPAM.

Relevant for:Enterprise / NetOpsProfessional Services
Where to find itCanvas→Drag a Lantronix SLC from Console Servers→Cable console/mgmt ports

Every physical network device on the canvas exposes two out-of-band ports alongside its data faceplate: an amber console slot (serial) and a violet mgmt slot (the real dedicated management NIC — mgmt0 on Nexus, Management1 on Arista, GigabitEthernet0 on IOS-XE routers, GigabitEthernet0/0 on Catalyst, MGT on PAN-OS, and so on).

Note
The Blueprint wizard builds this layer for you: with its out-of-band toggle on (the default), every generated site gets an SLC sized to its device count, console runs to every router/switch/firewall, and a management-VLAN uplink — ready to hand-edit like anything else.
Tip
On a canvas with console runs, the amber Console pill (top-left, next to Site area) hides and shows the whole console layer — handy when the OOB runs crowd out the data topology on a small site. Hiding is a view setting only: the runs stay in the design, validation, the BOM, and every export.

Console cabling — terminal servers only#

Just drag a device onto a Lantronix— the link is cabled as a console run automatically: the device's console port pairs with the SLC's lowest free port{n} (sequential: port1, port2, …), no port-picking needed. Override the assignment in the link editor at any time; picking an already-occupied port silently lands on the next free one. To uplink the SLC itself into the LAN for management, drag from its eth0/eth1 Ethernet ports into a switch port — that is a normal data link.

Console ports connect only to a terminal-server console port (Lantronix SLC 8/16/32/48, port1…N) — validation re-checks every link in the design, including imported ones, with console-invalid-target (error) and flags two runs landing on one SLC port with console-port-conflict (error). When a terminal server is on the canvas, devices with an uncabled console get an info-level nudge. Each console run renders on the SLC as a named device port with its configured baud rate — and the SLC config always follows the canvas: renaming the peer, editing the link description, moving the port, or deleting the cable updates the deviceport lines on the next generate:

set deviceport port 3 name "to SW-01"
set deviceport port 3 baud 9600 datab 8 parity none stopb 1 flowcontrol none
set deviceport port 3 ssh enabled true
set deviceport port 3 state enabled
Why
When the network path is down, the console run through the terminal server is the way in. The serial rollover is not a data link: it takes no IP, joins no port-channel, and is exempt from media/speed checks — and the managed device intentionally emits no interface stanza for it.

Management port, VRF and IPAM#

Cable the violet mgmt slot into your OOB switch and the generated config binds the management address to the real interface — Catalyst switches gain a physical OOB block (instead of the in-band SVI) only when cabled. The Management VRF field (Mgmt tab, site-inheritable) defaults per platform — management on NX-OS, Mgmt-intf on IOS-XE routers — and a custom name flows into every template.

interface mgmt0
  description OOB Management
  vrf member management
  ip address 10.255.0.5/24
  no shutdown
vrf context management
  ip route 0.0.0.0/0 10.255.0.1
Why
Define a management pool in the IPAM drawer and auto-assign hands one host per device to its real mgmt interface. Manually-typed management IPs are overrides: auto-assign never clobbers them and reserves their addresses so no other device receives the same host. Validation closes the loop — mgmt-ip-duplicate (error), mgmt-ip-outside-subnet (warning), and an info nudge when a device with a mgmt IP is left uncabled while the rest of the design uses OOB cabling.