|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * networking/ovn_kubernetes_network_provider/configuring-egress-traffic-for-vrf-loadbalancer-services.adoc |
| 4 | + |
| 5 | +:_content-type: PROCEDURE |
| 6 | +[id="nw-metallb-configure-return-traffic-proc_{context}"] |
| 7 | += Configuring symmetric routing by using VRFs with MetalLB |
| 8 | + |
| 9 | +You can configure symmetric network routing for applications behind a MetalLB service that require the same ingress and egress network paths. |
| 10 | + |
| 11 | +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. |
| 12 | + |
| 13 | +[NOTE] |
| 14 | +==== |
| 15 | +* If you use the `sourceIPBy: "LoadBalancerIP"` setting in the `EgressService` CR, you must specify the load-balancer node in the `BGPAdvertisement` custom resource (CR). |
| 16 | +
|
| 17 | +* 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. |
| 18 | +==== |
| 19 | + |
| 20 | +.Prerequisites |
| 21 | + |
| 22 | +* Install the OpenShift CLI (`oc`). |
| 23 | +* Log in as a user with `cluster-admin` privileges. |
| 24 | +
|
| 25 | +.Procedure |
| 26 | + |
| 27 | +. Create a `NodeNetworkConfigurationPolicy` CR to define the VRF instance: |
| 28 | + |
| 29 | +.. Create a file, such as `node-network-vrf.yaml`, with content like the following example: |
| 30 | ++ |
| 31 | +[source,yaml] |
| 32 | +---- |
| 33 | +apiVersion: nmstate.io/v1 |
| 34 | +kind: NodeNetworkConfigurationPolicy |
| 35 | +metadata: |
| 36 | + name: vrfpolicy <1> |
| 37 | +spec: |
| 38 | + nodeSelector: |
| 39 | + vrf: "true" <2> |
| 40 | + maxUnavailable: 3 |
| 41 | + desiredState: |
| 42 | + interfaces: |
| 43 | + - name: ens4vrf <3> |
| 44 | + type: vrf <4> |
| 45 | + state: up |
| 46 | + vrf: |
| 47 | + port: |
| 48 | + - ens4 <5> |
| 49 | + route-table-id: 2 <6> |
| 50 | + routes: <7> |
| 51 | + config: |
| 52 | + - destination: 0.0.0.0/0 |
| 53 | + metric: 150 |
| 54 | + next-hop-address: 192.168.130.1 |
| 55 | + next-hop-interface: ens4 |
| 56 | + table-id: 2 |
| 57 | + route-rules: <8> |
| 58 | + config: |
| 59 | + - ip-to: 172.30.0.0/16 |
| 60 | + priority: 998 |
| 61 | + route-table: 254 |
| 62 | + - ip-to: 10.132.0.0/14 |
| 63 | + priority: 998 |
| 64 | + route-table: 254 |
| 65 | +---- |
| 66 | +<1> The name of the policy. |
| 67 | +<2> This example applies the policy to all nodes with the label `vrf:true`. |
| 68 | +<3> The name of the interface. |
| 69 | +<4> The type of interface. This example creates a VRF instance. |
| 70 | +<5> The node interface that the VRF attaches to. |
| 71 | +<6> The name of the route table ID for the VRF. |
| 72 | +<7> 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. |
| 73 | +<8> Defines additional route rules. The `ip-to` fields must match the `Cluster Network` CIDR and `Service Network` CIDR. You can view the values for these CIDR address specifications by running the following command: `oc describe network.config/cluster`. |
| 74 | + |
| 75 | +.. Apply the policy by running the following command: |
| 76 | ++ |
| 77 | +[source,terminal] |
| 78 | +---- |
| 79 | +$ oc apply -f node-network-vrf.yaml |
| 80 | +---- |
| 81 | + |
| 82 | +. Create a `BGPPeer` custom resource (CR): |
| 83 | + |
| 84 | +.. Create a file, such as `frr-via-vrf.yaml`, with content like the following example: |
| 85 | ++ |
| 86 | +[source,yaml] |
| 87 | +---- |
| 88 | +apiVersion: metallb.io/v1beta2 |
| 89 | +kind: BGPPeer |
| 90 | +metadata: |
| 91 | + name: frrviavrf |
| 92 | + namespace: metallb-system |
| 93 | +spec: |
| 94 | + myASN: 100 |
| 95 | + peerASN: 200 |
| 96 | + peerAddress: 192.168.130.1 |
| 97 | + vrf: ens4vrf <1> |
| 98 | +---- |
| 99 | +<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. |
| 100 | + |
| 101 | +.. Apply the configuration for the BGP peer by running the following command: |
| 102 | ++ |
| 103 | +[source,terminal] |
| 104 | +---- |
| 105 | +$ oc apply -f frr-via-vrf.yaml |
| 106 | +---- |
| 107 | + |
| 108 | +. Create an `IPAddressPool` CR: |
| 109 | + |
| 110 | +.. Create a file, such as `first-pool.yaml`, with content like the following example: |
| 111 | ++ |
| 112 | +[source,yaml] |
| 113 | +---- |
| 114 | +apiVersion: metallb.io/v1beta1 |
| 115 | +kind: IPAddressPool |
| 116 | +metadata: |
| 117 | + name: first-pool |
| 118 | + namespace: metallb-system |
| 119 | +spec: |
| 120 | + addresses: |
| 121 | + - 192.169.10.0/32 |
| 122 | +---- |
| 123 | + |
| 124 | +.. Apply the configuration for the IP address pool by running the following command: |
| 125 | ++ |
| 126 | +[source,terminal] |
| 127 | +---- |
| 128 | +$ oc apply -f first-pool.yaml |
| 129 | +---- |
| 130 | + |
| 131 | +. Create a `BGPAdvertisement` CR: |
| 132 | + |
| 133 | +.. Create a file, such as `first-adv.yaml`, with content like the following example: |
| 134 | ++ |
| 135 | +[source,yaml] |
| 136 | +---- |
| 137 | +apiVersion: metallb.io/v1beta1 |
| 138 | +kind: BGPAdvertisement |
| 139 | +metadata: |
| 140 | + name: first-adv |
| 141 | + namespace: metallb-system |
| 142 | +spec: |
| 143 | + ipAddressPools: |
| 144 | + - first-pool |
| 145 | + peers: |
| 146 | + - frrviavrf <1> |
| 147 | + nodeSelectors: |
| 148 | + - matchLabels: |
| 149 | + egress-service.k8s.ovn.org/test-server1: "" <2> |
| 150 | +---- |
| 151 | +<1> In this example, MetalLB advertises a range of IP addresses from the `first-pool` IP address pool to the `frrviavrf` BGP peer. |
| 152 | +<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. |
| 153 | + |
| 154 | +.. Apply the configuration for the BGP advertisement by running the following command: |
| 155 | ++ |
| 156 | +[source,terminal] |
| 157 | +---- |
| 158 | +$ oc apply -f first-adv.yaml |
| 159 | +---- |
| 160 | + |
| 161 | +. Create an `EgressService` CR: |
| 162 | + |
| 163 | +.. Create a file, such as `egress-service.yaml`, with content like the following example: |
| 164 | ++ |
| 165 | +[source,yaml,options="nowrap",role="white-space-pre"] |
| 166 | +---- |
| 167 | +apiVersion: k8s.ovn.org/v1 |
| 168 | +kind: EgressService |
| 169 | +metadata: |
| 170 | + name: server1 <1> |
| 171 | + namespace: test <2> |
| 172 | +spec: |
| 173 | + sourceIPBy: "LoadBalancerIP" <3> |
| 174 | + nodeSelector: |
| 175 | + matchLabels: |
| 176 | + vrf: "true" <4> |
| 177 | + network: "2" <5> |
| 178 | +---- |
| 179 | +<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. |
| 180 | +<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. |
| 181 | +<3> This example assigns the `LoadBalancer` service ingress IP address as the source IP address for egress traffic. |
| 182 | +<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/<svc_namespace>-<svc_name>: ""`. |
| 183 | +<5> Specify the routing table for egress traffic. |
| 184 | + |
| 185 | +.. Apply the configuration for the egress service by running the following command: |
| 186 | ++ |
| 187 | +[source,terminal] |
| 188 | +---- |
| 189 | +$ oc apply -f egress-service.yaml |
| 190 | +---- |
| 191 | + |
| 192 | +.Verification |
| 193 | + |
| 194 | +. Verify that you can access the application endpoint of the pods running behind the MetalLB service by running the following command: |
| 195 | ++ |
| 196 | +[source,terminal] |
| 197 | +---- |
| 198 | +$ curl <external_ip_address>:<port_number> <1> |
| 199 | +---- |
| 200 | +<1> Update the external IP address and port number to suit your application endpoint. |
| 201 | + |
| 202 | +. 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. |
| 203 | + |
0 commit comments