On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote:

On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net> wrote:

On 02/16/2017 12:54 AM, Tony Mountifield wrote:

In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
Alice Wonder <al...@domblogger.net> wrote:


I can not figure out what I need to do.

Apparently according to linode support, the VM is trying to grab an
address with some privacy stuff enabled by default causing it to not
grab the IPv6 address that is assigned to me.

Does the accepted answer at the following link give you any useful



Not really - I tried

net.ipv6.conf.all.use_tempaddr = 0

and it still fails to grab the proper IPv6


Just in case, I did ask Linode support to verify that my hardware address
what it is suppose to be. Still waiting to hear on that.


it still is key=value  ... it uses the ifcfg- files (via the rh
plugin) and they are all key=value

It would be helpful if you could paste the journal output (journalctl
-u NetworkManager) from the time period of attempting to get an
address ...

also the nmcli conn sh <connection_name> information for the interface
along with your ifcfg- files

ifcfg-lo is the only one that exists on any of the servers - including the
VMs that grab the correct IPv6 address.

from /sbin/ifconfig -a :

For a start stop using ifconfig ... it's broken at this point on
linux, especially on multi ip and ipv6 scenarios

Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see
all IP address stuff regardless of family

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::a8ad:d312:4ef4:7272  prefixlen 64  scopeid 0x20<link>
        inet6 2a01:7e00::825f:e564:ad53:72fc  prefixlen 64  scopeid
        ether f2:3c:91:18:8a:7e  txqueuelen 1000  (Ethernet)
        RX packets 9903  bytes 1088621 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7786  bytes 1087223 (1.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

That hardware address - the 18:8a:7e corresponds with what the IPv6 address
is suppose to be. But that's not the address it is grabbing, despite the
fact that net.ipv6.conf.all.use_tempaddr = 0 is set.

I'm seriously wondering if the real issue is a mis-configured dhcp server in
their London facility because nothing makes sense.

journalctl -u NetworkManager

reports no journal entries found.

So are you not using NetworkManager then? there should be some logs ...

I think the problem must be on their end.

It all was working fine until they migrated the VM because of a hardware
issue, and I suspect now all the hardware address privacy stuff being the
issue is barking up the wrong tree because all the reading I have done seems
to indicate that with

net.ipv6.conf.all.use_tempaddr = 0

that a fake temporary hardware address would not be sent to their dhcp
server when obtaining the address, but the real one, that should be fetching
my assigned address.

Only if the kernel is doing SLAAC ... if other things (eg NM) are
handling it directly they may act differently ... but then from the
lack of logs is NM actually handling this?

Does systemctl status NetworkManager show it running and does nmcli
show anything?

systemctl status NetworkManager
‚óŹ NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2017-02-16 08:19:34 UTC; 2h 19min ago

* more stuff *

eth0: connected to Wired connection 1
        "Red Hat Virtio network device"
        ethernet (virtio_net), F2:3C:91:18:8A:7E, hw, mtu 1500
        ip4 default, ip6 default
        inet6 2a01:7e00::825f:e564:ad53:72fc/64
        inet6 fe80::a8ad:d312:4ef4:7272/64
        route6 2a01:7e00::/64

* more stuff for other interfaces *


The output of

sysctl -a | grep net.ipv6 :


It looks from that like it should not be hiding the real MAC address.

It's all very frustrating but I suspect now the problem isn't the CentOS
network configuration.

Sounds likely ... depending on what there RA's say and how dhcpv6 is
being handled there (if at all) it could drastically affect things -
particularly if MAC changed on migration.

Five other servers all configured the same (started from same CentOS 7 image
and network stuff left alone) work properly - so I don't know.

CentOS mailing list

CentOS mailing list

Reply via email to