updating with QE feedback

Author: kquinn1204

modules/nw-metallb-infra-considerations.adoc

@@ -24,12 +24,6 @@ MetalLB Operator and MetalLB are supported with the OpenShift SDN and OVN-Kubern
 [id="additional_network_and_metallb_limitation_{context}"]
 == Additional Network and MetalLB cannot use same network
 
-If you use the same VLAN for both MetalLB and an additional network interface configured on a source pod, it can lead to a connection failure. A connection failure happens when both the MetalLB IP and the source pod are on the same node.
+Using the same VLAN for both MetalLB and an additional network interface set up on a source pod may result in a connection failure. This occurs when both the MetalLB IP and the source pod reside on the same node.
 
-To resolve this issue, you have a couple of options:
-
-* **Use Different Subnets**: To avoid connection failures, consider placing the MetalLB IP in a different subnet from the one where the source pod resides. By doing this, traffic from the source pod will take the default gateway, which is typically OVN-K. This way, the traffic can reach its destination by using the OVN overlay network, and the connection should work as expected.
-
-* **Switch to MACVLAN Interface**: Alternatively, you can opt to use a MACVLAN interface instead of a VLAN interface for your additional network configuration. MACVLAN interfaces provide a more isolated network environment and can help prevent conflicts with MetalLB configurations. This change in interface type can help you avoid the connection issues that might arise when using the same VLAN for MetalLB and an additional network interface on the source pod.
-
-You can address this by ensuring the MetalLB IP is in another subnet so the traffic coming from a pod would take the default gateway, which is OVN-K and reach the destination via the OVN overlay. Alternatively use a MACVLAN interface instead of a VLAN interface.
+To avoid connection failures, place the MetalLB IP in a different subnet from the one where the source pod resides. This configuration ensures that traffic from the source pod will take the default gateway, which is typically OVN-Kubernetes. Consequently, the traffic can effectively reach its destination by using the OVN overlay network, ensuring that the connection functions as intended.

modules/nw-metallb-layer2-limitations.adoc

@@ -34,3 +34,10 @@ The old node can continue to forward traffic for outdated clients until their ca
 
 During an unplanned failover, the service IPs are unreachable until the outdated clients refresh their cache entries.
 
+[id="additional_network_and_metallb_limitation_{context}"]
+== Additional Network and MetalLB cannot use same network
+
+Using the same VLAN for both MetalLB and an additional network interface set up on a source pod may result in a connection failure. This occurs when both the MetalLB IP and the source pod reside on the same node.
+
+To avoid connection failures, place the MetalLB IP in a different subnet from the one where the source pod resides. This configuration ensures that traffic from the source pod will take the default gateway, which is typically OVN-Kubernetes. Consequently, the traffic can effectively reach its destination by using the OVN overlay network, ensuring that the connection functions as intended.
+