Link and power good, device never gets on
very common
“Green light, camera's powered, and it never shows up on the system. Sitting there on a one-sixty-nine address.”
Likely causes
-
Port in the wrong VLAN, or tagged when it should be untagged
30%The switch has learned the PD's MAC on the port but there is no DHCP offer and no ARP entry in the target subnet, and the PD self-assigns 169.254. Move the port into the right access VLAN and it appears immediately.
-
Native VLAN mismatch, or the VLAN missing from an upstream trunk's allowed list
25%The PD works from a port on this switch but not once traffic has to cross the trunk. The VLAN exists locally and is absent from the trunk, or from the switch at the other end of it.
-
No DHCP scope, exhausted scope, or no relay or helper on that VLAN's gateway interface
20%A laptop with a static address in the same VLAN talks fine while the PD gets nothing. Devices in that VLAN got addresses months ago and no new ones have appeared since.
-
Device expects a voice or auxiliary VLAN offered by LLDP-MED or CDP and the port does not offer one
10%Phone or endpoint lands in the data VLAN or nowhere at all, and the switch shows no MED policy on the port. Add the voice VLAN and enable LLDP-MED and it moves itself.
-
802.1X, MAB or port security rejecting the device
10%Switch logs an auth failure or a security violation against the PD's MAC, or the port is err-disabled or dumped into a restricted VLAN. The PD is unmanaged and cannot do 802.1X at all; it needs MAB or an exemption.
-
Static addressing left on the device from a previous site, or a duplicate address
5%The PD only answers from a laptop set into its old subnet, or ARP shows its address already claimed by something else.
What to bring
- Switch CLI for MAC table, VLAN, trunk config and auth logs
- Laptop that can take a static IP
- LLDP viewer app on the phone
- Small managed test switch
- PD documentation for its VLAN and addressing needs
Steps
-
Step 1: Confirm the switch has learned the PD's MAC on that port, and note the VLAN it landed in
MAC present means layer 1 and 2 are fine and the fault is above them: stop looking at cable. No MAC at all means go back to the physical faults.
If that doesn’t do it
Treat it as a link fault, not a config fault: go to Gig device links at 100 Mbps
-
Step 2: Compare the port's VLAN and tagging mode against what the device actually needs
Most cameras, readers, controllers and APs in access mode want untagged in one VLAN. APs in trunk mode and phones want a tagged config. Get the tagging backwards and it looks exactly like a dead network.
If that doesn’t do it
Follow the VLAN upstream
-
Step 3: Verify the VLAN exists and is allowed on every trunk between this switch and the gateway
One missing VLAN on one trunk breaks everything downstream of it. Check the native VLAN agrees at both ends of each trunk, not just at your end.
If that doesn’t do it
Prove the path with a static address
-
Step 4: Put a laptop on the same port with a static address in the target subnet and ping the gateway
Gateway answers: the VLAN path is good and the problem is DHCP or the device. No answer: the VLAN or trunk path is broken and DHCP was never going to work.
If that doesn’t do it
Check the DHCP scope and relay
-
Step 5: Check the DHCP scope and the relay or helper on that VLAN's gateway interface
Look for an exhausted pool, a missing helper address, or a reservation pointing somewhere else. A request counter that never increments at the server means the request is not reaching it: that is a relay problem, not a scope problem.
If that doesn’t do it
Check port authentication
-
Step 6: Check 802.1X, MAB, port security and any NAC policy against the PD's MAC
Unmanaged PDs need MAB or a static exemption. Look for auth failures and violation shutdowns in the log. If the site runs NAC, this is where most new-device installs die.
If that doesn’t do it
Hand off to the network owner with the MAC, the port, the VLAN and everything above
References
- IEEE 802.1Q Clause 9
- IEEE 802.1AB
- ANSI/TIA-1057
- IEEE 802.1X