To Reproduce Steps to reproduce the behavior:

1. Create the BMH with a secret pointed in `preprovisioningNetworkDataName`. The secret contains the necessary to configure the ctlplane as a vlan interface.
2. During the deployment two interfaces are present:
   vlanXXXX
   ifname.XXXX
   Both of them conflict and make the node unreachable, causing the deployment to fail after the network configuration phase.

Expected behavior

• Only one interface configures the ctlplane network as a vlan. The other one should be cleaned.
• Deployment successful.

Bug impact

• Two cases from different accounts are showing the same behavior. One of them is heavily escalated.

Known workaround

• Manually deleting the vlanXXXX interface makes the deployment succeed.

Additional context

• It's weird that the cloud-init configuration does not correspond with the expected one:

links:

• name: ens21f0np0
  id: ens21f0np0
  type: vif
• name: ens21f0np0.202
  id: ens21f0np0.202
  type: vlan
  vlan_id: 202
  vlan_link: ens21f0np0
  vlan_mac_address: null
  networks:
• link: ens21f0np0.202
  id: ens21f0np0.202
  type: ipv4
  ip_address: 10.66.0.72
  netmask: "255.255.252.0"
  routes:
• network: 0.0.0.0
  netmask: 0.0.0.0
  gateway: 10.66.0.1
  services:
• type: dns-nameserver
  address:
• 10.67.1.114
  search:
• ctlplane.ae-auh1-1.core42.systemsversus

dns-resolver:
config:
server:

• 10.67.225.11
• 10.96.137.36
• 10.97.137.36
  interfaces:
• name: ens21f0np0
  type: ethernet
  state: up
  ipv4:
  enabled: false
• name: vlan202
  type: vlan
  state: up
  vlan:
  base-iface: ens21f0np0
  id: 202
  ipv4:
  enabled: true
  address:
• ip: 10.66.0.73
  prefix-length: 22
  routes:
  config:
• destination: 0.0.0.0/0
  next-hop-address: 10.66.0.1
  next-hop-interface: vlan202