So, I was debugging why some customers are not getting IPv6 with PPPoE and DHCPv6
What I’ve noticed is that every SXT that is not getting the prefix delegation, are showing us the same DUID.
I’ve checked twice the MAC Address and already did reset the mac-address of the ethernet interface…
I don’t know why this is happening…
Here is the print detail:
/ipv6 dhcp-client print detail
Flags: D - dynamic, X - disabled, I - invalid
0 interface=bnet-PPPoE status=bound duid="0x00030001000c42f2c180" dhcp-server-v6=fe80::f0:184 request=prefix add-default-route=yes default-route-distance=1 use-peer-dns=yes pool-name="ipv6-pool" pool-prefix-length=64 prefix-hint=::/0
dhcp-options=""
At the server, I can see this:
01:40:12 echo: dhcp,debug binding belongs to other server: 000c42f2c180 2001:db8:8181:300::/56
01:40:12 echo: dhcp,debug binding not updated
01:40:12 echo: dhcp,debug processing client:000c42f2c180 iapd:0x6
01:40:12 echo: dhcp,debug binding belongs to other server: 000c42f2c180 2001:db8:8181:300::/56
01:40:12 echo: dhcp,debug binding not updated
01:40:12 echo: dhcp,debug processing client:000c42f2c180 iapd:0x6
01:40:12 echo: dhcp,debug binding belongs to other server: 000c42f2c180 2001:db8:8181:300::/56
01:40:12 echo: dhcp,debug binding not updated
01:40:12 echo: dhcp,debug processing client:000c42f2c180 iapd:0x6
01:40:12 echo: dhcp,debug binding belongs to other server: 000c42f2c180 2001:db8:8181:300::/56
01:40:12 echo: dhcp,debug binding not updated
So, could you guys help me how to fix those duplicated DUID on these devices?
Thanks a lot!
How did you initially configure those devices? Did you make a backup of a configured device and restore that on a new device?
That is definitely a no-no. Never do that!
Try to do a full factory reset on one of the problematic devices, configure it manually or at most by pasting some /export’ed lines without any things like MAC addresses, and see if it resolves the issue.
OK, that’s exactly what I’m suspecting.
I’ll reset and apply a script to reconfigure everything, but, if it is this, maybe some technicians did a backup and put backup on others…
But like I said, I already did a reset at the Ethernet mac-address.
Maybe Mikrotik need to recalculate DUID after this behavior, otherwise, I’ll need to reset a lot of devices which will be painful.
It could be enough to remove and re-add the dhcp6 client after you have reset the MAC.
There does not appear to be a set duid…
Of course you never know what other surprises like this exist in your restored devices, but that is only a theoretical issue.
I already tried this.
No go…
DUID is always the same.
Even rebooting the device
Even with ethernet reset-mac-address
Even after reset-mac-address deleting and adding again DHCP-Client
By default WLAN is not copied with backup procedure.
I know that because we always add mac-address to the access-list, so, if WLAN MAC was duplicated, our system would report.
We can find a device by WLAN mac, so, the only other MAC that could be duplicated (which is when we backup and restore) is ethernet.
I have also sometimes worried that there is configuration inside the router (and then also in a backup) which is not represented in a /export.
Apparently this is one example of such a thing.
That can cause severe hairpulling when you are looking for a problem that does not show up anywhere in the readable user interface.
Well, at least now you know how to solve it, the issue of course is how to do it without too much effort.
In theory you can /export the config to a file, then do a reset to defaults with import of that file.
This used to work fine (I did it in the past on like 6.39) but unfortunately it no longer works and MikroTik is not applying the easy fix.
The problem is that the import of the script starts immediately after boot, and the hardware referenced in the /export is not yet ready then.
This can be fixed by adding a /delay 30 at the top of the exported file, but of course that means you need to download, edit and upload each
of those files, which makes automation yet again harder.
Of course MikroTik should include that delay inside RouterOS itself, but they don’t.
I would advise you to report the issue to support@mikrotik.com and refer to this topic.
Unfortunately you can read only an entire file in a single chunk and the variable that will read it has a maximum of 4K.
So this is only possible when your export is smaller than 4K. Which could be, for some rudimentary configurations.
In that case you can make a script that reads the file, and then writes it with that extra line at the top.
