A device behind an ONU that sits on "obtaining IP address" forever almost never means the hardware is broken — it means a DHCP broadcast got stopped somewhere between the camera and the server. Fix the path the packet travels, and the address assigns itself. In a monitoring network with dozens of IP cameras hanging off ONU or switch user ports, DHCP is what hands out every address; when that link breaks, the device simply can't reach the network.
DHCP auto-assigns IP, subnet mask, gateway, and DNS; no address means the Discover broadcast never reached a server.
ONU downstream devices ride Layer-2 bridging, so the broadcast must cross every VLAN and uplink toward the DHCP server or relay.
Troubleshoot bottom-up: the device itself → same VLAN → link VLAN/uplink → server pool → cross-subnet relay.
When a device boots, it doesn't need a manually typed address. It sends a DHCP Discover broadcast — essentially asking "who is the DHCP server?" The server replies with a DHCP Offer carrying a candidate IP. The device answers with a DHCP Request ("I'll take this one"), and the server closes with a DHCP ACK, which makes the address live.
The address comes with a lease. A common lease is one day; some networks use eight hours. Before it expires, the device renews automatically without repeating the four-step handshake. Set the lease too short and you see extra broadcast traffic; set it too long and addresses stay locked to devices that have already been moved away.
An ONU downstream device sits on Layer-2 bridging. Its DHCP broadcast has to travel all the way up to the DHCP server — or to a DHCP relay / DHCP snooping function running on the OLT. In Rayin's industrial PoE switch plus PON fusion design, cameras land on the user-side ports of an ONU or switch, and the DHCP message has to climb through the uplink to the server sitting on the core switch.
If any single hop blocks the broadcast or the matching VLAN, the Discover never arrives and no address is handed out. The two usual culprits: the ONU's user-side and management-side VLANs aren't bridged, or the PON uplink port never permitted the camera's service VLAN.
| Symptom | Common cause | Fix |
|---|---|---|
| One device fails, others in the same VLAN are fine | Device set to static IP / wrong gateway | Switch it back to DHCP, verify the subnet |
| The whole VLAN fails | Uplink VLAN not permitted / relay not set | Permit the service VLAN, configure DHCP relay |
| Gets an IP but drops and reconnects | Pool exhausted / lease too short | Enlarge the pool, extend the lease |
| Fails across subnets | Layer-3 device missing helper address | Set DHCP relay on the gateway interface |
Work from the layer closest to the device and move up — that finds the break fastest.
Step one gets skipped constantly: many cameras ship from the factory with a static IP. Plug one into a DHCP network and it will never pull an address. Confirm the device is actually in DHCP mode before chasing the infrastructure — that alone removes half the wasted effort.
Note: A monitoring network that keeps growing — adding cameras but leaving the DHCP scope at its old range — will quietly run out of addresses. Checking the server's remaining pool is faster than swapping hardware.
Tip: For cameras and the DHCP server on different subnets, the Layer-3 switch or router needs a DHCP relay (helper address). It turns the broadcast into a unicast sent to the server, and the source interface must match the camera's gateway.
Warning: A too-long lease turns freed addresses into zombies. A device moved off-site still holds its address until the lease expires, so the pool looks full when it isn't.
Why does the camera stay stuck on "getting IP"? Almost always the DHCP message didn't reach the server. First confirm the device is in DHCP mode, then check whether other devices in the same VLAN can get addresses. If none can, inspect the uplink VLAN and the DHCP relay.
Can static IP and DHCP coexist? Yes, but the static address must be excluded from the DHCP pool. Otherwise the server may hand the same address to two devices, causing an IP conflict that takes both offline.
Should I enable DHCP snooping on the ONU? For monitoring networks with many terminals, yes. It blocks a rogue DHCP server — say a small router mistakenly plugged in — from handing out wrong addresses and pulling the whole segment offline, and it only forwards replies from trusted ports.
How long should the lease be? For fixed terminals that rarely change, 1–7 days is fine. For devices that frequently go up and down, use something shorter like 8 hours so addresses recycle quickly. The real rule: the pool must cover your peak online count.
Why does everything still fail after the camera is fine? Because the problem is usually "the message didn't traverse," not the server itself. Walk the order — device → same subnet → link VLAN → server pool → cross-subnet relay — and don't start by blaming the hardware.
DHCP looks trivial until it fails, and when it does the fault is almost always a broadcast that didn't get through — not a dead server. Move bottom-up, confirm DHCP mode first, and the address usually assigns itself.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
