New provisioned servers get provisioning ip on all it's vlan's
Issue
= We just added 2 new compute profiles to our existing environment.
-
With this we provisioned 2x 3 new nodes to our cluster.
-
But once it's tries to register in satellite the deploy fails.
-
After some investigation we found that for some unknown reason Openstack placed the provisioning interface ip on all vlan's instead of using the ip's from the right subnet.
-
For example:
22: vlan3951: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 82:34:74:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global vlan3951
valid_lft forever preferred_lft forever
inet6 fe80::8034:74ff:fe1b:599/64 scope link
valid_lft forever preferred_lft forever
23: vlan3952: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 4a:2d:c7:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global vlan3952
valid_lft forever preferred_lft forever
inet6 fe80::482d:c7ff:fe4f:4d26/64 scope link
valid_lft forever preferred_lft forever
24: vlan3954: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 42:9c:09:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global vlan3954
valid_lft forever preferred_lft forever
inet6 fe80::409c:9ff:fe3e:d0a6/64 scope link
valid_lft forever preferred_lft forever
-
They all use the same ip what is not the purpose and it's not compliant with what is requested in the corresponding nic config file.
-
We also observed that this is coming because Openstack generated a wrong /etc/os-net-config/config.json:
{"network_config": [{"addresses": [{"ip_netmask": "192.168.0.2/24"}], "mtu": 1500, "name": "ens3f0", "routes": [{"ip_netmask": "169.254.169.254/32", "next_hop": "192.168.24.1"}], "type": "interface", "use_dhcp": false}, {"members": [{"bonding_options": "mode=802.3ad lacp_rate=fast resend_igmp=1 updelay=0 use_carrier=1 miimon=100 downdelay=0 xmit_hash_policy=layer2+3 primary_reselect=always fail_over_mac=none ad_select=stable", "dns_servers": ["10.10.255.252", "10.10.255.253"], "members": [{"mtu": 9000, "name": "eno5", "primary": true, "type": "interface"}, {"mtu": 9000, "name": "eno6", "type": "interface"}], "mtu": 9000, "name": "bond0", "type": "linux_bond"}, {"addresses": [{"ip_netmask": "192.168.0.2/24"}], "device": "bond0", "mtu": 9000, "type": "vlan", "vlan_id": 3952}, {"addresses": [{"ip_netmask": "192.168.0.2/24"}], "device": "bond0", "mtu": 9000, "type": "vlan", "vlan_id": 3951}, {"addresses": [{"ip_netmask": "192.168.0.2/24"}], "device": "bond0", "mtu": 9000, "type": "vlan", "vlan_id": 3955}, {"addresses": [{"ip_netmask": "192.168.0.2/24"}], "device": "bond0", "mtu": 9000, "routes": [{"default": true, "next_hop": "10.11.131.129"}], "type": "vlan", "vlan_id": 3954}], "name": "br-ex", "type": "ovs_bridge"}, {"defroute": false, "mtu": 9000, "name": "ens1f0", "type": "interface", "use_dhcp": false}, {"defroute": false, "mtu": 9000, "name": "ens1f1", "type": "interface", "use_dhcp": false}, {"defroute": false, "mtu": 9000, "name": "ens4f0", "type": "interface", "use_dhcp": false}, {"defroute": false, "mtu": 9000, "name": "ens4f1", "type": "interface", "use_dhcp": false}]}
-
It has only the 192.168.0.2 ip in it.
-
As this file is coming from swift we downloaded the swift data on the director and indeed, there we can see the same wrong content like above.
Environment
- Red Hat OpenStack Platform 13.0 (RHOSP)
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.