"ipv6 address from-pool" lost after reboot

RouterOS General
1

I’d like to have multiple IPv6 addresses using “from-pool” on the same interface. If the have the same “address=…” specified, only one of them survives a reboot. Minimal working example (tested in RouterOS 7.11.2, but I’ve seen this behaviour already in RouterOS 6):

# before reboot
/interface bridge add name=bridge
/ipv6 pool add name=pool1 prefix=fd01::/64 prefix-length=64
/ipv6 pool add name=pool2 prefix=fd02::/64 prefix-length=64
/ipv6 address add address=::1 from-pool=pool1 interface=bridge
/ipv6 address add address=::1 from-pool=pool2 interface=bridge

Even though initially this works fine, after rebooting the second address is lost and all I have is

# after reboot
/interface bridge add name=bridge
/ipv6 pool add name=pool1 prefix=fd01::/64 prefix-length=64
/ipv6 pool add name=pool2 prefix=fd02::/64 prefix-length=64
/ipv6 address add address=::1 from-pool=pool1 interface=bridge

If I use different “address=…”, both addresses survive the reboot:

# this configuration survives reboots
/interface bridge add name=bridge
/ipv6 pool add name=pool1 prefix=fd01::/64 prefix-length=64
/ipv6 pool add name=pool2 prefix=fd02::/64 prefix-length=64
/ipv6 address add address=::1 from-pool=pool1 interface=bridge
/ipv6 address add address=::2 from-pool=pool2 interface=bridge

Is there a good reason why I should avoid using ::1 for both addresses? Or is this a bug in RouterOS?

Thanks,
Hendrik

2

Have a single aggregated pool of the entire /56 or whatever, then use the ::1, ::2… On each different VLAN/Interface, that should work fine.

3

Using a single pool is not an option here. We have a few thousand devices and each has it’s own fd10:x:y:z::/64 prefix. In certain environments, we need an additional network that we can advertise to hosts, and this can’t be in the fd10::/16 range.

4

This sounds like a problematic approach, IMO. I’d suggest giving this a read and re-doing the design:
http://forum.mikrotik.com/t/how-to-edge-router-and-bng-optimization-for-isps/150007/1

5

I know that article and I understand why you advocate using a larger net. For most applications that is definitely the way to go. But we have lots of other constrains that I didn’t mention here, some of which we don’t have control over. Mobile carriers limiting us to ::/64 per SIM card is only one example.

So I’d like to stop this discussion here and come back to the question I asked.

6

That’s not the problem at all. The issue here is, you aren’t aggregating your ULA into a single pool. The mobile carrier’s /64, you can just use NAT66 or NPTv6 for that whatever. But aggregate the pool, then configure the ULA /64 on per VLAN basis. It will work fine on reboot.

7

Sorry, but that’s wrong. Again: You don’t know all constrains and that’s okay. Please accept that. I’ve used these ULAs here to create a simple minimal example. Reality is more complex.

All I want to know is why in the first case only one address survives the reboot while in the second case both addresses survive the reboot.

8

AFAIK, it’s an acknowledged bug. I reported it back in June (SUP-118219) and was told by Sergejs B.:

Thank you for the report, we are aware of the particular problem, hopefully it will be fixed shortly.

Please report this again at https://help.mikrotik.com.


That being said, I recommend 2 adjustments:


  1. Global IDs should be generated randomly, per RFC 4193 recommendation
  2. Use eui-64=yes instead of address=

I understand the lure of having easy to remember addresses in ULA, but hold off this urge.

9

Thanks a lot! I’ll report it, too.

EDIT: reported as SUP-131641.

These are two valid points, but:

  • Using eui64=yes triggers this bug, because it assigns the same (eui64-based) address= to both /ipv6/address entries, causing one of them to get lost during reboot. So setting address= explicitly is the only work-around I know at the moment.
  • I know that global IDs should be generated randomly. We have several thousand remote devices in multi-homed environments with LTE connections (two modems with SIM cards from two different carriers) and for about 20% of the devices we also have DSL or some other kind of customer provided internet connection with we use to establish VPN connections into our network. For the SIM cards we have a /47 address space per carrier (these are ULAs and routed straight into our company network, no internet access at all) and can use them to assign static /64 prefixes to the individual SIM cards. This restricts us to 2^17 /64 prefixes per mobile carrier. With the number of devices we have, random assignment is not practical since we fill a significant amount of the available address space. That’s why we chose to assign the prefixes based on device serial numbers.

Yes, that means that most of the “Global ID” part is fixed and not controlled by us. And no, the carriers are very reluctant to hand out larger address spaces. Apparently they run into memory limits for the routing tables on their towers.

10

Using eui64=yes triggers this bug, because it assigns the same (eui64-based) address= to both /ipv6/address entries, causing one of them to get lost during reboot. So setting address= explicitly is the only work-around I know at the moment.

Interesting. I was pretty sure it worked before.