MikroTik Chateau 5G R17 AX — debugging a stuck failover: the wrong-port trap

A short troubleshooting story from my own Chateau setup. Internet "worked", games felt laggy, latency to local targets was around 30 ms instead of the usual 8–12 ms. Took me about 30 minutes to find — entirely because I was looking at config when the bug was in cabling. Writing it down so I don't lose another evening to it.

The setup recap

Chateau 5G R17 AX, RouterOS 7.19.5. Same shape as in the base-setup post:

The symptom

Browsing worked. Games started spiking — 30–60 ms ping where I expected 10. ipinfo.io from my laptop:

"ip": "<your-lte-public-ip>",
"city": "<city>",
"org": "AS<lte-asn> <LTE ISP>"

That's the LTE eSIM, not the cable ISP. So I was on backup the whole time and didn't notice. The reason it wasn't obvious: IPv6 did work normally because the ISP modem sits on the same L2 as the Chateau's bridge and ships IPv6 RAs directly to clients. So ping6 to anything was perfect; only IPv4 was on LTE.

Diagnostic ladder

This is the order I should have gone in (and will, next time).

1. Public IP and ASN — first thing always

curl -s ipinfo.io/json | grep -E '"ip"|"org"'
curl -s -6 ipinfo.io/json | grep -E '"ip"|"org"'

If IPv4 says AS<lte-asn> <LTE ISP> but IPv6 says AS<cable-asn> <cable ISP> — you're on backup for v4 only. That's the smoking gun.

2. Hop 2 of the IPv4 traceroute

traceroute -n -m 4 8.8.8.8

If hop 2 is anything in 172.16.0.0/12 or 100.64.0.0/10, you're CGNAT'd through LTE.

3. MikroTik default routes

/ip route print where active dst-address=0.0.0.0/0

Two equal-cost defaults via lte1 and no DHCP-derived route via ether1 → DHCP-client never bound on the WAN port.

4. DHCP-client status

/ip dhcp-client print detail

status=searching... for more than ~10 seconds with link-ok on the interface = something between the modem and the DHCP-client is broken. Always one of:

1. Wrong physical port (this post)
2. Wrong interface in the DHCP-client config
3. ISP modem LAN-DHCP not running yet (just rebooted, give it 60 s)
4. ISP modem has a stale lease bound to an old MAC
5. Bad cable / link auto-negotiated to 10 Mbps

5. Physical link state on the WAN port

/interface ethernet monitor ether1 once

Healthy:

status: link-ok
rate: 1Gbps
full-duplex: yes

If rate: 10Mbps, the cable is electrically dead on 2 of 4 pairs. Replace the cable before debugging anything else — at 10 Mbps half-duplex even DHCP can struggle on bursty offers, and you've capped the whole house at 10 Mbps anyway.

6. Bridge port membership and switch grouping

/interface bridge port print
/interface ethernet switch port print

This is the one that bit me. More on it below.

The actual bug

I had moved the Ethernet cable from the ISP modem into a different port on the Chateau (didn't think — was unplugging things and put them back wrong). Specifically:

• ether1 (WAN, outside bridge): now had my desktop PC plugged in
• ether5 (LAN, in bridge): now had the cable from the ISP modem

What this looks like on the router:

/interface bridge port print
;;; defconf
0 X ether1     bridge       ...  (DISABLED in bridge — defconf marks it as WAN)
1   ether2     bridge  yes  ...
4   ether5     bridge  yes  ...   ← provider cable plugged here
...

ether1 is intentionally disabled on the bridge in defconf. That's what makes it the WAN port. The DHCP-client is bound to ether1 for the same reason. So:

• The cable from ISP modem ended up on the LAN side: it was bridged with all my LAN devices and WiFi clients. ISP modem's DHCP server was racing the Chateau's DHCP server on 192.168.50.0/24.
• ether1 was waiting for DHCP from a desktop PC that obviously wasn't speaking DHCP-server.
• Failover correctly noticed ether1 had no default route and kept everything on lte1.

The fact that IPv6 still worked perfectly through the ISP modem made the whole thing feel like a "the internet is just slow today" situation rather than a clear outage.

The fix

Once I noticed:

1. Move ISP modem cable → ether1.

2. Move desktop → any of ether2–ether5.

3. On the Chateau:

   /ip dhcp-client set [find interface=ether1] add-default-route=yes default-route-distance=1
   /ip dhcp-client renew ether1

   I had add-default-route=no from the failover setup (because I add the recursive route by hand — see base-setup, Step 6). For a quick test I flipped it to yes with distance=1. If you want to keep the recursive 1.1.1.1 probe, leave add-default-route=no and trust the static routes you already have — they'll come back active once the DHCP lease binds.

4. Verify:

   /ip dhcp-client print
   # status=bound, address=192.168.0.<lease>/24
   /ip route print where active dst-address=0.0.0.0/0
   # DAd 0.0.0.0/0  192.168.0.1  d=1   ← cable, primary
   # As+ 0.0.0.0/0  lte1         d=2   ← LTE, backup

5. From the laptop:

   curl -s ipinfo.io/json | grep -E '"ip"|"org"'
   # "org": "AS<cable-asn> <cable ISP>"   ← cable, not LTE

Lessons (rakes added to the pile)

• Label the WAN port physically. A piece of tape on the back of the router that says WAN ← ISP would have saved this whole evening. Doing it next time I touch the router.
• ipinfo.io is the first command, not the tenth. When something feels off, public IP + ASN tells you instantly which uplink is active. I spent fifteen minutes poking at routes before I ran it.
• IPv6 lying to you is a real failure mode in dual-stack with a passthrough modem. If the ISP modem is on the same L2 as your LAN, it can RA IPv6 to clients directly while your IPv4 path is broken. The "internet works" feeling is deceptive — always check both stacks separately when debugging.
• A link-ok port can still be wrong. The link auto-negotiated to 1 Gbps full-duplex on ether5 and looked perfectly healthy — because there was a perfectly healthy gigabit link, just to the wrong device. Link state tells you about the cable, not about the topology.
• bridge port print is the source of truth for WAN vs LAN role, not the port number. If you ever rewire, run that command before plugging anything in.
• Recently-rebooted ISP modem needs a minute. Uptime under ~2 minutes can mean the LAN-side DHCP server isn't ready yet. Wait, then renew. Don't start tearing down config.
• bound ≠ default route. A DHCP-client status of bound only means the lease was issued. Check add-default-route and the actual route table separately. They can disagree.

Quick-check command bundle

For the "is everything sane" 30-second sanity check, paste this on the Chateau:

:put "--- DHCP ---"
/ip dhcp-client print detail
:put "--- Routes ---"
/ip route print where active dst-address=0.0.0.0/0
:put "--- WAN link ---"
/interface ethernet monitor ether1 once
:put "--- LTE ---"
/interface lte monitor lte1 once
:put "--- Bridge ports ---"
/interface bridge port print

And on the client:

curl -s ipinfo.io/json | grep -E '"ip"|"org"'
curl -s -6 ipinfo.io/json | grep -E '"ip"|"org"'
traceroute -n -m 4 8.8.8.8

If all of those agree on "cable, primary, distance 1, hop 2 is your ISP modem LAN side" — you're good. If any of them disagree, start at step 1 of the diagnostic ladder above.

Companion posts: overview · base setup · back to home VPN · hardening