Environment
- Router: CCR1072-1G-8S+ (Tile-Gx72, tile architecture)
- RouterOS: 6.49.20 (long-term)
- Setup: eBGP IPv4 has been running for years without issue. IPv6 was freshly enabled
(packageipv6was disabled, we enabled it + rebooted) to bring up a new eBGP IPv6
session with an upstream (AS11014) over a dedicated /127 point-to-point subnet on the
same physical interface already used for the IPv4 session.
Configuration applied
/ipv6 address add address=2800:a10:0:ff:1000::487/127 interface=sfp-sfpplus2-WANxMETRO
/routing filter add action=accept chain=METROTEL-OUT-V6 prefix=2803:9390::/32 prefix-length=32-32
/routing filter add action=discard chain=METROTEL-OUT-V6
/routing bgp network add network=2803:9390::/32 synchronize=no
/routing bgp peer add instance=Publico name=peer-METROTEL-v6 remote-address=2800:a10:0:ff:1000::486 remote-as=11014 address-families=ipv6 out-filter=METROTEL-OUT-V6 ttl=255 hold-time=3m default-originate=never
What's working
- BGP session establishes fine and stays Established:
6 E ;;; Peering IPv6 Metrotel
name="peer-METROTEL-v6" instance=Publico remote-address=2800:a10:0:ff:1000::486 remote-as=11014
address-families=ipv6 default-originate=never ...
Winbox peer status: Prefix Count=1, Updates Sent=1, Updates Received=1, Established.
-
Our own advertised prefix (2803:9390::/32, origin AS273021) is confirmed VISIBLE
externally (verified via public looking glass, upstream path shows AS11014). -
Ping to the BGP neighbor's IPv6 address succeeds perfectly:
/ping 2800:a10:0:ff:1000::486 count=5
sent=5 received=5 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=1ms
- The connected /127 route is Active and shows as reachable:
/ipv6 route print detail where connect
0 ADC dst-address=2800:a10:0:ff:1000::486/127 gateway=sfp-sfpplus2-WANxMETRO
gateway-status=sfp-sfpplus2-WANxMETRO reachable distance=0 scope=10
- IPv6 neighbor entry resolves with a valid MAC (upstream's side is a VRRP virtual MAC,
00:00:5E:00:01:EE):
/ipv6 neighbor print
0 R address=2800:a10:0:ff:1000::486 interface=sfp-sfpplus2-WANxMETRO
mac-address=00:00:5E:00:01:EE status="stale"
/ipv6 settings printshowsforward: yes(global IPv6 forwarding is enabled).
The problem
The default route (::/0) received via this BGP session is permanently NOT active,
with gateway-status ... unreachable, despite everything above:
/ipv6 route print detail where dst-address=::/0
0 Db dst-address=::/0 gateway=2800:a10:0:ff:1000::486
gateway-status=2800:a10:0:ff:1000::486 unreachable
distance=20 scope=40 target-scope=10 bgp-as-path="11014" bgp-origin=igp
received-from=peer-METROTEL-v6
Disabling/re-enabling the BGP peer to force re-negotiation did not change this.
Troubleshooting already attempted (all failed to resolve it)
- Manual static route to the same gateway IP, distance=1 (mirroring how the
existing, working IPv4 default route to this same upstream is configured — a plain
staticgateway=<ip> distance=1):
/ipv6 route add dst-address=::/0 gateway=2800:a10:0:ff:1000::486 distance=1
Result: also stays inactive (no "A" flag), same "unreachable" gateway-status.
-
Explicit scope=0 on a test static route to the same /127 network (to rule out
any scope/target-scope mismatch, since 0 satisfies any reasonable scope comparison):
no change — BGP route still unreachable. -
Explicit target-scope=30 on the static default route (well above the connected
route's scope=10, to rule out an off-by-one/strict-inequality scope comparison
issue): route still does NOT show as active. -
gateway= instead of gateway= (point-to-point-style gateway,
bypassing recursive resolution entirely):
/ipv6 route add dst-address=::/0 gateway=sfp-sfpplus2-WANxMETRO distance=1
This DOES show as Active — but real traffic through it fails. Pinging an external
IPv6 address (2001:4860:4860::8888) mostly times out, and one reply came back FROM
OUR OWN address as "address unreachable" — suggesting the router attempts to resolve
the final destination on-link rather than forwarding via the actual neighbor, which
is the wrong behavior for a shared-media (SFP+/Ethernet) interface, not a true PPP
point-to-point link.
-
gateway=% syntax: rejected outright by RouterOS —
failure: Invalid route configuration: Invalid gateway configration— apparently
this syntax is only accepted with link-local addresses, not global unicast. -
Attempted to flush/refresh the stale IPv6 neighbor cache entry to force it back to
"reachable":/ipv6 neighbor remove [...]is not accepted in this menu/version
(syntax error,removedoesn't appear to be a supported action for/ipv6 neighbor
in 6.49.20).
Question
Why would a BGP-received (and independently, manually-added static) IPv6 default route
whose gateway sits on a directly-connected, actively-pinging, ND-resolved /127 subnet
persistently show gateway-status ... unreachable, when every underlying reachability
signal we can check from the CLI (ping, connected route active+reachable, ND cache
resolved) looks healthy? What's actually being evaluated to produce that "unreachable"
status, and what's the correct/supported way to get this default route to install
active — ideally without resorting to the gateway=<interface>-only workaround, which
breaks proper next-hop resolution for real traffic on this Ethernet-type interface?
Happy to provide /export output (secrets masked) or a supout.rif file if useful.