Console Recovery on Deevnet Infrastructure Platform

Core Router

Mon, 01 Jan 0001 00:00:00 +0000

Core Router #

Recovering dv02cor002p01 from the physical console when the network cannot reach it, and restoring the configuration that closed the door.

The router’s management path — the web UI, the API, SSH — is itself a firewall rule on the router. When that rule is wrong there is no remote route back in, including for the automation host, which sits behind the same policy and so cannot undo its own change. The console is the way in.

Hypervisor

Mon, 01 Jan 0001 00:00:00 +0000

Hypervisor #

Recovering a Proxmox node — dv02hyp001p01 or dv02hyp002p02 — from the physical console when its management address stops answering.

A node loses its own management path far more easily than it loses its VMs. The guests usually keep running on a node you cannot log into, which is worth knowing before you rush: there is normally no data at risk, only access.

What you need #


Adapter	DisplayPort → HDMI, into your monitor.
Keyboard	USB.
Access	Physical, at the node.
Credentials	The node’s root password, from the inventory vault.

Node	Address	Role	CNAME
`dv02hyp001p01`	10.20.99.21	Management hypervisor	`pve`
`dv02hyp002p02`	10.20.99.22	Tenant hypervisor	`pve2`

1. Confirm it is the node, and that it is awake #

ping -c1 10.20.99.21
timeout 3 bash -c 'exec 3<>/dev/tcp/10.20.99.21/8006' # PVE web UI
timeout 3 bash -c 'exec 3<>/dev/tcp/10.20.99.21/22' # ssh

Both nodes have wol: true in inventory, so if the box is simply powered off the answer is not a monitor:

Access Switch

Mon, 01 Jan 0001 00:00:00 +0000

Access Switch #

Recovering dv02acc001p01 when it can no longer be reached at 10.20.99.10 — by discarding its configuration and rebuilding it from inventory.

The switch’s whole configuration is declared: VLAN database, trunks, access ports, hostname and default gateway all come from host_vars/dv02acc001p01.yml and are applied by one playbook. That makes a factory reset a legitimate recovery tool rather than a last resort — there is nothing on the switch worth preserving that is not already in git.

Wireless AP

Mon, 01 Jan 0001 00:00:00 +0000

Wireless AP #

Recovering dv02wap001p01 when it stops answering at 10.20.99.9 or its SSIDs stop serving the right VLANs — by factory reset, re-adoption, and reapplying its wireless configuration.

Nothing wired depends on the AP, so the site keeps running while you work — but you probably do. The AP supplies primary connectivity here, so the moment it stops serving, the laptop you would recover it from is off the network too, and every address in this page becomes unreachable. Getting a wired path onto the management segment is therefore step 1, not a footnote.