|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * networking/route_advertisements/about-route-advertisements.adoc |
| 4 | + |
| 5 | +//// |
| 6 | +Terminology - |
| 7 | +Cluster network routes: Both pod network routes and/or EgressIP routes |
| 8 | +Pod network routes: Routes to pod IPs |
| 9 | +EgressIP routes: Routes to EgressIPs |
| 10 | +//// |
| 11 | + |
| 12 | +:_mod-docs-content-type: CONCEPT |
| 13 | +[id="nw-routeadvertisements-about_{context}"] |
| 14 | += Advertise cluster network routes with Border Gateway Protocol |
| 15 | + |
| 16 | +With route advertisements enabled, the OVN-Kubernetes network plugin supports advertising network routes for the default pod network and cluster user-defined (CUDN) networks to the provider network, including EgressIPs, and importing routes from the provider network to the default pod network and CUDNs. From the provider network, IP addresses advertised from the default pod network and CUDNs can be reached directly. |
| 17 | + |
| 18 | +For example, you can import routes to the default pod network so you no longer need to manually configure routes on each node. Previously, you might have been using local gateway mode (`RoutingViaHost=true`) and manually configuring routes on each node to approximate a similar configuration. With route advertisements you can accomplish this seamlessly and you can use shared gateway mode (`RoutingViaHost=false`) as well. |
| 19 | + |
| 20 | +Route reflectors on the provider network are supported and can reduce the number of BGP connections required to advertise routes on large networks. |
| 21 | + |
| 22 | +If you use EgressIPs with route advertisements enabled, the layer 3 provider network is aware of EgressIP failovers. This allows you to locate cluster nodes that host EgressIPs on different layer 2 segments whereas before only the layer 2 provider network was aware so that required all the egress nodes to be on the same layer 2 segment. |
| 23 | + |
| 24 | +[id="supported-platforms_{context}"] |
| 25 | +== Supported platforms |
| 26 | + |
| 27 | +Advertising routes with border gateway protocol (BGP) is supported on the following infrastructure types: |
| 28 | + |
| 29 | +- Bare-metal |
| 30 | +//- {vmw-full} on-premise |
| 31 | + |
| 32 | +[id="infrastructure-requirements_{context}"] |
| 33 | +== Infrastructure requirements |
| 34 | + |
| 35 | +To use route advertisements, you must have configured BGP for your network infrastructure. Outages or misconfigurations of your network infrastructure might cause disruptions to your cluster network. |
| 36 | + |
| 37 | +[id="compatibility-with-other-networking-features_{context}"] |
| 38 | +== Compatibility with other networking features |
| 39 | + |
| 40 | +Route advertisements support the following {product-title} Networking features: |
| 41 | + |
| 42 | +Multiple external gateways (MEG):: |
| 43 | +MEG is not supported with this feature. |
| 44 | + |
| 45 | +EgressIPs:: |
| 46 | +-- |
| 47 | +Supports the use and advertisement of EgressIPs. The node where an egress IP address resides advertises the EgressIP. An egress IP address must be on the same layer 2 network subnet as the egress node. The following limitations apply: |
| 48 | + |
| 49 | +- Advertising EgressIPs from a user-defined network (CUDN) operating in layer 2 mode are not supported. |
| 50 | +- Advertising EgressIPs for a network that has both egress IP addresses assigned to the primary network interface and egress IP addresses assigned to additional network interfaces is impractical. All EgressIPs are advertised on all of the BGP sessions of the selected FRRConfiguration instances, regardless of whether these sessions are established over the same interface that the EgressIP is assigned to or not, potentially leading to unwanted advertisements. |
| 51 | + |
| 52 | +-- |
| 53 | + |
| 54 | +Services:: |
| 55 | +Works with the MetalLB Operator to advertise services to the provider network. |
| 56 | + |
| 57 | +Egress service:: |
| 58 | +Full support. |
| 59 | + |
| 60 | +Egress firewall:: |
| 61 | +Full support. |
| 62 | + |
| 63 | +Egress QoS:: |
| 64 | +Full support. |
| 65 | + |
| 66 | +Network policies:: |
| 67 | +Full support. |
| 68 | + |
| 69 | +Direct pod ingress:: |
| 70 | +Full support for the default cluster network and cluster user-defined (CUDN) networks. |
| 71 | + |
| 72 | +[id="considerations-for-use-with-the-metallb-operator_{context}"] |
| 73 | +== Considerations for use with the MetalLB Operator |
| 74 | + |
| 75 | +The MetalLB Operator is installed as an add-on to the cluster. Deployment of the MetalLB Operator automatically enables FRR-K8s as an additional routing capability provider. This feature and the MetalLB Operator use the same FRR-K8s deployment. |
| 76 | + |
| 77 | +[id="considerations-for-naming-cluster-user-defined-networks_{context}"] |
| 78 | +== Considerations for naming cluster user-defined networks (CUDNs) |
| 79 | + |
| 80 | +When referencing a VRF device in a `FRRConfiguration` CR, the VRF name is the same as the CUDN name for VRF names that are less than or equal to 15 characters. It is recommended to use a VRF name no longer than 15 characters so that the VRF name can be inferred from the CUDN name. |
| 81 | + |
| 82 | +[id="bgp-routing-custom-resources_{context}"] |
| 83 | +== BGP routing custom resources |
| 84 | + |
| 85 | +The following custom resources (CRs) are used to configure route advertisements with BGP: |
| 86 | + |
| 87 | +`RouteAdvertisements`:: |
| 88 | +This CR defines the advertisements for the BGP routing. From this CR, the OVN-Kubernetes controller generates a `FRRConfiguration` object that configures the FRR daemon to advertise cluster network routes. This CR is cluster scoped. |
| 89 | + |
| 90 | +`FRRConfiguration`:: |
| 91 | +This CR is used to define BGP peers and to configure route imports from the provider network into the cluster network. Before applying `RouteAdvertisements` objects, at least one FRRConfiguration object must be initially defined to configure the BGP peers. This CR is namespaced. |
| 92 | + |
| 93 | +[id="ovn-kubernetes-controller-generation-of-frrconfiguration-objects_{context}"] |
| 94 | +== OVN-Kubernetes controller generation of `FRRConfiguration` objects |
| 95 | + |
| 96 | +An `FRRConfiguration` object is generated for each network and node selected by a `RouteAdvertisements` CR with the appropriate advertised prefixes that apply to each node. The OVN-Kubernetes controller checks whether the `RouteAdvertisements`-CR-selected nodes are a subset of the nodes that are selected by the `RouteAdvertisements`-CR-selected FRR configurations. |
| 97 | + |
| 98 | +Any filtering or selection of prefixes to receive are not considered in `FRRConfiguration` objects that are generated from the `RouteAdvertisement` CRs. Configure any prefixes to receive on other `FRRConfiguration` objects. OVN-Kubernetes imports routes from the VRF into the appropriate network. |
| 99 | + |
| 100 | +[id="cluster-network-operator_{context}"] |
| 101 | +== Cluster Network Operator configuration |
| 102 | + |
| 103 | +The Cluster Network Operator (CNO) API exposes several fields to configure route advertisements: |
| 104 | + |
| 105 | +- `spec.additionalRoutingCapabilities.providers`: Specifies an additional routing provider, which is required to advertise routes. The only supported value is `FRR`, which enables deployment of the FRR-K8S daemon for the cluster. When enabled, the FRR-K8S daemon is deployed on all nodes. |
| 106 | +- `spec.defaultNetwork.ovnKubernetesConfig.routeAdvertisements`: Enables route advertisements for the default cluster network and CUDN networks. The `spec.additionalRoutingCapabilities` field must be set to `FRR` to enable this feature. |
0 commit comments