I'm a bit surprised to see all the devices listed 2x, but maybe it is just IPv4 vs IPv6, since the first case is 127.* and then ::1, and the second is 172.* and nothing. (But if it was just IPv6, then why would we report a device at all if it didn't have an address? Maybe we start thinking about the link local fe80 but then discard it late?)
My best guess is that 172.16.8.0 is considered ScopeCloudLocal but so is 10.*. Since both of them come from RFC 1918 (https://tools.ietf.org/html/rfc1918) as private addresses. (As are 192.168/16 addresses)
In your local testing, are you also only using Private addresses for both the host machines and for the flannel bridge?
I don't see why we wouldn't be returning both addresses from the wider 'network-get' call.
I'm a bit surprised to see all the devices listed 2x, but maybe it is just IPv4 vs IPv6, since the first case is 127.* and then ::1, and the second is 172.* and nothing. (But if it was just IPv6, then why would we report a device at all if it didn't have an address? Maybe we start thinking about the link local fe80 but then discard it late?)
My best guess is that 172.16.8.0 is considered ScopeCloudLocal but so is 10.*. Since both of them come from RFC 1918 (https:/ /tools. ietf.org/ html/rfc1918) as private addresses. (As are 192.168/16 addresses)
In your local testing, are you also only using Private addresses for both the host machines and for the flannel bridge?
I don't see why we wouldn't be returning both addresses from the wider 'network-get' call.