Comment 7 for bug 1897115

> 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)

Does network-get treat RFC 1918 addresses in priority to non RFC 1918 address? Or the other way around, put lower priority on non RFC 1918 addresses?

If that's the case, that may explain the behavior that we see both addresses in the machine status, but only one address in network-get.

  "6":
    juju-status:
      current: started
      since: 23 Sep 2020 18:58:14+09:00
      version: 2.8.3
    dns-name: 133.X.X.X
    ip-addresses:
    - 133.X.X.X
    - 172.16.13.0
    instance-id: juju-d7d00e-6
...
    series: bionic
    network-interfaces:
      ens192:
        ip-addresses:
        - 133.X.X.X
        mac-address: XX:XX:XX:XX:XX:XX
        gateway: 133.X.X.X
        is-up: true
      flannel.1:
        ip-addresses:
        - 172.16.13.0
        mac-address: 06:4a:27:1b:ea:39
        is-up: true

> In your local testing, are you also only using Private addresses for both the host machines and for the flannel bridge?

I tested it with the following address mapping (both inside RFC 1918).

10.1.59.0 (flannel.1)
10.0.8.82 (eth0)

So the key is to use a global IP and flannel/32 IP? The issue is reproducible in the specific customer environment. Can you please investigate it further while coming up with a firm reproducer in a test env?

I see some test cases here with network-get. Would it be possible to test this scenario by extending it? > "a global IP and flannel/32 IP"
https://github.com/juju/juju/blob/2.8/worker/uniter/runner/jujuc/network-get_test.go