Merge pull request #75996 from dfitzmau/OSDOCS-10230

[internal-fix] OSDOCS-10230: Fixed Networking doc callout errors on CP

Author: stevsmit

modules/nw-egress-router-cr.adoc

@@ -20,44 +20,37 @@ apiVersion: network.operator.openshift.io/v1
 kind: EgressRouter
 metadata:
   name: <egress_router_name>
-  namespace: <namespace>  <.>
+  namespace: <namespace>  <1>
 spec:
-  addresses: [  <.>
+  addresses: [  <2>
     {
-      ip: "<egress_router>",  <.>
-      gateway: "<egress_gateway>"  <.>
+      ip: "<egress_router>",  <3>
+      gateway: "<egress_gateway>"  <4>
     }
   ]
   mode: Redirect
   redirect: {
-    redirectRules: [  <.>
+    redirectRules: [  <5>
       {
         destinationIP: "<egress_destination>",
         port: <egress_router_port>,
-        targetPort: <target_port>,  <.>
-        protocol: <network_protocol>  <.>
+        targetPort: <target_port>,  <6>
+        protocol: <network_protocol>  <7>
       },
       ...
     ],
-    fallbackIP: "<egress_destination>" <.>
+    fallbackIP: "<egress_destination>" <8>
   }
 ----
 // openshift/api:networkoperator/v1/001-egressrouter.crd.yaml
-<.> Optional: The `namespace` field specifies the namespace to create the egress router in. If you do not specify a value in the file or on the command line, the `default` namespace is used.
-
-<.> The `addresses` field specifies the IP addresses to configure on the secondary network interface.
-
-<.> The `ip` field specifies the reserved source IP address and netmask from the physical network that the node is on to use with egress router pod. Use CIDR notation to specify the IP address and netmask.
-
-<.> The `gateway` field specifies the IP address of the network gateway.
-
-<.> Optional: The `redirectRules` field specifies a combination of egress destination IP address, egress router port, and protocol. Incoming connections to the egress router on the specified port and protocol are routed to the destination IP address.
-
-<.> Optional: The `targetPort` field specifies the network port on the destination IP address. If this field is not specified, traffic is routed to the same network port that it arrived on.
-
-<.> The `protocol` field supports TCP, UDP, or SCTP.
-
-<.> Optional: The `fallbackIP` field specifies a destination IP address. If you do not specify any redirect rules, the egress router sends all traffic to this fallback IP address. If you specify redirect rules, any connections to network ports that are not defined in the rules are sent by the egress router to this fallback IP address. If you do not specify this field, the egress router rejects connections to network ports that are not defined in the rules.
+<1> Optional: The `namespace` field specifies the namespace to create the egress router in. If you do not specify a value in the file or on the command line, the `default` namespace is used.
+<2> The `addresses` field specifies the IP addresses to configure on the secondary network interface.
+<3> The `ip` field specifies the reserved source IP address and netmask from the physical network that the node is on to use with egress router pod. Use CIDR notation to specify the IP address and netmask.
+<4> The `gateway` field specifies the IP address of the network gateway.
+<5> Optional: The `redirectRules` field specifies a combination of egress destination IP address, egress router port, and protocol. Incoming connections to the egress router on the specified port and protocol are routed to the destination IP address.
+<6> Optional: The `targetPort` field specifies the network port on the destination IP address. If this field is not specified, traffic is routed to the same network port that it arrived on.
+<7> The `protocol` field supports TCP, UDP, or SCTP.
+<8> Optional: The `fallbackIP` field specifies a destination IP address. If you do not specify any redirect rules, the egress router sends all traffic to this fallback IP address. If you specify redirect rules, any connections to network ports that are not defined in the rules are sent by the egress router to this fallback IP address. If you do not specify this field, the egress router rejects connections to network ports that are not defined in the rules.
 
 .Example egress router specification
 [source,yaml,subs="attributes+"]

modules/nw-egress-router-redirect-mode-ovn.adoc

@@ -34,9 +34,9 @@ spec:
     port: 8080
   type: ClusterIP
   selector:
-    app: egress-router-cni <.>
+    app: egress-router-cni <1>
 ----
-<.> Specify the label for the egress router. The value shown is added by the Cluster Network Operator and is not configurable.
+<1> Specify the label for the egress router. The value shown is added by the Cluster Network Operator and is not configurable.
 +
 After you create the service, your pods can connect to the service. The egress router pod redirects traffic to the corresponding port on the destination IP address. The connections originate from the reserved source IP address.
 

modules/nw-metallb-configure-svc.adoc

@@ -51,27 +51,27 @@ $ oc describe service <service_name>
 Name:                     <service_name>
 Namespace:                default
 Labels:                   <none>
-Annotations:              metallb.universe.tf/address-pool: doc-example  <.>
+Annotations:              metallb.universe.tf/address-pool: doc-example  <1>
 Selector:                 app=service_name
-Type:                     LoadBalancer  <.>
+Type:                     LoadBalancer  <2>
 IP Family Policy:         SingleStack
 IP Families:              IPv4
 IP:                       10.105.237.254
 IPs:                      10.105.237.254
-LoadBalancer Ingress:     192.168.100.5  <.>
+LoadBalancer Ingress:     192.168.100.5  <3>
 Port:                     <unset>  80/TCP
 TargetPort:               8080/TCP
 NodePort:                 <unset>  30550/TCP
 Endpoints:                10.244.0.50:8080
 Session Affinity:         None
 External Traffic Policy:  Cluster
-Events:  <.>
+Events:  <4>
   Type    Reason        Age                From             Message
   ----    ------        ----               ----             -------
   Normal  nodeAssigned  32m (x2 over 32m)  metallb-speaker  announcing from node "<node_name>"
 ----
-<.> The annotation is present if you request an IP address from a specific pool.
-<.> The service type must indicate `LoadBalancer`.
-<.> The load-balancer ingress field indicates the external IP address if the service is assigned correctly.
-<.> The events field indicates the node name that is assigned to announce the external IP address.
+<1> The annotation is present if you request an IP address from a specific pool.
+<2> The service type must indicate `LoadBalancer`.
+<3> The load-balancer ingress field indicates the external IP address if the service is assigned correctly.
+<4> The events field indicates the node name that is assigned to announce the external IP address.
 If you experience an error, the events field indicates the reason for the error.

modules/nw-metallb-operator-limit-speaker-to-nodes.adoc

@@ -23,15 +23,15 @@ metadata:
   name: metallb
   namespace: metallb-system
 spec:
-  nodeSelector:  <.>
+  nodeSelector:  <1>
     node-role.kubernetes.io/worker: ""
-  speakerTolerations:   <.>
+  speakerTolerations:   <2>
   - key: "Example"
     operator: "Exists"
     effect: "NoExecute"
 ----
-<.> The example configuration specifies to assign the speaker pods to worker nodes, but you can specify labels that you assigned to nodes or any valid node selector.
-<.> In this example configuration, the pod that this toleration is attached to tolerates any taint that matches the `key` value and `effect` value using the `operator`.
+<1> The example configuration specifies to assign the speaker pods to worker nodes, but you can specify labels that you assigned to nodes or any valid node selector.
+<2> In this example configuration, the pod that this toleration is attached to tolerates any taint that matches the `key` value and `effect` value using the `operator`.
 
 After you apply a manifest with the `spec.nodeSelector` field, you can check the number of pods that the Operator deployed with the `oc get daemonset -n metallb-system speaker` command.
 Similarly, you can display the nodes that match your labels with a command like `oc get nodes -l node-role.kubernetes.io/worker=`.

modules/nw-metallb-operator-setting-runtimeclass.adoc

@@ -49,7 +49,7 @@ spec:
       controller: demo
   speakerConfig:
     runtimeClassName: myclass
-    annotations: <1>
+    annotations:
       speaker: demo
 ----
 <1> This example uses `annotations` to add metadata such as build release information or GitHub pull request information. You can populate annotations with characters that are not permitted in labels. However, you cannot use annotations to identify or select objects.

modules/nw-metallb-troubleshoot-bgp.adoc

@@ -60,8 +60,8 @@ router bgp 64500  <1>
  neighbor 10.0.2.3 remote-as 64500  <2>
  neighbor 10.0.2.3 bfd profile doc-example-bfd-profile-full  <3>
  neighbor 10.0.2.3 timers 5 15
- neighbor 10.0.2.4 remote-as 64500  <2>
- neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full  <3>
+ neighbor 10.0.2.4 remote-as 64500
+ neighbor 10.0.2.4 bfd profile doc-example-bfd-profile-full
  neighbor 10.0.2.4 timers 5 15
  !
  address-family ipv4 unicast
@@ -73,7 +73,7 @@ router bgp 64500  <1>
  exit-address-family
  !
  address-family ipv6 unicast
-  network fc00:f853:ccd:e799::/124  <4>
+  network fc00:f853:ccd:e799::/124
   neighbor 10.0.2.3 activate
   neighbor 10.0.2.3 route-map 10.0.2.3-in in
   neighbor 10.0.2.4 activate
@@ -91,7 +91,7 @@ ipv6 nht resolve-via-default
 line vty
 !
 bfd
- profile doc-example-bfd-profile-full  <3>
+ profile doc-example-bfd-profile-full
   transmit-interval 35
   receive-interval 35
   passive-mode
@@ -102,10 +102,10 @@ bfd
 !
 end
 ----
-<.> The `router bgp` section indicates the ASN for MetalLB.
-<.> Confirm that a `neighbor <ip-address> remote-as <peer-ASN>` line exists for each BGP peer custom resource that you added.
-<.> If you configured BFD, confirm that the BFD profile is associated with the correct BGP peer and that the BFD profile appears in the command output.
-<.> Confirm that the `network <ip-address-range>` lines match the IP address ranges that you specified in address pool custom resources that you added.
+<1> The `router bgp` section indicates the ASN for MetalLB.
+<2> Confirm that a `neighbor <ip-address> remote-as <peer-ASN>` line exists for each BGP peer custom resource that you added.
+<3> If you configured BFD, confirm that the BFD profile is associated with the correct BGP peer and that the BFD profile appears in the command output.
+<4> Confirm that the `network <ip-address-range>` lines match the IP address ranges that you specified in address pool custom resources that you added.
 
 . Display the BGP summary:
 +
@@ -135,8 +135,8 @@ RIB entries 1, using 192 bytes of memory
 Peers 2, using 29 KiB of memory
 
 Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
-10.0.2.3        4      64500       387       389        0    0    0 00:32:02 NoNeg  <1>
-10.0.2.4        4      64500         0         0        0    0    0    never       Active        0  <2>
+10.0.2.3        4      64500       387       389        0    0    0 00:32:02 NoNeg
+10.0.2.4        4      64500         0         0        0    0    0    never       Active        0
 
 Total number of neighbors 2
 ----
@@ -159,10 +159,10 @@ Replace `203.0.113.200/30` with an IPv4 or IPv6 IP address range from an address
 BGP routing table entry for 203.0.113.200/30
 Paths: (1 available, best #1, table default)
   Advertised to non peer-group peers:
-  10.0.2.3  <.>
+  10.0.2.3  <1>
   Local
     0.0.0.0 from 0.0.0.0 (10.0.1.2)
       Origin IGP, metric 0, weight 32768, valid, sourced, local, best (First path received)
       Last update: Mon Jan 10 19:49:07 2022
 ----
-<.> Confirm that the output includes an IP address for a BGP peer.
+<1> Confirm that the output includes an IP address for a BGP peer.

modules/nw-sriov-hwol-adding-network-attachment-definitions-to-pods.adoc

@@ -17,6 +17,6 @@ After you create the machine config pool, the `SriovNetworkPoolConfig` and `Srio
 ....
 metadata:
   annotations:
-    v1.multus-cni.io/default-network: net-attach-def/net-attach-def <.>
+    v1.multus-cni.io/default-network: net-attach-def/net-attach-def <1>
 ----
-<.> The value must be the name and namespace of the network attachment definition you created for hardware offloading.
+<1> The value must be the name and namespace of the network attachment definition you created for hardware offloading.

modules/nw-sriov-hwol-creating-network-attachment-definition.adoc

@@ -22,16 +22,16 @@ After you define the machine config pool and the SR-IOV network node policy, you
 apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
-  name: net-attach-def <.>
-  namespace: net-attach-def <.>
+  name: net-attach-def <1>
+  namespace: net-attach-def <2>
   annotations:
-    k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <.>
+    k8s.v1.cni.cncf.io/resourceName: openshift.io/mlxnics <3>
 spec:
   config: '{"cniVersion":"0.3.1","name":"ovn-kubernetes","type":"ovn-k8s-cni-overlay","ipam":{},"dns":{}}'
 ----
-<.> The name for your network attachment definition.
-<.> The namespace for your network attachment definition.
-<.> This is the value of the `spec.resourceName` field you specified in the `SriovNetworkNodePolicy` object.
+<1> The name for your network attachment definition.
+<2> The namespace for your network attachment definition.
+<3> This is the value of the `spec.resourceName` field you specified in the `SriovNetworkNodePolicy` object.
 
 . Apply the configuration for the network attachment definition:
 +

modules/nw-sriov-hwol-creating-sriov-policy.adoc

@@ -25,11 +25,11 @@ The following procedure creates an SR-IOV interface for a network interface cont
 apiVersion: sriovnetwork.openshift.io/v1
 kind: SriovNetworkNodePolicy
 metadata:
-  name: sriov-node-policy <.>
+  name: sriov-node-policy <1>
   namespace: openshift-sriov-network-operator
 spec:
-  deviceType: netdevice <.>
-  eSwitchMode: "switchdev" <.>
+  deviceType: netdevice <2>
+  eSwitchMode: "switchdev" <3>
   nicSelector:
     deviceID: "1019"
     rootDevices:
@@ -43,9 +43,9 @@ spec:
   priority: 5
   resourceName: mlxnics
 ----
-<.> The name for the custom resource object.
-<.> Required. Hardware offloading is not supported with `vfio-pci`.
-<.> Required.
+<1> The name for the custom resource object.
+<2> Required. Hardware offloading is not supported with `vfio-pci`.
+<3> Required.
 
 . Apply the configuration for the policy:
 +

modules/nw-sriov-hwol-improving-network-traffic-performance.adoc

@@ -44,15 +44,15 @@ spec:
     - 0000:d8:00.0
     vendor: "15b3"
     pfNames:
-    - ens8f0#0-0 <.>
+    - ens8f0#0-0 <1>
   nodeSelector:
     network.operator.openshift.io/smart-nic: ""
-  numVfs: 6 <.>
+  numVfs: 6 <2>
   priority: 5
   resourceName: mgmtvf
 ----
-<.> Replace this device with the appropriate network device for your use case. The `#0-0` part of the `pfNames` value reserves a single virtual function used by OVN-Kubernetes.
-<.> The value provided here is an example. Replace this value with one that meets your requirements. For more information, see _SR-IOV network node configuration object_ in the _Additional resources_ section.
+<1> Replace this device with the appropriate network device for your use case. The `#0-0` part of the `pfNames` value reserves a single virtual function used by OVN-Kubernetes.
+<2> The value provided here is an example. Replace this value with one that meets your requirements. For more information, see _SR-IOV network node configuration object_ in the _Additional resources_ section.
 
 . Create a policy named `sriov-node-policy.yaml` with content such as the following example:
 +
@@ -72,15 +72,15 @@ spec:
     - 0000:d8:00.0
     vendor: "15b3"
     pfNames:
-    - ens8f0#1-5 <.>
+    - ens8f0#1-5 <1>
   nodeSelector:
     network.operator.openshift.io/smart-nic: ""
-  numVfs: 6 <.>
+  numVfs: 6 <2>
   priority: 5
   resourceName: mlxnics
 ----
-<.> Replace this device with the appropriate network device for your use case.
-<.> The value provided here is an example. Replace this value with the value specified in the `sriov-node-mgmt-vf-policy.yaml` file. For more information, see _SR-IOV network node configuration object_ in the _Additional resources_ section.
+<1> Replace this device with the appropriate network device for your use case.
+<2> The value provided here is an example. Replace this value with the value specified in the `sriov-node-mgmt-vf-policy.yaml` file. For more information, see _SR-IOV network node configuration object_ in the _Additional resources_ section.
 +
 [NOTE]
 ====