As far as I know, at the moment (RoS 7.18.2 and 7.19rc2) we can treat IPv6 link local in two different ways:
As it always was done: the system creates on for us. We can´t change it, we can’t choose it directly. We can change the interface MAC address, and then the link local will be updated - but using that extremely complex obfuscating rules. We may as well say we can’t change it, not if we need a given one.
As of 7.17 (if I’m not mistaken) we can set the “Disable Link-Local-Address” option, on the IPv6 settings. NOW we have full control over the link local address, and can choose whatever the value we want. Beautiful. But (there is always one “but”)… Now we have to create the link local for EVERY new interface on the system. In fact, when we set this option, all the already existing values go POOF. A lot of work, a lot left to chance - since now we MUST remember to create the link local for everything, now and forever.
“Just don’t set the link local!”
I wish. Sometimes we need to do this. Sometimes is an ISP that force the customer to use a given one. Sometimes is a peer that wants/needs a fixed one. Problem is: now, because of one single corner case, the user have to keep setting the link local forever. Not good.
So, the question: is there any way to edit this thing, that doesn’t force me to forever create link local to a new interface?
Doesn’t the relatively new auto-link-local address option allow you to manually create one and override the dynamically created? At least that’s how I interpret the description of the parameter in the docs
I tried it and either I didn´t understand how it works, or is bugged.
Set the “Disable Link-Local-Address” option
Create a new address, with the option “auto-link-local address” checked
Now I have a new IPv6 address on my interface, but no link local.
I can create a link local address (either before or later), but I couldn’t find a way to create the link local AND the normal address at the same time. Not with the “Disable Link-Local-Address” option set.
I would try with “Disable link-local address” off and “Auto link-local” on and see what the behavior of the parameter - does it remove the auto generated link-local address for the interface, do they coexist but one gets preferred over the other, etc.
This is the way I always used. It keeps the original link local, and just add the normal address.
If I enable the “Disable link-local address” (I hate double negative in parameters) the normal address is created, but not the link local.
On the command line (through ssh, RoS 7.18.2, CHR)
The line
/ipv6/address> add address=fd55:ad17:8e8d:b000::230/64 interface=mwahaha auto-link-local=yes
Sets the address fd55:ad17:8e8d:b000::230/64 to the bridge called mwahahaha.
BUT it doesn’t set the link local address.
The line
/ipv6/address> add address=fe80::230/64 interface=mwahaha auto-link-local=yes
Sets the link local address fe80::230/64 to the bridge called mwahahaha
If you read the documentation for the “auto-link-local” parameter, it does clearly state the following:
If newly created address is manual link-local address this setting allows to override dynamically created IPv6 link-local address.
Which is (almost) exactly the behavior you described. So, I think the intended use of this parameter is that you leave “disable-link-local-address” as “no”, and then you simply add fe80::/10 address of your choice to the interface whose auto-generated link-local you want to override with a custom one, with “auto-link-local=no” set on the fe80:: address.
I just tested this (7.18.2), and it works: if I leave “disable-link-local-address=no”, and then add fe80::1234 to a random interface, with “auto-link-local=yes”, then it adds an additional link-local address (the custom one), without removing the auto-generated one. If I then change “auto-link-local=no” on the custom address, the auto-generated address disappears on that one interface. But all of the auto-gen addresses on the other interfaces still remain. Which it sounds like is the exact behavior you want: to be able to override just a single address on a single interface, but still have it auto-generate them for the others.
You said you saw this happen with “auto-link-local=yes” which is why I said “(almost) exactly”. I cannot reproduce your results. And my own experiments resulted in the opposite behavior. So I am wondering if maybe you did not typo something in your latest post.
I did read the documentation. To say it’s lacking is an understatement. I could get to the point of the second link local address, but couldn’t get rid of it. Because, of course, the solution is to create a second one, change the parameter on the second in order to erase the first. Cristal clear, just the most logical thing to do. Shame on me for not thinking about it.
Yes, doing it this bizarre and convoluted way works. It would be easier for them just let me edit the auto generated one, and mark it as “static” from now on. But no, we have to do this whole dancing.
30 seconds of internal seething and screaming at the heavens later
There is a better way. You DID read the documentation, didn’t You?
There is clearly stated “If newly created address is manual link-local address this setting allows to override dynamically created IPv6 link-local address.”
Just add the link local address with the “auto-link-local” = no. It will overwrite the original fe80, without all that faff of deleting it and all.
Like this (on a throwaway VM, don’t get started on the “admin” user).
[admin@MikroTik] > /ipv6/settings/print
disable-ipv6: no
forward: yes
multipath-hash-policy: l3
accept-redirects: yes-if-forwarding-disabled
accept-router-advertisements: yes-if-forwarding-disabled
disable-link-local-address: no
stale-neighbor-detect-interval: 30
stale-neighbor-timeout: 60
min-neighbor-entries: 4096
soft-max-neighbor-entries: 8192
max-neighbor-entries: 16384
allow-fast-path: yes
ipv6-fast-path-active: yes
ipv6-fast-path-packets: 0
ipv6-fast-path-bytes: 0
ipv6-fasttrack-active: no
ipv6-fasttrack-packets: 0
ipv6-fasttrack-bytes: 0
[admin@MikroTik] >
[admin@MikroTik] >
[admin@MikroTik] > /interface/bridge/add name=validatingLL
[admin@MikroTik] > /ipv6/address/print
Flags: D - DYNAMIC; L - LINK-LOCAL
Columns: ADDRESS, INTERFACE, ADVERTISE
# ADDRESS INTERFACE ADVERTISE
0 D ::1/128 lo no
1 DL fe80::5054:ff:fefa:eaf2/64 ether1 no
2 DL fe80::b8b7:51ff:fe30:9e73/64 validatingLL no
[admin@MikroTik] >
[admin@MikroTik] >
[admin@MikroTik] > /ipv6/address/add auto-link-local=no address=fe80::666 interface=validatingLL advertise=no
[admin@MikroTik] > /ipv6/address/print
Flags: D - DYNAMIC; L - LINK-LOCAL
Columns: ADDRESS, INTERFACE, ADVERTISE
# ADDRESS INTERFACE ADVERTISE
0 D ::1/128 lo no
1 DL fe80::5054:ff:fefa:eaf2/64 ether1 no
2 L fe80::666/64 validatingLL no
Bonus points:
If we remove the custom link local address, the system restores the original one.
The behavior of 1) is kept, even after reboot.
So, thank you for pointing me on the right direction.
Not so happy about the condescending tone. We can always misread things, as You just did.
I literally quoted that exact same sentence from the documentation in my reply.
But of course.
I was not trying to communicate that you had to add the address first, and then change the parameter after adding it. I was merely explaining that I tried to manually create a fe80:: address both with and without that setting enabled, and that in my tests, it seemed to behave in the opposite way that you described in the post of yours that I was replying to, where you said that…
…caused the router to “Sets the link local address fe80::230/64 to the bridge called mwahahaha”. You didn’t say it added a second one when you used auto-link-local=yes, you said it “SETS” “the” (implying one, not two) link-local address on the interface. So your post sounded like you were trying to say that the auto-link-local parameter behaves on your router the opposite way it is supposed to behave, where making it =yes CHANGES (“SETS”) the address, but =no ADDS an additional one. IF that had been the case, then I would have said YES, that would clearly seem to be a bug. But now it seems as though perhaps either you misstated what you observed, or I misunderstand your use of language here.
As far as setting auto-link-local at creation or changing it later, I didn’t think I needed to clarify that of course both work. I can’t think of a single parameter on an object in RouterOS that can’t be explicitly set at the time of creation? Again, I was just demonstrating that toggling that parameter back-and-forth on an existing object resulted in exactly the opposite behavior of how you seemed to be describing how it worked on your router. That you can set auto-link-local=no at creation time and don’t need to create the new address first just seems like common sense to me…