Overview

When a local network device fails to obtain an IP address via ONT DHCP, the root cause is rarely the DHCP server itself—it is almost always a Layer 2 VLAN mapping or Service-Port configuration mismatch between the ONT, OLT, and upstream core switch. This FAQ addresses the most common post-sales technical inquiries from B2B network engineers deploying GPON/EPON access solutions, focusing on the critical interworking between optical interfaces, virtual chassis stacking, and Layer 3 routing protocols that govern DHCP packet forwarding.

Frequently Asked Questions

Q1: Why does an ONT that shows online status still fail to pass DHCP traffic to connected devices?

An ONT being online only confirms that the PON management channel (OMCI) is operational; it does not guarantee that service VLANs are correctly mapped or forwarded. The most common cause is a missing or misconfigured Service-Port on the OLT, which is responsible for binding the ONT GEM port to the upstream business VLAN. If the Service-Port does not exist, uses the wrong VLAN ID, or references an incorrect GEM port index, DHCP Discover broadcasts from the client will be silently dropped before reaching the DHCP server. Always verify Service-Port mappings using OLT CLI commands such as display service-port all before assuming a DHCP server fault.

Q2: What is the default VLAN handling mode on ONT LAN ports, and how does it affect DHCP Discover forwarding?

The default VLAN mode is typically Transparent, which passes tagged frames without modification but does not automatically insert a VLAN tag on untagged client traffic. When a PC sends an untagged DHCP Discover frame, the ONT will forward it as untagged unless a Tag or Translation rule explicitly maps the LAN port to the service VLAN. This causes the frame to arrive at the OLT without the expected VLAN tag, where it is discarded by the Service-Port filter. For B2B deployments with untagged client devices, configure the ONT LAN port to add the service VLAN tag (Tag mode) or use a translation rule mapping PVID to the business VLAN.

Q3: How can I verify whether DHCP packets are actually traversing the OLT uplink to the core switch?

The definitive verification method is to enable DHCP Relay Agent logging on the OLT and inspect the packet capture counters. On supported platforms (e.g., Eltex LTP-X, MA4000), activate the dhcp-ra profile and set the logging module pmchal-dhcpra to debug level; the OLT will then log DHCP session entries showing the assigned IP, MAC address, and originating ONT port. If no session entries appear despite clients sending Discover broadcasts, the issue is upstream of the OLT—check the uplink trunk VLAN allow-list on the connecting core switch and confirm that the DHCP server address pool has available leases for that VLAN interface.

Q4: What stacking configuration errors can prevent DHCP relay from functioning across a virtual chassis?

In a stacking topology, DHCP Relay requires that the ip helper-address be reachable from the active master switch's routing instance, and that the relay agent's source IP (giaddr) be routable back from the DHCP server. A common error is configuring the helper-address on a standby member's interface without ensuring that the master's routing table has a path to the server; when the master forwards the relayed packet, the return DHCP Offer is routed to the master's giaddr and then dropped because the client VLAN interface is not locally present on that member. Always verify helper-address configuration on the master and confirm that the stacking ports carry the client VLAN in the inter-switch trunk.

Q5: How does DHCP Snooping interact with ONT-based access to block legitimate client requests?

DHCP Snooping, when enabled on the OLT uplink or core switch, classifies ports as trusted or untrusted; DHCP server responses (Offer/ACK) arriving on untrusted ports are discarded. In ONT deployments, the ONT-facing port on the OLT is often left in the default untrusted state, causing the DHCP Offer from the legitimate server to be dropped on its return path even though the Discover successfully reached the server. Configure the OLT uplink port toward the DHCP server as trusted, and ensure that the Service-Port mapping does not strip Option 82 information that Snooping may require for binding table validation.

Q6: What Layer 3 gateway misconfiguration on the core switch would cause DHCP Relay to fail for ONT clients?

If the core switch acting as DHCP Relay lacks a VLANIF interface with an IP address in the same subnet as the DHCP pool, or if the ip helper-address points to an unreachable server IP, relayed Discover packets will be dropped. Additionally, when VRRP is deployed for gateway redundancy, the DHCP Relay source address (giaddr) must be set to the virtual IP rather than the physical interface IP; otherwise, the DHCP server's Offer will be routed to the physical address and may be rejected if that address is not the active VRRP master. Verify that the relay configuration uses the VRRP virtual address as the gateway parameter for the client subnet.

Q7: Can a third-party SFP optical module cause DHCP to fail intermittently on the ONT uplink?

Yes, but only indirectly through physical layer instability. An incompatible or degraded SFP module on the OLT uplink or ONT PON interface can cause CRC errors, frame loss, or intermittent link flaps that manifest as DHCP timeout symptoms. However, if the optical link is stable and the ONT reports normal receive power (typically −8 dBm to −27 dBm for Class B+), the SFP itself is unlikely to be the DHCP-specific culprit. For B2B deployments, always validate third-party module compatibility with the OLT vendor's I2C EEPROM specification and monitor interface error counters (display interface) for CRC growth during DHCP failure windows.