Expanding on the issue

Author: kquinn1204

modules/nw-metallb-bgp-limitations.adoc

@@ -18,13 +18,6 @@ However, you can anticipate that a change in the number of `speaker` pods affect
 To avoid or reduce the likelihood of a service interruption, you can specify a node selector when you add a BGP peer.
 By limiting the number of nodes that start BGP sessions, a fault on a node that does not have a BGP session has no affect on connections to the service.
 
-[id="additional_network_and_metallb_limitation_{context}"]
-== Additional Network and MetalLB cannot use same network
-
-There is a limitation when using the same VLAN for both MetalLB and an additional network interface on a source pod. In such cases, a connection failure occurs, when the MetalLB IP and the source pod share the same node.
-
-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.
-
 [id="nw-metallb-bgp-limitations-single-asn_{context}"]
 == Support for a single ASN and a single router ID only
 

modules/nw-metallb-infra-considerations.adoc

@@ -21,3 +21,15 @@ For example, the following infrastructures can benefit from adding the MetalLB O
 
 MetalLB Operator and MetalLB are supported with the OpenShift SDN and OVN-Kubernetes network providers.
 
+[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.
+
+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.