OCPBUGS-55065: Updated the JSON examples in compatibility-with-multi-network-policy

Author: dfitzmau

Diff for: modules/configuring-localnet-switched-topology.adoc

@@ -16,9 +16,9 @@ The switched `localnet` topology interconnects the workloads created as Network
 // tag::localnet-content[]
 You must map an additional network to the OVN bridge to use it as an OVN-Kubernetes additional network. Bridge mappings allow network traffic to reach the physical network. A bridge mapping associates a physical network name, also known as an interface label, to a bridge created with Open vSwitch (OVS).
 
-You can create an `NodeNetworkConfigurationPolicy` object, part of the `nmstate.io/v1` API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified `nodeSelector` expression, such as `node-role.kubernetes.io/worker: ''`.
+You can create an `NodeNetworkConfigurationPolicy` object, part of the `nmstate.io/v1` API group, to declaratively create the mapping. This API is provided by the NMState Operator. By using this API you can apply the bridge mapping to nodes that match your specified `nodeSelector` expression, such as `node-role.kubernetes.io/worker: ''`. This declarative approach is recommended because the NMState Operator applies additional network configuration to all nodes specified by the node selector automatically and transparently.
 
-When attaching an additional network, you can either use the existing `br-ex` bridge or create a new bridge. Which approach to use depends on your specific network infrastructure.
+When attaching an additional network, you can either use the existing `br-ex` bridge or create a new bridge. Which approach to use depends on your specific network infrastructure. Consider the following approaches:
 
 - If your nodes include only a single network interface, you must use the existing bridge. This network interface is owned and managed by OVN-Kubernetes and you must not remove it from the `br-ex` bridge or alter the interface configuration. If you remove or alter the network interface, your cluster network will stop working correctly.
 - If your nodes include several network interfaces, you can attach a different network interface to a new bridge, and use that for your additional network. This approach provides for traffic isolation from your primary cluster network.
@@ -47,6 +47,23 @@ spec:
 <3> The name for the additional network from which traffic is forwarded to the OVS bridge. This additional network must match the name of the `spec.config.name` field of the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes additional network.
 <4> The name of the OVS bridge on the node. This value is required only if you specify `state: present`.
 <5> The state for the mapping. Must be either `present` to add the bridge or `absent` to remove the bridge. The default value is `present`.
++
+The following JSON example configures a localnet, `localnet1`, secondary network:
++
+[source,json]
+----
+{
+  "cniVersion": "0.3.1",
+  "name": "ns1-localnet-network",
+  "type": "ovn-k8s-cni-overlay",
+  "topology":"localnet1",
+  "subnets": "202.10.130.112/28",
+  "vlanID": 33,
+  "mtu": 1500,
+  "netAttachDefName": "ns1/localnet-network",
+  "excludeSubnets": "10.100.200.0/29"
+}
+----
 
 In the following example, the `localnet2` network interface is attached to the `ovs-br1` bridge. Through this attachment, the network interface is available to the OVN-Kubernetes network plugin as an additional network.
 
@@ -87,22 +104,20 @@ spec:
 <5> The name for the additional network from which traffic is forwarded to the OVS bridge. This additional network must match the name of the `spec.config.name` field of the `NetworkAttachmentDefinition` CRD that defines the OVN-Kubernetes additional network.
 <6> The name of the OVS bridge on the node. This value is required only if you specify `state: present`.
 <7> The state for the mapping. Must be either `present` to add the bridge or `absent` to remove the bridge. The default value is `present`.
-
-This declarative approach is recommended because the NMState Operator applies additional network configuration to all nodes specified by the node selector automatically and transparently.
-
++
 The following JSON example configures a localnet secondary network:
-
++
 [source,json]
 ----
 {
   "cniVersion": "0.3.1",
   "name": "ns1-localnet-network",
   "type": "ovn-k8s-cni-overlay",
-  "topology":"localnet",
+  "topology":"localnet2",
   "subnets": "202.10.130.112/28",
   "vlanID": 33,
   "mtu": 1500,
-  "netAttachDefName": "ns1/localnet-network"
+  "netAttachDefName": "ns1/localnet-network",
   "excludeSubnets": "10.100.200.0/29"
 }
 ----