Reset IPv6 after gateway reboot.

In CPE scenario when upstream serves IPv6 properly you most definitely want add-default-route=**no** on /ipv6/dhcp-client. Enabling /ipv6/nd on the gateway interface should be sufficient to set up the default route.

So I made the changes to (I think) mimic yours

Can you post /ipv6/export and /ipv6/route after you do that and reboot the router? Reboot may be necessary to speed up the transition, otherwise RouterOS may be stuck waiting for various timeouts to expire before the config is refreshed.

Are you doing anything fancy with IPv6 firewall? Make sure you don’t block ICMPv6.

It is working now, I lost IP a couple of times overnight Saturday and I rebooted the gateway and in the past ipv6 wouldn’t have recovered.

Your posts lead me to the configuration “add add-default-route=yes” on the ipv6 dhcp-client that I need to include. I don’t have all your setting but unless I hear a recommendation I am happy with this so thanks a lot. I will be able remove the ipvb-server (it is only disabled in this)

[admin@MikroTik] > ipv6/export      
# 2024-10-14 22:25:04 by RouterOS 7.16
# software id = QGQN-CV9P
#
# model = RB5009UG+S+
# serial number = 
/ipv6 address
add address=::... eui-64=yes from-pool=rogers interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=rogers request=prefix use-peer-dns=no
/ipv6 dhcp-server
add address-pool=rogers disabled=yes interface=bridge name=ipv6-server
/ipv6 nd
set [ find default=yes ] advertise-dns=no interface=bridge other-configuration=yes
/ipv6 settings
set accept-router-advertisements=yes

I would try to add an /ipv6/nd record for the gateway interface (as in my example above) and change add-default-route to no on /ipv6/dhcp-client. Then see whether it would work after router’s reboot.

With your settings my gateway DAg IPv6 still drops off the route. Other than the prefix hint which I am not sure of I think this is still the same as yours.

/ipv6 address
add address=::... eui-64=yes from-pool=rogers interface=bridge
/ipv6 dhcp-client
add interface=ether1 pool-name=rogers request=prefix
/ipv6 dhcp-server
add address-pool=rogers disabled=yes interface=bridge name=ipv6-server
/ipv6 nd
set [ find default=yes ] advertise-dns=no disabled=yes other-configuration=yes
add advertise-dns=no interface=ether1 ra-lifetime=none ra-preference=low reachable-time=5m
add interface=bridge ra-preference=high reachable-time=5m
/ipv6 settings
set accept-redirects=no accept-router-advertisements=yes

With my settings the route is

DAg+ ::/0                      fe80::217:...        1
DAd+ ::/0                      fe80::217:...        1

with yours (before it gets dropped off) it is this.

DAg ::/0                      fe80::217:....         1

How long does it take for the default route to “drop off” after you apply this configuration? Did you try a reboot after applying it?

It would be interesting to capture the Router Advertisement packets on the WAN interface (e.g. with Wireshark), if you’re willing to diagnose this issue further and get to the bottom of the problem :slight_smile:

Yes I tested after a full reboot. the default route drops off as soon as I pull the network cable.

With my settings when I reinsert it the DAg+ router also disappears, but the seconds DAd route remains without the +.

I don’t know how to capture on the WAN side (between the gw and bridge) tcpdump shows me the router advertisements on the LAN side. I can’t even attach to the gw’s IPv6 address.

After you connected the network cable back, did you try waiting for the route to re-appear, if so for how long?

To capture the packets on the gateway (or any RouterOS interface, really) use its builtin packet sniffer: https://help.mikrotik.com/docs/display/ROS/Packet+Sniffer

Points of interest:

  • Does upstream regularly send Router Advertisements (I suspect yes) and at what intervals?
  • Does RouterOS sends Router Solicitation after you unplug / plug the cable?
  • Does the upstream reply to these solicitations?

After DAg route is lost it never comes back. With my setting the DAd is the one that stays.

Not sure how to answer your questions, I will need to research the packet sniffer (thanks for that) and get some details from the pcap file.

  • I see the gw IPv6 talk to ether1 about every 50 seconds.
  • when the network is unplugged I see router advertisement on the IPv6 clients. When it reconnected IPv6 clients only see neighbor-advertisement and neighbor-solicitation messages.

For this scenario it doesn’t matter what your local hosts see as the link we’re interested in is between the upstream and your mikrotik router.

I needed to research how to get the PacketSniffer TZNP into WireShark to help monitor. I can do that now and with my settings I only saw a one time RouterAdvertisement from the GW IP to ff02::1 after I reconnected the cable. All the other ICMPv6 on the ether1 connection are Neighbor Solicitations and Advertisements. So there were no RouterSolicitation messages to the GW IP

I will restore your settings tomorrow and see if that is different.

Did you see RouterOS to send Router Solicitation shortly after you unplugged / plugged the router cable? Did you see Router Advertisement sent back in response?

Normally hosts (and your mikrotik router is a host in the link with the gateway) don’t send Router Solicitations unless needed. From RFC 4861 - Neighbor Discovery in IPv6, Section 6.3.7:


  • The interface is reinitialized after a temporary interface
    failure or after being temporarily disabled by system
    management.

  • The host attaches to a link for the first time.

  • The host re-attaches to a link after being detached for some
    time.

In my opinion if the link is detached long enough for RouterOS to drop the default route, then it’s also enough time to re-send Router Solicitation.

No as I posted I didn’t see a RouterSolicitation. I will wait longer in my tests tomorrow, but 10 seconds has been enough to drop it.

If that test won’t show Router Solicitation then I suggest to report this as a bug at https://help.mikrotik.com/servicedesk/servicedesk explaining the flow and attaching the captured packets.