EPON customer-owned router — need ONU provisioning to remove XER10

[SOLVED] UDM Pro + Xfinity Fiber (Nokia NKFN11AEL ONU) — Frequent Short "Temporary Internet Disconnection" alerts — Root cause + fix

TL;DR: If you're running a UniFi Dream Machine Pro directly connected to Xfinity's Nokia ONU (model NKFN11AEL, 10G-EPON) and getting frequent brief "Temporary Internet Disconnection" alerts, the issue may be a NIC/PHY negotiation incompatibility between the UDM Pro's native WAN port and the ONU — not your cabling or fiber signal. Using an SFP copper transceiver in the UDM Pro's SFP+ port instead of the native RJ45 WAN port resolved it completely for me, with no extra hardware needed.

My setup:

• Xfinity Fiber
• ONU: Nokia NKFN11AEL (10G-EPON), Comcast-provided
• Router: UniFi Dream Machine Pro, connected directly to the ONU (no separate Xfinity gateway — had Xfinity remove my XER10 and adopt the UDM Pro directly)

The symptom:
After switching from Xfinity's XER10 gateway to my own UDM Pro, I started getting frequent UniFi alerts along these lines: "Internet connection WAN1 (Comcast Cable) on port 9 is restored after a temporary disconnection," with a reported duration of around 7 seconds. Short outages, auto-recovering quickly, happening repeatedly throughout the day. Xfinity had the ONU remotely rebooted, which reduced the frequency slightly but didn't fix it.

What I ruled out (in order):

1. Ethernet cable — swapped it, no change.

2. Fiber connector cleanliness — I have access to professional fiber cleaning tools through my job, cleaned both ends, no change.

3. SSH'd into the UDM Pro to get real data instead of guessing. This was the turning point. A few useful things to check if you're in the same boat:

• Running "ip addr show" and grepping for your public IP confirms which interface is actually your WAN (for me it was eth8, mapped to physical port 9).
• Checking the file at /sys/class/net/eth8/carrier_changes gives you a cumulative counter of physical link up/down transitions since boot. Mine was absurdly high — 500+ in about 12 hours of uptime.
• Running "dmesg -T" and grepping for your WAN interface name showed explicit, repeating kernel log entries — a "Link is Down" message followed a couple seconds later by "Link is Up - 1Gbps/Full - flow control rx/tx" — happening every 1-3 minutes, sometimes multiple times per minute. This confirmed it was a real physical-layer link flap, not just a false-positive reachability/ping check from UniFi's monitoring.
• Running "ethtool -S eth8" showed zero CRC/MAC/DMA errors. The link was flapping cleanly, with no signal corruption — which pointed away from a damaged/dirty fiber connection and toward a negotiation-level issue instead.

4. Energy Efficient Ethernet (EEE) — checked via ethtool, already disabled by default. Ruled out.

5. Flow control — disabled it manually via ethtool, confirmed the change applied, but flapping continued at the same rate. Ruled out.

What actually fixed it:

Option A — Add a switch in between. Putting any unmanaged switch between the ONU and the UDM Pro's WAN port (ONU → switch → UDM) completely stopped the flapping — confirmed with zero flaps over 7+ hours overnight once I used a gigabit-capable switch (my first test switch had PoE ports capped at 100Mbps, which worked but obviously isn't ideal for speed).

Option B — Use an SFP copper transceiver instead of the native WAN port (this is what I ended up using). My theory, which testing confirmed, was that the actual electrical/PHY negotiation chip is different hardware on an SFP module versus the UDM Pro's integrated native RJ45 WAN port (which uses an Annapurna Labs chipset). I swapped in a copper SFP transceiver — Aruba model J8177D, 1G SFP-BT — into the UDM Pro's SFP+ port, and connected the ONU directly to that instead of the native WAN port. Result: zero flapping, confirmed over 13+ hours overnight, running at full 1Gbps/Full duplex, no switch needed.

My conclusion: This looks like a NIC/PHY-level autonegotiation incompatibility specifically between the UDM Pro's native WAN port chipset and this Nokia ONU's Ethernet port — not a cabling, fiber, or ISP provisioning issue. Both workarounds (switch, or SFP transceiver) sidestep it by introducing different PHY hardware into the negotiation. The SFP route is the cleaner fix since it doesn't require an extra device in the chain — just plug a copper SFP into your UDM Pro's SFP+ port instead of using the native WAN RJ45 port.

If you're hitting this issue, here's what I'd try, roughly in order:

1. SSH into your UDM/gateway and check dmesg for repeating "Link is Down"/"Link is Up" entries on your WAN interface to confirm you're dealing with the same thing.
2. Try a copper SFP module (1000BASE-T) in your gateway's SFP+ port if it has one, connected directly to your ONU.
3. If that's not an option, an unmanaged switch between the ONU and your router's WAN port works too.

One more note: I used Claude (Anthropic's AI assistant) throughout this entire troubleshooting process — from figuring out the right commands to run, interpreting the log output, and designing the step-by-step tests (cable swap, fiber cleaning, EEE/flow control checks, switch test, SFP test) that eventually isolated the root cause. Mentioning that both for transparency and in case it's useful for anyone else — pairing AI-assisted troubleshooting with actual CLI/log verification got me to a real root cause instead of just guessing or doing a string of generic "reboot everything" steps.

Happy to answer questions if anyone runs into the same thing.