New provisioned servers get provisioning ip on all it's vlan's

Solution In Progress - Updated -

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 of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In