Is my upstream ISP sending me bad Router Advertisement?

I have recently started seeing repeated logs appearing in my CCR2004, related to the port that’s facing my ISP’s ONT.

radvd, warning    invalid mtu 1504 on sfpplus1 from fe80::b2a6:51ff:fe6c:d8e0

The log entries started at night after a brief outage, and I know my ISP tends to do maintenance during those hours, so it’s entirely plausible that they changed something.
Also for what it’s worth - the link-local address seems to suggest that it’s a Cisco device, which I don’t own any so unlikely it’s my own.

With that said, I’m not entirely familiar with radvd beyond the scope of my own network.
I did some googling and apparently this is ISP having RA enabled on the wrong interfaces. (?)

I’m not too familiar with ND beyond the scope of my own network, hoping to get some pointers:

  • my IPv6 connectivity seems unaffected, presumably this is fine to ignore?
  • “Accept Router Advertisements On” setting defaults to “all” in ROS, should that be disabled on my ISP interface since I’m getting a prefix through DHCPv6?
  • and what might the implication be with Accept RA disabled on the interface facing my ISP?

Accept Router Advertisements On ‘all’ is the default, BUT

Accept Router Advertisements ‘yes if forwading disabled’ is also the default. It seems you’ve changed this. Why?

If that warning message bothers you, increase the MTU value of sfpplus1 to >= 1504 (but still smaller than L2MTU of that interface). Or you can ignore that warning unless it overflows your log with hundreds of entries.

As for the need for /ipv6 settings set accept-router-advertisements=yes:

  • If your WANs only use PPPoE clients or other types of point-to-point connection, then you should keep the default accept-router-advertisements=yes-if-forwarding-disabled.

  • You have WAN interfaces that don't use PPPoE but use DHCP or static IP address on the IPv4 side, then you'll need accept-router-advertisements=yes.

    But it's preferable in that case to not keep accept-router-advertisements-on=all. Instead, create an interface list that contains only the non PPPoE WAN interfaces, then use that interface list as value for accept-router-advertisements-on=.

DHCPv6 normally do not provide the gateway / default route information. The gateway information must come from other sources. In case of point-to-point connections like PPPoE then the gateway is known to be the other side of the link. But if the WAN link is only ethernet, then you need to accept router advertisements.

Note: There is a hack from MikroTik that allows you to keep not accepting router advertisements. It's the "Add Default Route" checkbox in the DHCPv6 client setting. However this is not based on any real standard, but it's only RouterOS taking the address of the DHCPv6 server and use it as gateway address. Which might be the right address or not, depending on the ISP.

2 Likes

One of my ISPs sends me nothing via RAs, I have to use the MikroTik ‘trick’.

Those I haven’t changed - my ISP uses DHCP for both IPv4 and IPv6, presumably that has something to do with it?

Thank you for your detailed explanation!

My ISP uses DHCP for IPv4, so I’m trying to go down the accept-route-advertisements= route.

Do you know if setting MTU to 1504 would have any adverse effect on either IPv4/v6 traffic?
The spammy warning does go away after I’ve adjusted the MTU on that interface.

Interesting note about add-default-routeon DHCPv6 as well - not sure if my ISP is doing anything unusual / out-of-spec here, with RA presumably-now-working (with MTU 1504) and add-default-route disabled, the IPv6 route for ::/0 disappears and I lose IPv6 connectivity. :thinking:

And fwiw, the route that got added by add-default-routelook like this

    DST-ADDRESS               GATEWAY                             ROUTING-TABLE  DISTANCE
DAd ::/0                      fe80::b2a6:51ff:fe6c:d8e0%sfpplus1  main                  1

Is this a problem with the CCR2004 or something else…………….

1 Like

When in your LAN every other interfaces have the default MTU value of 1500 then your WAN having it set to a larger value will not cause any issue with forwarded traffic, because all clients will not send anything larger and the will also tell the remote side to not send anything bigger (besides, most remote hosts on the internet will not send IP packet larger than 1500 bytes anyway).

It will normally have an effect only when the router itself sends large packets to the internet. It might generate 1504-byte packets but usually TCP MSS and Path MTU Discovery working properly will propably means that the router will soon know to reduce the packet size.

As for turning of add-default-route on the DHCPv6 client cause the default route to go away although accept-router-advertisements=yes is set: Your ISP might be one of those that do not advertise any prefix with RA, only the gateway information. In that case there is an issue in RouterOS since 7.21 that results in the default route from RA not being installed (see the 7.21 and 7.21.1 threads) and currently you'll have to turn on add-default-route to have IPv6 connectivity, until MikroTik reverts the change in an update.

1 Like

Thank you for your detailed explanation, really helpful indeed.

I found your reply in 7.21, will keep an eye out there as well!

zneva, does the thumbs down mean>

  • the 2004 is not the problem?
  • RoS is the problem?
  • Op config is the problem?
  • ipv6 issue ?

Thumbs down is easy but why not just state the something else??

According to MikroTik, the RA bug should be fixed soon:

Once the new version is out, could you then retest with DHCPv6 Client's add-default-route=no and accept-router-advertisements=yes and accept-router-advertisements-on=WAN in IPv6 -> Settings to see if that was also the bug that you encountered?

1 Like

Wait, so I’ve bitched to my ISP for nothing?

They send RAs with M and O unset (the RA contains nothing else) AND they give me a prefix and an address via DHCPv6, obviously no route installed if I uncheck ‘add-default-route’ in the DHCPv6 client.

I still think that they need to set at least managed-configuration in the RAs.

Yes, they should set M when they give out address via DHCPv6. But this is not related to the default route. If RA lifetime is positive then the default route should be installed, regardless of whether there is any prefix (in RA message) or DHCPv6 server available.

1 Like

My ISPs set M but nothing else. 7.22rc1 has improvements that fix my particular error. Curious if yours is addressed as well.

Nope, and I don’t think that it should install a route in this case.

If the RA doesn’t contain a prefix and M=0 the router thinks that it has no reason to install a route since there’s no public prefix offered. Even if my ISP does provide one via DHCPv6. Probably MikroTik stops at does RA contain prefix? -no; ok, does it have M=1? -no; = K, NO ROUTE FOR YOU;

Even if it does contain router lifetime > 0.

They don’t check if the interface has a public IP.

And I don’t think they should change this behaviour.

I’ll keep bitchin to my ISP to fix their routers.

Nokia defaults M/O=0 for some reason and it looks like they didn’t bother changing the defaults.

However, I think RouterOS should still install the route even if M=0 and the RA has no prefix. Routes and address/prefix assignment are different things. If we read RFC4861, specifically the section:

  • 6.3.4. Processing Received Router Advertisements

    On receipt of a valid Router Advertisement, a host extracts the source address of the packet and does the following:

    • If the address is not already present in the host's Default Router List, and the advertisement's Router Lifetime is non-zero, create a new entry in the list, and initialize its invalidation timer value from the advertisement's Router Lifetime field.

    • If the address is already present in the host's Default Router List as a result of a previously received advertisement, reset its invalidation timer to the Router Lifetime value in the newly received advertisement.

    • If the address is already present in the host's Default Router List and the received Router Lifetime value is zero, immediately time-out the entry as specified in Section 6.3.5.

    To limit the storage needed for the Default Router List, a host MAY choose not to store all of the router addresses discovered via advertisements. However, a host MUST retain at least two router addresses and SHOULD retain more. Default router selections are made whenever communication to a destination appears to be failing.

  • 6.3.6. Default Router Selection

    This process mostly depends on the reachability of the router in the Default Router List populated from the received RA with non-zero RA Lifetime.

Then adding the router to the default router list only depends on "Router Lifetime" (RA Lifetime) being non-zero, not on the presence of the prefix information or the M flag. And criteria for the added default router to be used or not doesn't depend on those informations either.

1 Like

So you say that MikroTik should install a route even if the RA looks like this?

Yes, the router lifetime is advertised as 4500s (and has RA Preference Medium), so according to the RFC, fe80::1a5b:ff:feb9:fec9 should be added to the default router list. And a default router by definition provides a default route. The list in this case would also have only one item because no other host is sending RA.


Edit: We can open any of the major AI providers and give them this question:

Does ipv6 the router advertisements message need to have the prefix information and management flag to have a default route, or only a positive router lifetime suffices?

and they will all confirm that only RA Lifetime > 0 is required, neither the Prefix Information Option (PIO) nor the Management flags are needed. In this case I don't think that they all hallucinate and give out the same false information :wink:

Examples




Let’s hope that MikroTik will fix it then.

I’m still gonna bitch to my ISP about at least the Managed flag.

1 Like

I did have a chat with one can’t say it hallucinates.

To be clear: The M flag does not technically control the routing table. The "Router Lifetime" field controls the route.
However, your router is likely refusing to install the route because, without M=1 or a Prefix Option (PIO), it believes it has no valid method to acquire a WAN IP address. A compliant router will not start DHCPv6 if M=0 and O=0, leaving the interface unconfigured and the route useless.