Merge pull request #112391 from kquinn1204/test-symmetric-routing-metallb

OCPBUGS-86705:  Hybrid cluster network cited instead of cluster network for metallb+vrf symmetric NNCP config

Author: slovern

modules/nw-metallb-configure-return-traffic-proc.adoc

@@ -13,7 +13,7 @@ The example in the procedure associates a VRF routing table with MetalLB and an
 
 [IMPORTANT]
 ====
-* If you use the `sourceIPBy: "LoadBalancerIP"` setting in the `EgressService` CR, you must specify the load-balancer node in the `BGPAdvertisement` custom resource (CR).
+* If you use the `sourceIPBy: "LoadBalancerIP"` setting in the `EgressService` CR, you must specify the `LoadBalancer` node in the `BGPAdvertisement` custom resource (CR).
 
 * You can use the `sourceIPBy: "Network"` setting on clusters that use OVN-Kubernetes configured with the `gatewayConfig.routingViaHost` specification set to `true` only. Additionally, if you use the `sourceIPBy: "Network"` setting, you must schedule the application workload on nodes configured with the network VRF instance.
 ====
@@ -24,9 +24,20 @@ The example in the procedure associates a VRF routing table with MetalLB and an
 * Log in as a user with `cluster-admin` privileges.
 * Install the Kubernetes NMState Operator.
 * Install the MetalLB Operator.
+* Create a namespace for your application workload. The examples in this procedure use a namespace called `test`.
 
 .Procedure
 
+. Label the nodes that you want to participate in the VRF configuration by running the following command:
++
+[source,terminal]
+----
+$ oc label node <node_name> vrf=true
+----
++
+The examples in this procedure use the label `vrf: "true"`.
+
+
 . Create a `NodeNetworkConfigurationPolicy` CR to define the VRF instance:
 +
 .. Create a file, such as `node-network-vrf.yaml`, with content like the following example:
@@ -71,7 +82,7 @@ spec:
       - ip-to: 172.30.0.0/16
         priority: 998
         route-table: 254
-      - ip-to: 10.132.0.0/14
+      - ip-to: 10.128.0.0/14
         priority: 998
         route-table: 254
       - ip-to: 169.254.0.0/17
@@ -88,7 +99,7 @@ where:
 `interfaces.type`:: Specifies the type of interface. This example creates a VRF instance.
 `vrf.port`:: Specifies the node interface that the VRF attaches to.
 `vrf.route-table-id`:: Specifies the name of the route table ID for the VRF.
-`interfaces.name.ens4 `:: Specifies the IPv4 address of the interface associated with the VRF. 
+`interfaces.name.ens4`:: Specifies the IPv4 address of the interface associated with the VRF.
 `routes`:: Specifies the configuration for network routes. The `next-hop-address` field defines the IP address of the next hop for the route. The `next-hop-interface` field defines the outgoing interface for the route. In this example, the VRF routing table is `2`, which references the ID that you define in the `EgressService` CR.
 `route-rules`:: Specifies additional route rules. The `ip-to` fields must match the `Cluster Network` CIDR, `Service Network` CIDR, and `Internal Masquerade` subnet CIDR. You can view the values for these CIDR address specifications by running the following command: `oc describe network.operator/cluster`.
 `route-rules.route-table`:: Specifies the main routing table that the Linux kernel uses when calculating routes has the ID `254`.
@@ -99,6 +110,15 @@ where:
 ----
 $ oc apply -f node-network-vrf.yaml
 ----
++
+.. Verify that the policy is applied by running the following command:
++
+[source,terminal]
+----
+$ oc get nncp vrfpolicy
+----
++
+The output must show `Available` in the `STATUS` column before you continue to the next step.
 
 . Create a `BGPPeer` custom resource (CR):
 +
@@ -179,7 +199,7 @@ spec:
 where:
 +
 `peers`:: In this example, MetalLB advertises a range of IP addresses from the `first-pool` IP address pool to the `frrviavrf` BGP peer.
-`nodeSelectors`:: In this example, the `EgressService` CR configures the source IP address for egress traffic to use the load-balancer service IP address. Therefore, you must specify the load-balancer node for return traffic to use the same return path for the traffic originating from the pod.
+`nodeSelectors`:: In this example, the `EgressService` CR configures the source IP address for egress traffic to use the `LoadBalancer` service IP address. Therefore, you must specify the `LoadBalancer` node for return traffic to use the same return path for the traffic originating from the pod.
 +
 .. Apply the configuration for the BGP advertisement by running the following command:
 +
@@ -210,11 +230,11 @@ spec:
 +
 where:
 +
-`metadata.name`:: Specifies the name for the egress service. The name of the `EgressService` resource must match the name of the load-balancer service that you want to modify.
-`metadata.namespace`:: Specifies the namespace for the egress service. The namespace for the `EgressService` must match the namespace of the load-balancer service that you want to modify. The egress service is namespace-scoped.
+`metadata.name`:: Specifies the name for the egress service. The name of the `EgressService` resource must match the name of the `LoadBalancer` service that you want to modify.
+`metadata.namespace`:: Specifies the namespace for the egress service. The namespace for the `EgressService` must match the namespace of the `LoadBalancer` service that you want to modify. The egress service is namespace-scoped.
 `spec.sourceIPBy`:: Specifies the `LoadBalancer` service ingress IP address as the source IP address for egress traffic.
 `matchLabels.vrf`:: If you specify `LoadBalancer` for the `sourceIPBy` specification, a single node handles the `LoadBalancer` service traffic. In this example, only a node with the label `vrf: "true"` can handle the service traffic. If you do not specify a node, OVN-Kubernetes selects a worker node to handle the service traffic. When a node is selected, OVN-Kubernetes labels the node in the following format: `egress-service.k8s.ovn.org/<svc_namespace>-<svc_name>: ""`.
-`network`:: Specifyies the routing table ID for egress traffic. Ensure that the value matches the `route-table-id` ID defined in the `NodeNetworkConfigurationPolicy` resource, for example, `route-table-id: 2`. 
+`network`:: Specifies the routing table ID for egress traffic. Ensure that the value matches the `route-table-id` ID defined in the `NodeNetworkConfigurationPolicy` resource, for example, `route-table-id: 2`.
 +
 .. Apply the configuration for the egress service by running the following command:
 +
@@ -225,12 +245,22 @@ $ oc apply -f egress-service.yaml
 
 .Verification
 
+. Get the external IP address for the `LoadBalancer` service by running the following command:
++
+[source,terminal]
+----
+$ oc get svc <service_name> -n <namespace>
+----
++
+where `<service_name>` is the name of your `LoadBalancer` service and `<namespace>` is the namespace where the service is deployed. Note the `EXTERNAL-IP` value from the output.
+
 . Verify that you can access the application endpoint of the pods running behind the MetalLB service by running the following command:
 +
 [source,terminal]
 ----
 $ curl <external_ip_address>:<port_number>
 ----
-* `<external_ip_address>:<port_number>`: Specifies the external IP address and port number to suit your application endpoint.
++
+where `<external_ip_address>` is the `EXTERNAL-IP` value from the previous step, and `<port_number>` is the port number of your application endpoint.
 
-. Optional: If you assigned the `LoadBalancer` service ingress IP address as the source IP address for egress traffic, verify this configuration by using tools such as `tcpdump` to analyze packets received at the external client.
+. Optional: If you assigned the `LoadBalancer` service ingress IP address as the source IP address for egress traffic, verify this configuration by using tools such as `tcpdump` to analyze packets received at the external client.