[enterprise-4.19] : Added note about bonded interface and node IP address …

installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc

@@ -34,6 +34,11 @@ include::modules/creating-scaling-machine-sets-compute-nodes-networking.adoc[lev
 // Establishing communication between subnets
 include::modules/ipi-install-establishing-communication-between-subnets.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../installing/installing_bare_metal/ipi/ipi-install-installation-workflow.adoc#modifying-install-config-for-dual-stack-network_ipi-install-installation-workflow[Configuring host network interfaces]
+
 // Retrieving the {product-title} installer
 include::modules/ipi-install-retrieving-the-openshift-installer.adoc[leveloffset=+1]
 

modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc

@@ -6,7 +6,7 @@
 [id="configuring-host-network-interfaces-in-the-install-config-yaml-file_{context}"]
 = Configuring host network interfaces
 
-Before installation, you can set the `networkConfig` configuration setting in the `install-config.yaml` file to configure host network interfaces using NMState.
+Before installation, you can set the `networkConfig` configuration setting in the `install-config.yaml` file to use NMState to configure host network interfaces.
 
 The most common use case for this functionality is to specify a static IP address on the bare-metal network, but you can also configure other networks such as a storage network. This functionality supports other NMState features such as VLAN, VXLAN, bridges, bonds, routes, MTU, and DNS resolver settings.
 
@@ -17,36 +17,35 @@ The most common use case for this functionality is to specify a static IP addres
 
 .Procedure
 
-. Optional: Consider testing the NMState syntax with `nmstatectl gc` before including it in the `install-config.yaml` file, because the installer will not check the NMState YAML syntax.
+. Optional: Consider testing the NMState syntax with `nmstatectl gc` before including the syntax in the `install-config.yaml` file, because the installation program does not check the NMState YAML syntax.
 +
 [NOTE]
 ====
-Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes using Kubernetes NMState after deployment or when expanding the cluster.
+Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes by using Kubernetes NMState after deployment or when expanding the cluster.
 ====
 
-
 .. Create an NMState YAML file:
 +
 [source,yaml]
 ----
-interfaces:
-- name: <nic1_name> <1>
+interfaces: <1>
+- name: <nic1_name>
   type: ethernet
   state: up
   ipv4:
     address:
-    - ip: <ip_address> <1>
+    - ip: <ip_address>
       prefix-length: 24
     enabled: true
 dns-resolver:
   config:
     server:
-    - <dns_ip_address> <1>
+    - <dns_ip_address>
 routes:
   config:
   - destination: 0.0.0.0/0
-    next-hop-address: <next_hop_ip_address> <1>
-    next-hop-interface: <next_hop_nic1_name> <1>
+    next-hop-address: <next_hop_ip_address>
+    next-hop-interface: <next_hop_nic1_name>
 ----
 +
 <1> Replace `<nic1_name>`, `<ip_address>`, `<dns_ip_address>`, `<next_hop_ip_address>` and `<next_hop_nic1_name>` with appropriate values.
@@ -77,24 +76,24 @@ Replace `<nmstate_yaml_file>` with the configuration file name.
         rootDeviceHints:
           deviceName: "/dev/sda"
         networkConfig: <1>
-          interfaces:
-          - name: <nic1_name> <2>
+          interfaces: <2>
+          - name: <nic1_name>
             type: ethernet
             state: up
             ipv4:
               address:
-              - ip: <ip_address> <2>
+              - ip: <ip_address>
                 prefix-length: 24
               enabled: true
           dns-resolver:
             config:
               server:
-              - <dns_ip_address> <2>
+              - <dns_ip_address>
           routes:
             config:
             - destination: 0.0.0.0/0
-              next-hop-address: <next_hop_ip_address> <2>
-              next-hop-interface: <next_hop_nic1_name> <2>
+              next-hop-address: <next_hop_ip_address>
+              next-hop-interface: <next_hop_nic1_name>
 ----
 <1> Add the NMState YAML syntax to configure the host interfaces.
 <2> Replace `<nic1_name>`, `<ip_address>`, `<dns_ip_address>`, `<next_hop_ip_address>` and `<next_hop_nic1_name>` with appropriate values.

modules/ipi-install-establishing-communication-between-subnets.adoc

@@ -8,7 +8,12 @@
 
 In a typical {product-title} cluster setup, all nodes, including the control plane and compute nodes, reside in the same network. However, for edge computing scenarios, it can be beneficial to locate compute nodes closer to the edge. This often involves using different network segments or subnets for the remote nodes than the subnet used by the control plane and local compute nodes. Such a setup can reduce latency for the edge and allow for enhanced scalability.
 
-Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too.
+Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too. 
+
+[IMPORTANT]
+====
+During cluster installation, assign permanent IP addresses to nodes in the network configuration of the `install-config.yaml` configuration file. If you do not do this, nodes might get assigned a temporary IP address that can impact how traffic reaches the nodes. For example, if a node has a temporary IP address assigned to it and you configured a bonded interface for a node, the bonded interface might receive a different IP address.
+====
 
 You can run control plane nodes in the same subnet or multiple subnets by configuring a user-managed load balancer in place of the default load balancer. With a multiple subnet environment, you can reduce the risk of your {product-title} cluster from failing because of a hardware failure or a network outage. For more information, see "Services for a user-managed load balancer" and "Configuring a user-managed load balancer".