diff --git a/modules/challenges-of-managing-symmetric-routing-with-metallb.adoc b/modules/challenges-of-managing-symmetric-routing-with-metallb.adoc new file mode 100644 index 0000000000..7f92f761fb --- /dev/null +++ b/modules/challenges-of-managing-symmetric-routing-with-metallb.adoc @@ -0,0 +1,16 @@ +// Module included in the following assemblies: +// +// * networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc + +:_mod-docs-content-type: CONCEPT +[id="challenges-of-managing-symmetric-routing-with-metallb_{context}"] += Challenges of managing symmetric routing with MetalLB + +[role="_abstract"] +To resolve network isolation and asymmetric routing challenges on multiple host interfaces, implement a configuration combining MetalLB, NMState, and OVN-Kubernetes. This solution ensures symmetric routing and prevents overlapping CIDR addresses without requiring manual static route maintenance. + +One option to ensure that return traffic reaches the correct client is to use static routes. However, with this solution, MetalLB cannot isolate the services and then announce each service through a different interface. Additionally, static routing requires manual configuration and requires maintenance if remote sites are added. + +A further challenge of symmetric routing when implementing a MetalLB service is scenarios where external systems expect the source and destination IP address for an application to be the same. The default behavior for {product-title} is to assign the IP address of the host network interface as the source IP address for traffic originating from pods. This is problematic with multiple host interfaces. + +You can overcome these challenges by implementing a configuration that combines features from MetalLB, NMState, and OVN-Kubernetes. \ No newline at end of file diff --git a/modules/nw-ingress-creating-a-passthrough-route.adoc b/modules/nw-ingress-creating-a-passthrough-route.adoc index 128e06ef2c..2519bd0e49 100644 --- a/modules/nw-ingress-creating-a-passthrough-route.adoc +++ b/modules/nw-ingress-creating-a-passthrough-route.adoc @@ -6,7 +6,8 @@ [id="nw-ingress-creating-a-passthrough-route_{context}"] = Creating a passthrough route -You can configure a secure route using passthrough termination by using the `oc create route` command. With passthrough termination, encrypted traffic is sent straight to the destination without the router providing TLS termination. Therefore no key or certificate is required on the route. +[role="_abstract"] +To send encrypted traffic directly to the destination without decryption at the router, configure a route with passthrough termination by running the `oc create route` command. This configuration requires no key or certificate on the route, as the destination pod handles TLS termination. .Prerequisites @@ -29,21 +30,23 @@ If you examine the resulting `Route` resource, it should look similar to the fol apiVersion: route.openshift.io/v1 kind: Route metadata: - name: route-passthrough-secured <1> + name: route-passthrough-secured spec: host: www.example.com port: targetPort: 8080 tls: - termination: passthrough <2> - insecureEdgeTerminationPolicy: None <3> + termination: passthrough + insecureEdgeTerminationPolicy: None to: kind: Service name: frontend ---- -<1> The name of the object, which is limited to 63 characters. -<2> The `*termination*` field is set to `passthrough`. This is the only required `tls` field. -<3> Optional `insecureEdgeTerminationPolicy`. The only valid values are `None`, `Redirect`, or empty for disabled. + -The destination pod is responsible for serving certificates for the -traffic at the endpoint. This is currently the only method that can support requiring client certificates, also known as two-way authentication. +where: ++ +`metadata.name`:: Specifies the name of the object, which is limited to 63 characters. +`tls.termination`:: Specifies the `termination` field is set to `passthrough`. This is the only required `tls` field. +`tls.insecureEdgeTerminationPolicy`:: Specifies the type of edge termination policy. Optional parameter. The only valid values are `None`, `Redirect`, or empty for disabled. ++ +The destination pod is responsible for serving certificates for the traffic at the endpoint. This is currently the only method that can support requiring client certificates, also known as two-way authentication. diff --git a/modules/nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate.adoc b/modules/nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate.adoc index 302b4009ee..e4c86c2944 100644 --- a/modules/nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate.adoc +++ b/modules/nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate.adoc @@ -6,9 +6,10 @@ [id="nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_{context}"] = Creating a re-encrypt route with a custom certificate -You can configure a secure route using re-encrypt TLS termination with a custom certificate by using the `oc create route` command. +[role="_abstract"] +To secure traffic by using a custom certificate, configure a route with re-encrypt TLS termination by running the `oc create route` command. This configuration enables the Ingress Controller to decrypt traffic, and then re-encrypt traffic before forwarding the traffic to the destination pod. -This procedure creates a `Route` resource with a custom certificate and reencrypt TLS termination. The following assumes that the certificate/key pair are in the `tls.crt` and `tls.key` files in the current working directory. You must also specify a destination CA certificate to enable the Ingress Controller to trust the service's certificate. You may also specify a CA certificate if needed to complete the certificate chain. Substitute the actual path names for `tls.crt`, `tls.key`, `cacert.crt`, and (optionally) `ca.crt`. Substitute the name of the `Service` resource that you want to expose for `frontend`. Substitute the appropriate hostname for `www.example.com`. +The procedure creates a `Route` resource with a custom certificate and reencrypt TLS termination. The procedure assumes that the certificate/key pair are in the `tls.crt` and `tls.key` files in the current working directory. You must also specify a destination CA certificate to enable the Ingress Controller to trust the service's certificate. You may also specify a CA certificate if needed to complete the certificate chain. Substitute the actual path names for `tls.crt`, `tls.key`, `cacert.crt`, and (optionally) `ca.crt`. Substitute the name of the `Service` resource that you want to expose for `frontend`. Substitute the appropriate hostname for `www.example.com`. .Prerequisites @@ -36,8 +37,7 @@ $ openssl rsa -in password_protected_tls.key -out tls.key $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com ---- + -If you examine the resulting `Route` resource, it should look similar to the -following: +If you examine the resulting `Route` resource, the resource should have a configuration similar to the following example: + .YAML Definition of the Secure Route [source,yaml] @@ -69,6 +69,7 @@ spec: -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- +# ... ---- + See `oc create route reencrypt --help` for more options. diff --git a/modules/nw-ingress-creating-an-edge-route-with-a-custom-certificate.adoc b/modules/nw-ingress-creating-an-edge-route-with-a-custom-certificate.adoc index 2209c60a95..b43c74c325 100644 --- a/modules/nw-ingress-creating-an-edge-route-with-a-custom-certificate.adoc +++ b/modules/nw-ingress-creating-an-edge-route-with-a-custom-certificate.adoc @@ -6,14 +6,17 @@ [id="nw-ingress-creating-an-edge-route-with-a-custom-certificate_{context}"] = Creating an edge route with a custom certificate -You can configure a secure route using edge TLS termination with a custom certificate by using the `oc create route` command. With an edge route, the Ingress Controller terminates TLS encryption before forwarding traffic to the destination pod. The route specifies the TLS certificate and key that the Ingress Controller uses for the route. +[role="_abstract"] +To secure traffic by using a custom certificate, configure a route with edge TLS termination by running the `oc create route` command. This configuration terminates encryption at the Ingress Controller before forwarding traffic to the destination pod. -This procedure creates a `Route` resource with a custom certificate and edge TLS termination. The following assumes that the certificate/key pair are in the `tls.crt` and `tls.key` files in the current working directory. You may also specify a CA certificate if needed to complete the certificate chain. Substitute the actual path names for `tls.crt`, `tls.key`, and (optionally) `ca.crt`. Substitute the name of the service that you want to expose for `frontend`. Substitute the appropriate hostname for `www.example.com`. +The route specifies the TLS certificate and key that the Ingress Controller uses for the route. + +The procedure creates a `Route` resource with a custom certificate and edge TLS termination. The procedure assumes that the certificate/key pair are in the `tls.crt` and `tls.key` files in the current working directory. You may also specify a CA certificate if needed to complete the certificate chain. Substitute the actual path names for `tls.crt`, `tls.key`, and (optionally) `ca.crt`. Substitute the name of the service that you want to expose for `frontend`. Substitute the appropriate hostname for `www.example.com`. .Prerequisites * You must have a certificate/key pair in PEM-encoded files, where the certificate is valid for the route host. -* You may have a separate CA certificate in a PEM-encoded file that completes the certificate chain. +* You might have a separate CA certificate in a PEM-encoded file that completes the certificate chain. * You must have a service that you want to expose. [NOTE] @@ -35,7 +38,7 @@ $ openssl rsa -in password_protected_tls.key -out tls.key $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com ---- + -If you examine the resulting `Route` resource, it should look similar to the following: +If you examine the resulting `Route` resource, the resource should have a configuration similar to the following example: + .YAML Definition of the Secure Route [source,yaml] @@ -63,6 +66,7 @@ spec: -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- +# ... ---- + See `oc create route edge --help` for more options. diff --git a/modules/nw-metallb-community-cr.adoc b/modules/nw-metallb-community-cr.adoc index 25bfa02c10..ea7c20f352 100644 --- a/modules/nw-metallb-community-cr.adoc +++ b/modules/nw-metallb-community-cr.adoc @@ -6,14 +6,16 @@ [id="nw-metallb-community-cr_{context}"] = About the community custom resource -The `community` custom resource is a collection of aliases for communities. Users can define named aliases to be used when advertising `ipAddressPools` using the `BGPAdvertisement`. The fields for the `community` custom resource are described in the following table. +[role="_abstract"] +To simplify BGP configuration, define named aliases for community values by using the community custom resource. You can reference these aliases when advertising `ipAddressPools` with the `BGPAdvertisement` resource. + +The fields for the `community` custom resource are described in the following table. [NOTE] ==== The `community` CRD applies only to BGPAdvertisement. ==== - .MetalLB community custom resource [cols="1,1,3a", options="header"] |=== diff --git a/modules/nw-metallb-configure-community-bgp-advertisement.adoc b/modules/nw-metallb-configure-community-bgp-advertisement.adoc index 28343d1e0f..92194adcc3 100644 --- a/modules/nw-metallb-configure-community-bgp-advertisement.adoc +++ b/modules/nw-metallb-configure-community-bgp-advertisement.adoc @@ -6,21 +6,20 @@ [id="nw-metallb-configure-BGP-advertisement-community-alias_{context}"] = Configuring MetalLB with a BGP advertisement and community alias -Configure MetalLB as follows so that the `IPAddressPool` is advertised with the BGP protocol and the community alias set to the numeric value of the NO_ADVERTISE community. +[role="_abstract"] +To advertise an `IPAddressPool` by using the BGP protocol, configure MetalLB with a community alias. This configuration sets the alias to the numeric value of the `NO_ADVERTISE` community. In the following example, the peer BGP router `doc-example-peer-community` receives one `203.0.113.200/32` route and one `fc00:f853:ccd:e799::1/128` route for each load-balancer IP address that MetalLB assigns to a service. A community alias is configured with the `NO_ADVERTISE` community. .Prerequisites -* Install the OpenShift CLI (`oc`). - +* Install the {oc-first} * Log in as a user with `cluster-admin` privileges. - .Procedure . Create an IP address pool. - ++ .. Create a file, such as `ipaddresspool.yaml`, with content like the following example: + [source,yaml] @@ -35,7 +34,7 @@ spec: - 203.0.113.200/30 - fc00:f853:ccd:e799::/124 ---- - ++ .. Apply the configuration for the IP address pool: + [source,terminal] @@ -59,7 +58,7 @@ spec: ---- . Create a BGP peer named `doc-example-bgp-peer`. - ++ .. Create a file, such as `bgppeer.yaml`, with content like the following example: + [source,yaml] @@ -75,7 +74,7 @@ spec: myASN: 64500 routerID: 10.10.10.10 ---- - ++ .. Apply the configuration for the BGP peer: + [source,terminal] @@ -84,7 +83,7 @@ $ oc apply -f bgppeer.yaml ---- . Create a BGP advertisement with the community alias. - ++ .. Create a file, such as `bgpadvertisement.yaml`, with content like the following example: + [source,yaml] @@ -105,8 +104,10 @@ spec: - doc-example-peer ---- + -<1> Specify the `CommunityAlias.name` here and not the community custom resource (CR) name. - +where: ++ +`NO_ADVERTISE`: Specifies the `CommunityAlias.name` here and not the community custom resource (CR) name. ++ .. Apply the configuration: + [source,terminal] diff --git a/modules/nw-metallb-configure-return-traffic-proc.adoc b/modules/nw-metallb-configure-return-traffic-proc.adoc index 1f636c668e..03c2edfd32 100644 --- a/modules/nw-metallb-configure-return-traffic-proc.adoc +++ b/modules/nw-metallb-configure-return-traffic-proc.adoc @@ -6,9 +6,10 @@ [id="nw-metallb-configure-return-traffic-proc_{context}"] = Configuring symmetric routing by using VRFs with MetalLB -You can configure symmetric network routing for applications behind a MetalLB service that require the same ingress and egress network paths. +[role="_abstract"] +To ensure that applications behind a MetalLB service use the same network path for both ingress and egress, configure symmetric routing by using Virtual Routing and Forwarding (VRF). -This example associates a VRF routing table with MetalLB and an egress service to enable symmetric routing for ingress and egress traffic for pods behind a `LoadBalancer` service. +The example in the procedure associates a VRF routing table with MetalLB and an egress service to enable symmetric routing for ingress and egress traffic for pods behind a `LoadBalancer` service. [IMPORTANT] ==== @@ -19,7 +20,7 @@ This example associates a VRF routing table with MetalLB and an egress service t .Prerequisites -* Install the OpenShift CLI (`oc`). +* Install the {oc-first}. * Log in as a user with `cluster-admin` privileges. * Install the Kubernetes NMState Operator. * Install the MetalLB Operator. @@ -27,7 +28,7 @@ This example associates a VRF routing table with MetalLB and an egress service t .Procedure . Create a `NodeNetworkConfigurationPolicy` CR to define the VRF instance: - ++ .. Create a file, such as `node-network-vrf.yaml`, with content like the following example: + [source,yaml] @@ -35,21 +36,21 @@ This example associates a VRF routing table with MetalLB and an egress service t apiVersion: nmstate.io/v1 kind: NodeNetworkConfigurationPolicy metadata: - name: vrfpolicy <1> + name: vrfpolicy spec: nodeSelector: - vrf: "true" <2> + vrf: "true" maxUnavailable: 3 desiredState: interfaces: - - name: ens4vrf <3> - type: vrf <4> + - name: ens4vrf + type: vrf state: up vrf: port: - - ens4 <5> - route-table-id: 2 <6> - - name: ens4 <7> + - ens4 + route-table-id: 2 + - name: ens4 type: ethernet state: up ipv4: @@ -58,36 +59,40 @@ spec: prefix-length: 24 dhcp: false enabled: true - routes: <8> + routes: config: - destination: 0.0.0.0/0 metric: 150 next-hop-address: 192.168.130.1 next-hop-interface: ens4 table-id: 2 - route-rules: <9> + route-rules: config: - ip-to: 172.30.0.0/16 priority: 998 - route-table: 254 <10> + route-table: 254 - ip-to: 10.132.0.0/14 priority: 998 route-table: 254 - ip-to: 169.254.0.0/17 priority: 998 route-table: 254 +# ... ---- -<1> The name of the policy. -<2> This example applies the policy to all nodes with the label `vrf:true`. -<3> The name of the interface. -<4> The type of interface. This example creates a VRF instance. -<5> The node interface that the VRF attaches to. -<6> The name of the route table ID for the VRF. -<7> The IPv4 address of the interface associated with the VRF. -<8> Defines 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. -<9> Defines 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`. -<10> The main routing table that the Linux kernel uses when calculating routes has the ID `254`. - ++ +where: ++ +`metadata.name`:: Specifies the name of the policy. +`nodeSelector.vrf`:: Specifies the policy for all nodes with the label `vrf:true`. +`interfaces.name.ens4vrf`:: Specifies the name of the interface. +`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. +`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`. ++ .. Apply the policy by running the following command: + [source,terminal] @@ -96,7 +101,7 @@ $ oc apply -f node-network-vrf.yaml ---- . Create a `BGPPeer` custom resource (CR): - ++ .. Create a file, such as `frr-via-vrf.yaml`, with content like the following example: + [source,yaml] @@ -110,10 +115,14 @@ spec: myASN: 100 peerASN: 200 peerAddress: 192.168.130.1 - vrf: ens4vrf <1> + vrf: ens4vrf +# ... ---- -<1> Specifies the VRF instance to associate with the BGP peer. MetalLB can advertise services and make routing decisions based on the routing information in the VRF. - ++ +where: ++ +`spec.vrf`:: Specifies the VRF instance to associate with the BGP peer. MetalLB can advertise services and make routing decisions based on the routing information in the VRF. ++ .. Apply the configuration for the BGP peer by running the following command: + [source,terminal] @@ -122,7 +131,7 @@ $ oc apply -f frr-via-vrf.yaml ---- . Create an `IPAddressPool` CR: - ++ .. Create a file, such as `first-pool.yaml`, with content like the following example: + [source,yaml] @@ -135,8 +144,9 @@ metadata: spec: addresses: - 192.169.10.0/32 +# ... ---- - ++ .. Apply the configuration for the IP address pool by running the following command: + [source,terminal] @@ -145,7 +155,7 @@ $ oc apply -f first-pool.yaml ---- . Create a `BGPAdvertisement` CR: - ++ .. Create a file, such as `first-adv.yaml`, with content like the following example: + [source,yaml] @@ -159,14 +169,18 @@ spec: ipAddressPools: - first-pool peers: - - frrviavrf <1> + - frrviavrf nodeSelectors: - matchLabels: - egress-service.k8s.ovn.org/test-server1: "" <2> + egress-service.k8s.ovn.org/test-server1: "" +# ... ---- -<1> In this example, MetalLB advertises a range of IP addresses from the `first-pool` IP address pool to the `frrviavrf` BGP peer. -<2> 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. - ++ +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. ++ .. Apply the configuration for the BGP advertisement by running the following command: + [source,terminal] @@ -175,7 +189,7 @@ $ oc apply -f first-adv.yaml ---- . Create an `EgressService` CR: - ++ .. Create a file, such as `egress-service.yaml`, with content like the following example: + [source,yaml,options="nowrap",role="white-space-pre"] @@ -183,21 +197,25 @@ $ oc apply -f first-adv.yaml apiVersion: k8s.ovn.org/v1 kind: EgressService metadata: - name: server1 <1> - namespace: test <2> + name: server1 + namespace: test spec: - sourceIPBy: "LoadBalancerIP" <3> + sourceIPBy: "LoadBalancerIP" nodeSelector: matchLabels: - vrf: "true" <4> - network: "2" <5> + vrf: "true" + network: "2" +# ... ---- -<1> Specify 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. -<2> Specify 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. -<3> This example assigns the `LoadBalancer` service ingress IP address as the source IP address for egress traffic. -<4> 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/-: ""`. -<5> Specify 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`. - ++ +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. +`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/-: ""`. +`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`. ++ .. Apply the configuration for the egress service by running the following command: + [source,terminal] @@ -211,8 +229,8 @@ $ oc apply -f egress-service.yaml + [source,terminal] ---- -$ curl : <1> +$ curl : ---- -<1> Update the external IP address and port number to suit your application endpoint. +* `:`: Specifies the external IP address and port number to suit 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. \ No newline at end of file diff --git a/modules/overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb.adoc b/modules/overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb.adoc new file mode 100644 index 0000000000..008db9210b --- /dev/null +++ b/modules/overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb.adoc @@ -0,0 +1,30 @@ +// Module included in the following assemblies: +// +// * networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc + +:_mod-docs-content-type: CONCEPT +[id="overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb_{context}"] += Overview of managing symmetric routing by using VRFs with MetalLB + +[role="_abstract"] +You can overcome the challenges of implementing symmetric routing by using NMState to configure a VRF instance on a host, associating the VRF instance with a MetalLB `BGPPeer` resource, and configuring an egress service for egress traffic with OVN-Kubernetes. + +.Network overview of managing symmetric routing by using VRFs with MetalLB +image::357_OpenShift_MetalLB_VRF_0823.png[Network overview of managing symmetric routing by using VRFs with MetalLB] + +The configuration process involves three stages: + +1: Define a VRF and routing rules:: + +* Configure a `NodeNetworkConfigurationPolicy` custom resource (CR) to associate a VRF instance with a network interface. +* Use the VRF routing table to direct ingress and egress traffic. + +2: Link the VRF to a MetalLB `BGPPeer`:: + +* Configure a MetalLB `BGPPeer` resource to use the VRF instance on a network interface. +* By associating the `BGPPeer` resource with the VRF instance, the designated network interface becomes the primary interface for the BGP session, and MetalLB advertises the services through this interface. + +3: Configure an egress service:: + +* Configure an egress service to choose the network associated with the VRF instance for egress traffic. +* Optional: Configure an egress service to use the IP address of the MetalLB load-balancer service as the source IP for egress traffic. diff --git a/networking/ingress_load_balancing/metallb/metallb-configure-community-alias.adoc b/networking/ingress_load_balancing/metallb/metallb-configure-community-alias.adoc index b5f651caa9..cadc5ea929 100644 --- a/networking/ingress_load_balancing/metallb/metallb-configure-community-alias.adoc +++ b/networking/ingress_load_balancing/metallb/metallb-configure-community-alias.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] As a cluster administrator, you can configure a community alias and use it across different advertisements. // Address pool custom resource diff --git a/networking/ingress_load_balancing/metallb/metallb-configure-return-traffic.adoc b/networking/ingress_load_balancing/metallb/metallb-configure-return-traffic.adoc index 014ec85758..9c23b92930 100644 --- a/networking/ingress_load_balancing/metallb/metallb-configure-return-traffic.adoc +++ b/networking/ingress_load_balancing/metallb/metallb-configure-return-traffic.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] As a cluster administrator, you can effectively manage traffic for pods behind a MetalLB load-balancer service with multiple host interfaces by implementing features from MetalLB, NMState, and OVN-Kubernetes. By combining these features in this context, you can provide symmetric routing, traffic segregation, and support clients on different networks with overlapping CIDR addresses. To achieve this functionality, learn how to implement virtual routing and forwarding (VRF) instances with MetalLB, and configure egress services. @@ -13,41 +14,9 @@ To achieve this functionality, learn how to implement virtual routing and forwar :FeatureName: Configuring symmetric traffic by using a VRF instance with MetalLB and an egress service include::snippets/technology-preview.adoc[] -[id="challenges-of-managing-symmetric-routing-with-metallb"] -== Challenges of managing symmetric routing with MetalLB +include::modules/challenges-of-managing-symmetric-routing-with-metallb.adoc[leveloffset=+1] -When you use MetalLB with multiple host interfaces, MetalLB exposes and announces a service through all available interfaces on the host. This can present challenges relating to network isolation, asymmetric return traffic and overlapping CIDR addresses. - -One option to ensure that return traffic reaches the correct client is to use static routes. However, with this solution, MetalLB cannot isolate the services and then announce each service through a different interface. Additionally, static routing requires manual configuration and requires maintenance if remote sites are added. - -A further challenge of symmetric routing when implementing a MetalLB service is scenarios where external systems expect the source and destination IP address for an application to be the same. The default behavior for {product-title} is to assign the IP address of the host network interface as the source IP address for traffic originating from pods. This is problematic with multiple host interfaces. - -You can overcome these challenges by implementing a configuration that combines features from MetalLB, NMState, and OVN-Kubernetes. - -[id="overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb"] -== Overview of managing symmetric routing by using VRFs with MetalLB - -You can overcome the challenges of implementing symmetric routing by using NMState to configure a VRF instance on a host, associating the VRF instance with a MetalLB `BGPPeer` resource, and configuring an egress service for egress traffic with OVN-Kubernetes. - -.Network overview of managing symmetric routing by using VRFs with MetalLB -image::357_OpenShift_MetalLB_VRF_0823.png[Network overview of managing symmetric routing by using VRFs with MetalLB] - -The configuration process involves three stages: - -.1. Define a VRF and routing rules - -* Configure a `NodeNetworkConfigurationPolicy` custom resource (CR) to associate a VRF instance with a network interface. -* Use the VRF routing table to direct ingress and egress traffic. - -.2. Link the VRF to a MetalLB `BGPPeer` - -* Configure a MetalLB `BGPPeer` resource to use the VRF instance on a network interface. -* By associating the `BGPPeer` resource with the VRF instance, the designated network interface becomes the primary interface for the BGP session, and MetalLB advertises the services through this interface. - -.3. Configure an egress service - -* Configure an egress service to choose the network associated with the VRF instance for egress traffic. -* Optional: Configure an egress service to use the IP address of the MetalLB load-balancer service as the source IP for egress traffic. +include::modules/overview-of-managing-symmetric-routing-using-vrf-based-networks-with-metallb.adoc[leveloffset=+1] // Deploying an egress service for VRF include::modules/nw-metallb-configure-return-traffic-proc.adoc[leveloffset=+1]