Network on Deevnet IoTaaS

Important URLs

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

Important URLs #

Every management interface and service endpoint on the mobile site, by DNS name and by IP.

Names are in the mobile.deevnet.net zone and resolve through the core router, 10.20.99.1.
Use the IP when DNS is the thing that is broken, or when you are not using the site’s resolver.
Where to reach them from: the management segment (VLAN 99) — the builder, or a laptop on the operator port gi1/0/2, which gets an address from 10.20.99.200–230. From the travel router’s network, tunnel through the builder instead: see Operator Access.

Checked 2026-09-11 from the builder: every URL below answered, by name and by IP, except where the Notes say otherwise.

Operator Access

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

Operator Access #

Reaching the builder and the management web UIs from an operator laptop. There are three ways in, and which one to use depends on what is broken.

Path	Laptop on	Goes through	Use it for
Trusted Wi-Fi	`DVNTM` (trusted, `10.20.10.0/24`)	the AP, the switch and the core router	everyday work: SSH to the builder at `10.20.99.95`, and the management UIs directly
Travel router (below)	`192.168.8.0/24`	the builder’s `enp1s0` only	work that takes down the switch, the AP or the router’s trusted side
Operator port ( below)	`gi1/0/2`, untagged VLAN 99	the switch only	the travel router or `enp1s0` is the problem

Trusted reaches management by a declared lab exception, the trusted -> management pass in the zone policy. The standard allows it: the trusted segment “MAY access management services for administration purposes”. It is also protected from deletion (firewall_protected_descriptions), because it is the operator’s own path. A dedicated jump host would be purer, but it would be one more thing to build and keep running for a lab this size, and that isn’t worth it. No other SSID reaches management; Segment Check verifies both from a client.

Segment Check

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

Segment Check #

Checking from a real client that each Wi-Fi segment reaches what the zone policy allows and nothing else.

The firewall role reports what it wrote. It cannot report what a client gets: whether a lease lands in the right subnet, whether names resolve through the segment’s own gateway, or whether a denied port is really dropped. The only place to see that is a laptop on the SSID. scripts/segment-check.sh in ansible-collection-deevnet.net does it in one run per SSID.

Network Reference

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

Network Reference #

Quick reference for VLAN assignments and network configuration across Deevnet sites.

mobile VLAN Assignments #

Segment	VLAN ID	Subnet	Gateway	DHCP
Trusted	10	10.20.10.0/24	10.20.10.1	.100-.200
Storage	20	10.20.20.0/24	10.20.20.1	Static only
Platform	25	10.20.25.0/24	10.20.25.1	Static only
IoT	30	10.20.30.0/24	10.20.30.1	.100-.200
IoT Vendor	31	10.20.31.0/24	10.20.31.1	.100-.200
IoT Backend	35	10.20.35.0/24	10.20.35.1	Static only
Guest	40	10.20.40.0/24	10.20.40.1	.50-.250
Tenant Dev	45	10.20.45.0/24	10.20.45.1	.50-.250
Tenant Transit	50	10.20.50.0/24	10.20.50.1	Static only
Tenant Underlay	51	—	—	None (unrouted)
Management	99	10.20.99.0/24	10.20.99.1	.200-.230 (temporary; infrastructure is static or reserved)
Blackhole	999	—	—	None (unrouted)

Tenants are not VLANs. Under ADR-0001 a tenant is an EVPN/VXLAN overlay owned by the tenant hypervisor’s fabric, addressed from 10.20.128.0/18 by fabric IPAM. The Tenant Transit and Tenant Underlay VLANs are the fabric’s transport: transit to the perimeter, and the VTEP underlay. Creating a tenant changes neither. Tenant Dev is not part of the fabric: it is where a tenant’s developer sits ( CHG-0022).