[enterprise-4.12] OCPBUGS-46042: Swapped out Shared Gateway Mode for routingViaHost

modules/nw-egressnetworkpolicy-about.adoc

@@ -14,16 +14,15 @@ ifeval::["{context}" == "openshift-sdn-egress-firewall"]
 :api: network.openshift.io/v1
 endif::[]
 
+:_mod-docs-content-type: CONCEPT
 [id="nw-egressnetworkpolicy-about_{context}"]
 = How an egress firewall works in a project
 
-As a cluster administrator, you can use an _egress firewall_ to
-limit the external hosts that some or all pods can access from within the
-cluster. An egress firewall supports the following scenarios:
+As a cluster administrator, you can use an _egress firewall_ to limit the external hosts that some or all pods can access from within the cluster. An egress firewall supports the following scenarios:
 
-- A pod can only connect to internal hosts and cannot initiate connections to
+- A pod can only connect to internal hosts and cannot start connections to
 the public internet.
-- A pod can only connect to the public internet and cannot initiate connections
+- A pod can only connect to the public internet and cannot start connections
 to internal hosts that are outside the {product-title} cluster.
 - A pod cannot reach specified internal subnets or hosts outside the {product-title} cluster.
 - A pod can connect to only specific external hosts.
@@ -32,7 +31,7 @@ For example, you can allow one project access to a specified IP range but deny t
 
 [NOTE]
 ====
-Egress firewall does not apply to the host network namespace. Pods with host networking enabled are unaffected by egress firewall rules.
+Egress firewall does not apply to the host network namespace. Egress firewall rules do not impact any pods that have host networking enabled.
 ====
 
 You configure an egress firewall policy by creating an {kind} custom resource (CR) object. The egress firewall matches network traffic that meets any of the following criteria:
@@ -108,7 +107,7 @@ endif::openshift-sdn[]
 ifdef::ovn[]
 * A maximum of one {kind} object with a maximum of 8,000 rules can be defined per project.
 
-* If you are using the OVN-Kubernetes network plugin with shared gateway mode in Red Hat OpenShift Networking, return ingress replies are affected by egress firewall rules. If the egress firewall rules drop the ingress reply destination IP, the traffic is dropped.
+* If you use the OVN-Kubernetes network plugin and you configured `false` for the `routingViaHost` parameter in the `Network` custom resource for your cluster, egress firewall rules impact the return ingress replies. If the egress firewall rules drop the ingress reply destination IP, the traffic is dropped.
 endif::ovn[]
 ifdef::openshift-sdn[]
 * A maximum of one {kind} object with a maximum of 1,000 rules can be defined per project.
@@ -124,17 +123,17 @@ ifdef::openshift-sdn[]
 * If you create a selectorless service and manually define endpoints or `EndpointSlices` that point to external IPs, traffic to the service IP might still be allowed, even if your `EgressNetworkPolicy` is configured to deny all egress traffic. This occurs because OpenShift SDN does not fully enforce egress network policies for these external endpoints. Consequently, this might result in unexpected access to external services.
 endif::openshift-sdn[]
 
-Violating any of these restrictions results in a broken egress firewall for the project. Consequently, all external network traffic is dropped, which can cause security risks for your organization.
+Violating any of these restrictions results in a broken egress firewall for the project. As a result, all external network traffic drops, which can cause security risks for your organization.
 
-An Egress Firewall resource can be created in the `kube-node-lease`, `kube-public`, `kube-system`, `openshift` and `openshift-` projects.
+You can create an Egress Firewall resource in the `kube-node-lease`, `kube-public`, `kube-system`, `openshift` and `openshift-` projects.
 
 [id="policy-rule-order_{context}"]
 == Matching order for egress firewall policy rules
 
-The egress firewall policy rules are evaluated in the order that they are defined, from first to last. The first rule that matches an egress connection from a pod applies. Any subsequent rules are ignored for that connection.
+The OVN-Kubernetes network plugin evaluates egress firewall policy rules based on the first-to-last order of how you defined the rules. The first rule that matches an egress connection from a pod applies. The plugin ignores any subsequent rules for that connection.
 
 [id="domain-name-server-resolution_{context}"]
-== How Domain Name Server (DNS) resolution works
+== Domain Name Server (DNS) resolution
 
 If you use DNS names in any of your egress firewall policy rules, proper resolution of the domain names is subject to the following restrictions:
 
@@ -145,7 +144,7 @@ ifdef::ovn[]
 * Domain name updates are polled based on a time-to-live (TTL) duration. By default, the duration is 30 minutes. When the egress firewall controller queries the local name servers for a domain name, if the response includes a TTL and the TTL is less than 30 minutes, the controller sets the duration for that DNS name to the returned value. Each DNS name is queried after the TTL for the DNS record expires.
 endif::ovn[]
 
-* The pod must resolve the domain from the same local name servers when necessary. Otherwise the IP addresses for the domain known by the egress firewall controller and the pod can be different. If the IP addresses for a hostname differ, the egress firewall might not be enforced consistently.
+* The pod must resolve the domain from the same local name servers when necessary. Otherwise the IP addresses for the domain known by the egress firewall controller and the pod can be different. If the IP addresses for a hostname differ, consistent enforcement of the egress firewall does not apply.
 
 * Because the egress firewall controller and pods asynchronously poll the same local name server, the pod might obtain the updated IP address before the egress controller does, which causes a race condition. Due to this current limitation, domain name usage in {kind} objects is only recommended for domains with infrequent IP address changes.
 

networking/ovn_kubernetes_network_provider/configuring-gateway.adoc

@@ -0,0 +1,14 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="configuring-gateway"]
+= Configuring a gateway
+include::_attributes/common-attributes.adoc[]
+:context: configuring-gateway-mode
+
+toc::[]
+
+As a cluster administrator you can configure the `gatewayConfig` object to manage how external traffic leaves the cluster. You do so by setting the `routingViaHost` parameter to one of the following values:
+
+* `true` means that egress traffic routes through a specific local gateway on the node that hosts the pod. Egress traffic routes through the host and this traffic applies to the routing table of the host.
+* `false` means that egress traffic routes through a dedicated node but a group of nodes share the same gateway. Egress traffic does not route through the host. The Open vSwitch (OVS) outputs traffic directly to the node IP interface.
+
+include::modules/nwt-configure-egress-routing-policies.adoc[leveloffset=+1]