OSDOCS-14356-New: Added bond best practices info to networking docs

modules/installation-network-user-infra.adoc

@@ -87,9 +87,17 @@ endif::ibm-z[]
 ifndef::ibm-z[]
 During the initial boot, the machines require an IP address configuration that is set either through a DHCP server or statically by providing the required boot options. After a network connection is established, the machines download their Ignition config files from an HTTP or HTTPS server. The Ignition config files are then used to set the exact state of each machine. The Machine Config Operator completes more changes to the machines, such as the application of new certificates or keys, after installation.
 
+Use a DHCP server for the long-term management of the machines for your cluster. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines. As a cluster administrator, ensure that you reserve the following IP addresses components that interact with the DHCP server:
+
+* Two unique virtual IP (VIP) addresses. One VIP address for the API endpoint and one VIP address for the wildcard ingress endpoint.
+* One IP address for the provisioner node. 
+* An IP address for each control plane node.
+* An IP address for each compute node.
+If you have multiple network interfaces that interact with a bonded interface, reserve the same IP addresses for these multiple network interfaces so to ensure better load balancing, fault tolerance, and bandwidth capabilites for your cluster network infrastructure. 
+
 [NOTE]
 ====
-* It is recommended to use a DHCP server for long-term management of the cluster machines. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines.
+* Use a DHCP server for long-term management of the cluster machines. Ensure that the DHCP server is configured to provide persistent IP addresses, DNS server information, and hostnames to the cluster machines.
 
 * If a DHCP service is not available for your user-provisioned infrastructure, you can instead provide the IP networking configuration and the address of the DNS server to the nodes at {op-system} install time. These can be passed as boot arguments if you are installing from an ISO image. See the _Installing {op-system} and starting the {product-title} bootstrap process_ section for more information about static IP provisioning and advanced networking options.
 ====

modules/installation-user-infra-machines-static-network.adoc

@@ -220,7 +220,20 @@ ifndef::ibm-z-kvm[]
 [discrete]
 === Bonding multiple network interfaces to a single interface
 
-Optional: You can bond multiple network interfaces to a single interface by using the `bond=` option. Refer to the following examples:
+As an optional configuration, you can bond multiple network interfaces to a single interface by using the `bond=` option. To apply this configuration to your cluster, complete the procedure steps for each node that runs on your cluster.
+
+[IMPORTANT]
+====
+A bonding mode specifies the policy for how bond interfaces are used during network transmission. If your network configuration includes an Open vSwitch (OVS) interface and you enabled `active-backup` bond mode, you must specify a Media Access Control (MAC) address failover. This configuration prevents node communication issues with the bond interfaces, such as `eno1f0` and `eno2f0`.
+
+The following list details supported values for the `fail_over_mac` parameter:
+
+* `0`: Specifies the `none` value and this is the default value that disables MAC address failover so that all nodes receive the same MAC address as the bond interface. With this setting, packets might be sent to inactive nodes.
+* `1`: Specifies the `active` value and sets the MAC address of the primary bond interface to always remain the same as active nodes. If during a failover, the MAC address of a node changes, the MAC address of the bond interface changes to match the new MAC address of the node.
+* `2`: Specifies the `follow` value so that during a failover, an active node gets the MAC address of the bond interface and a formerly active node receives the MAC address of the newly active node.
+====
+
+.Procedure
 
 * The syntax for configuring a bonded interface is: `bond=<name>[:<network_interfaces>][:options]`
 +
@@ -235,7 +248,7 @@ information for the bonded interface.
 [source,terminal]
 ----
 bond=bond0:em1,em2:mode=active-backup
-ip=bond0:dhcp
+fail_over_mac=1
 ----
 
 ** To configure the bonded interface to use a static IP address, enter the specific IP address you want and related information. For example:
@@ -266,7 +279,6 @@ Optional: You can configure VLANs on bonded interfaces by using the `vlan=` para
 
 [source,terminal]
 ----
-ip=bond0.100:dhcp
 bond=bond0:em1,em2:mode=active-backup
 vlan=bond0.100:bond0
 ----
@@ -287,9 +299,9 @@ ifndef::ibm-z[]
 [discrete]
 === Bonding multiple SR-IOV network interfaces to a dual port NIC interface
 
-Optional: You can bond multiple SR-IOV network interfaces to a dual port NIC interface by using the `bond=` option.
+As an optional configuration, you can bond multiple SR-IOV network interfaces to a dual port NIC interface by using the `bond=` option.
 
-On each node, you must perform the following tasks:
+.Procedure
 
 ifndef::installing-ibm-power[]
 . Create the SR-IOV virtual functions (VFs) following the guidance in link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/managing-virtual-devices_configuring-and-managing-virtualization#managing-sr-iov-devices_managing-virtual-devices[Managing SR-IOV devices]. Follow the procedure in the "Attaching SR-IOV networking devices to virtual machines" section.
@@ -313,7 +325,6 @@ The following examples illustrate the syntax you must use:
 [source,terminal]
 ----
 bond=bond0:eno1f0,eno2f0:mode=active-backup
-ip=bond0:dhcp
 ----
 
 ** To configure the bonded interface to use a static IP address, enter the specific IP address you want and related information. For example:

modules/nw-understanding-networking-service-to-pod.adoc

@@ -28,7 +28,7 @@ Key concepts of service-to-pod communication include:
 
 Services use selectors to identify the pods that should receive the traffic. The selectors match labels on the pods to determine which pods are part of the service. Example: A service with the selector `app: myapp` will route traffic to all pods with the label `app: myapp`.
 
-Endpoints are dynamically updated to reflect the current IP addresses of the pods that match the service selector. {product-name} maintains these endpoints and ensures that the service routes traffic to the correct pods.
+Endpoints are dynamically updated to reflect the current IP addresses of the pods that match the service selector. {product-title} maintains these endpoints and ensures that the service routes traffic to the correct pods.
 
 The communication flow refers to the sequence of steps and interactions that occur when a service in Kubernetes routes traffic to the appropriate pods. The typical communication flow for service-to-pod communication is as follows:
 

modules/virt-example-nmstate-multiple-interfaces.adoc

@@ -8,6 +8,11 @@
 
 You can create multiple interfaces in the same node network configuration policy. These interfaces can reference each other, allowing you to build and deploy a network configuration by using a single policy manifest.
 
+[IMPORTANT]
+====
+If multiple interfaces use the same default configuration, a single Network Manager connection profile activates on multiple interfaces simultaneously and this causes connections to have the same universally unique identifier (UUID). To avoid this issue, ensure that each interface has a specific configuration that is different to the default configuration.
+====
+
 The following example YAML file creates a bond that is named `bond10` across two NICs and VLAN that is named `bond10.103` that connects to the bond.
 
 [source,yaml]