IPMI IPv6 link local addresses are overwritten with (unusable) IPv4 addresses

Users
,
1

Hello!

I’m currently trying to setup some servers using MAAS in an IPv6 - only network.

I’m using the MAAS API to set up servers and provide IPMI configuration (IP address, username, password). Everything works fine until the end of the commission. Then ‘suddenly’ the valid and working IPv6 link local address is overwritten by an (unusable) IPv4 address, like:

# maas maas_user machines power-parameters
Success.
Machine-readable output follows:
{
    "asw77q": {
        "k_g": "",
        "power_pass": "XYZ",
        "power_user": "maas",
        "power_driver": "LAN_2_0",
        "power_address": "192.168.0.120",
        "cipher_suite_id": "3",
        "power_boot_type": "efi",
        "privilege_level": "ADMIN",
        "mac_address": "B0:8B:35:AE:B4:56"
    },
...

BTW: IPv4 is explicitly disabled on the IMPI.

Does somebody know where / when / why this change happens? Is there a way to switch off this automatic update of the IPMI IP address as the original perfectly works? (Manually (via GUI) changing the IP back to the IPv6 address enables me to install the servers.)

Using Ubuntu 20.04 LTS and MAAS 2.9.2

Kind regards - Andre

2

Upgraded to MAAS 3.0: also there the same problem.

3

Hi, could you please attach the output from the following commissioning scripts: 50-maas-01-commissioning, 30-maas-01-bmc-config for that machine?

4

Attached the output of 30-maas-bmc.config.

Can you please be a bit more specific about the 50-maas-01-commissioning output? There are some information which I don’t want to post, like network addresses or serial numbers. The server is a Dell R640 and some month old.

BTW.: I found a workaround: setting the IMPI address (power_parameters_power_address) again after the commissioning stage works for me.

```
INFO: Loading IPMI kernel modules...
INFO: Checking for HP Moonshot...
INFO: Checking for IPMI...
INFO: IPMI detected!
INFO: Reading current IPMI BMC values...
INFO: Configuring IPMI Lan_Channel...
INFO: Configuring IPMI Lan_Channel_Auth...
INFO: Lan_Channel_Auth settings unavailable!
INFO: Configuring IPMI cipher suite ids...
INFO: Gathering supported cipher suites and current configuration...
INFO: BMC supports the following ciphers - [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14]
INFO: Current cipher suite configuration - XXXaXXXXaXXXaXX
INFO: New cipher suite configuration - XXXaXXXXaXXXaXX
INFO: MAAS will use IPMI cipher suite id "3" for BMC communication
WARNING: No K_g BMC key found or configured, communication with BMC will not use a session key!
INFO: Configuring IPMI Serial_Channel...
INFO: Serial_Channel settings unavailable!
INFO: Configuring IPMI SOL_Conf...
INFO: Found existing IPMI user "maas"!
INFO: Configuring IPMI BMC user "maas"...
INFO: IPMI user number - User4
INFO: IPMI user privilege level - Administrator
INFO: IPMI Version - LAN_2_0
INFO: IPMI boot type - efi
```
5

Feel free to redact sensitive information. I think the most interesting part is the "networks" section from that output, which contains interfaces and IPs during commissioning.

6

Here is the networks part of the output.
I don’t care about the IPv4 addresses - but changed
the IPv6 link local addresses and the MAC addresses.

Kind regards - Andre

"networks": {
    "eno1np0": {
        "addresses": [
            {
                "family": "inet",
                "address": "172.30.2.42",
                "netmask": "24",
                "scope": "global"
            },
            {
                "family": "inet6",
                "address": "fe80::be97:70ff:fec0:f656",
                "netmask": "64",
                "scope": "link"
            }
        ],
        "counters": {
            "bytes_received": 441203633,
            "bytes_sent": 953565,
            "packets_received": 293039,
            "packets_sent": 9349
        },
        "hwaddr": "bc:97:70:c0:f6:56",
        "mtu": 1500,
        "state": "up",
        "type": "broadcast",
        "bond": null,
        "bridge": null,
        "vlan": null
    },
    "eno2np1": {
        "addresses": [
            {
                "family": "inet",
                "address": "172.30.2.43",
                "netmask": "24",
                "scope": "global"
            },
            {
                "family": "inet6",
                "address": "fe80::be97:24ff:fe1a:6827",
                "netmask": "64",
                "scope": "link"
            }
        ],
        "counters": {
            "bytes_received": 7608,
            "bytes_sent": 2310,
            "packets_received": 82,
            "packets_sent": 20
        },
        "hwaddr": "bc:97:24:1a:68:27",
        "mtu": 1500,
        "state": "up",
        "type": "broadcast",
        "bond": null,
        "bridge": null,
        "vlan": null
    },
    "lo": {
        "addresses": [
            {
                "family": "inet",
                "address": "127.0.0.1",
                "netmask": "8",
                "scope": "local"
            },
            {
                "family": "inet6",
                "address": "::1",
                "netmask": "128",
                "scope": "local"
            }
        ],
        "counters": {
            "bytes_received": 62815,
            "bytes_sent": 62815,
            "packets_received": 729,
            "packets_sent": 729
        },
        "hwaddr": "",
        "mtu": 65536,
        "state": "up",
        "type": "loopback",
        "bond": null,
        "bridge": null,
        "vlan": null
    }
}
7

@florath, doesn’t look like you got a response to this last. did you ever figure it out?

8

No - still using the ‘workaround’: re-setting the address after it changed magically.

9

okay, please file a bug; there might be some IPv6 issue causing this; at the very least, if you have misconfigured something, filing a bug will get it a deeper look.