mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
324 lines
11 KiB
Plaintext
324 lines
11 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * networking/route_advertisements/about-bgp-routing.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="nw-bgp-examples_{context}"]
|
|
= Examples advertising pod IP addresses with BGP
|
|
|
|
The following examples describe several configurations for advertising pod IP addresses and EgressIPs with Border Gateway Protocol (BGP). The external network border router has the `172.18.0.5` IP address. These configures assume that you have configured an external route reflector that can relay routes to all nodes on the cluster network.
|
|
|
|
////
|
|
A route advertisements object selects existing FRRConfiguration objects, and along with the selected nodes, OVN-Kubernetes controller generates further FRRConfiguration objects 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.
|
|
|
|
The FRRConfiguration objects generated by OVN-Kubernetes controller do not configure routes to be imported from the provider network. Any filtering or selection of prefixes to import are configured by a cluster administrator in different FRRConfiguration objects that those managed by OVN-Kubernetes controller. Imported routes will take effect for a cluster network as long as they are imported to that network VRF or a VRF that the network advertises to as specified by the targetVRF field of a routeAdvertisements object applying to it.
|
|
////
|
|
|
|
[id="advertising-the-default-cluster-network_{context}"]
|
|
== Advertising the default cluster network
|
|
|
|
In this scenario, the default cluster network is exposed to the external network so that pod IP addresses and EgressIPs are advertised to the provider network.
|
|
|
|
This scenario relies upon the following `FRRConfiguration` object:
|
|
|
|
.`FRRConfiguration` CR
|
|
[source,yaml]
|
|
----
|
|
apiVersion: k8s.ovn.org/v1
|
|
kind: RouteAdvertisements
|
|
metadata:
|
|
name: default
|
|
spec:
|
|
advertisements:
|
|
- PodNetwork
|
|
- EgressIP
|
|
networkSelectors:
|
|
- networkSelectionType: DefaultNetwork
|
|
frrConfigurationSelector:
|
|
matchLabels:
|
|
routeAdvertisements: receive-all
|
|
nodeSelector: {}
|
|
----
|
|
|
|
When the OVN-Kubernetes controller sees this `RouteAdvertisements` CR, it generates further `FRRConfiguration` objects based on the selected ones that configure the FRR daemon to advertise the routes for the default cluster network.
|
|
|
|
.An example of a `FRRConfiguration` CR generated by OVN-Kubernetes
|
|
[source,yaml]
|
|
----
|
|
apiVersion: frrk8s.metallb.io/v1beta1
|
|
kind: FRRConfiguration
|
|
metadata:
|
|
name: ovnk-generated-abcdef
|
|
namespace: openshift-frr-k8s
|
|
spec:
|
|
bgp:
|
|
routers:
|
|
- asn: 64512
|
|
neighbors:
|
|
- address: 172.18.0.5
|
|
asn: 64512
|
|
toReceive:
|
|
allowed:
|
|
mode: filtered
|
|
toAdvertise:
|
|
allowed:
|
|
prefixes:
|
|
- <default_network_host_subnet>
|
|
prefixes:
|
|
- <default_network_host_subnet>
|
|
nodeSelector:
|
|
matchLabels:
|
|
kubernetes.io/hostname: ovn-worker
|
|
----
|
|
|
|
In the example generated `FRRConfiguration` object, `<default_network_host_subnet>` is the subnet of the default cluster network that is advertised to the provider network.
|
|
|
|
[id="advertising-pod-ips-from-a-user-defined-network-over-bgp_{context}"]
|
|
== Advertising pod IPs from a cluster user-defined network over BGP
|
|
|
|
In this scenario, the blue cluster user-defined network (CUDN) is exposed to the external network so that the network's pod IP addresses and EgressIPs are advertised to the provider network.
|
|
|
|
This scenario relies upon the following `FRRConfiguration` object:
|
|
|
|
.`FRRConfiguration` CR
|
|
[source,yaml]
|
|
----
|
|
apiVersion: frrk8s.metallb.io/v1beta1
|
|
kind: FRRConfiguration
|
|
metadata:
|
|
name: receive-all
|
|
namespace: openshift-frr-k8s
|
|
labels:
|
|
routeAdvertisements: receive-all
|
|
spec:
|
|
bgp:
|
|
routers:
|
|
- asn: 64512
|
|
neighbors:
|
|
- address: 172.18.0.5
|
|
asn: 64512
|
|
disableMP: true
|
|
toReceive:
|
|
allowed:
|
|
mode: all
|
|
----
|
|
|
|
With this `FRRConfiguration` object, routes will be imported from neighbor `172.18.0.5` into the default VRF and are available to the default cluster network.
|
|
|
|
The CUDNs are advertised over the default VRF as illustrated in the following diagram:
|
|
|
|
image::524-openshift-bgp-ovn-k8s-no-vpn-0325.png[Advertising pod IPs from a cluster user-defined network over BGP]
|
|
|
|
Red CUDN::
|
|
- A VRF named `red` associated with a CUDN named `red`
|
|
- A subnet of `10.0.0.0/24`
|
|
|
|
Blue CUDN::
|
|
- A VRF named `blue` associated with a CUDN named `blue`
|
|
- A subnet of `10.0.1.0/24`
|
|
|
|
In this configuration, two separate CUDNs are defined. The red network covers the `10.0.0.0/24` subnet and the blue network covers the `10.0.1.0/24` subnet. The red and blue networks are labeled as `export: true`.
|
|
|
|
The following `RouteAdvertisements` CR describes the configuration for the red and blue tenants:
|
|
|
|
.`RouteAdvertisements` CR for the red and blue tenants
|
|
[source,yaml]
|
|
----
|
|
apiVersion: k8s.ovn.org/v1
|
|
kind: RouteAdvertisements
|
|
metadata:
|
|
name: advertise-cudns
|
|
spec:
|
|
advertisements:
|
|
- PodNetwork
|
|
- EgressIP
|
|
networkSelectors:
|
|
- networkSelectionType: ClusterUserDefinedNetworks
|
|
clusterUserDefinedNetworkSelector:
|
|
networkSelector:
|
|
matchLabels:
|
|
export: "true"
|
|
frrConfigurationSelector:
|
|
matchLabels:
|
|
routeAdvertisements: receive-all
|
|
nodeSelector: {}
|
|
----
|
|
|
|
When the OVN-Kubernetes controller sees this `RouteAdvertisements` CR, it generates further `FRRConfiguration` objects based on the selected ones that configure the FRR daemon to advertise the routes. The following example is of one such configuration object, with the number of `FRRConfiguration` objects created depending on the node and networks selected.
|
|
|
|
.An example of a `FRRConfiguration` CR generated by OVN-Kubernetes
|
|
[source,yaml]
|
|
----
|
|
apiVersion: frrk8s.metallb.io/v1beta1
|
|
kind: FRRConfiguration
|
|
metadata:
|
|
name: ovnk-generated-abcdef
|
|
namespace: openshift-frr-k8s
|
|
spec:
|
|
bgp:
|
|
routers:
|
|
- asn: 64512
|
|
vrf: blue
|
|
imports:
|
|
- vrf: default
|
|
- asn: 64512
|
|
neighbors:
|
|
- address: 172.18.0.5
|
|
asn: 64512
|
|
toReceive:
|
|
allowed:
|
|
mode: filtered
|
|
toAdvertise:
|
|
allowed:
|
|
prefixes:
|
|
- 10.0.1.0/24
|
|
prefixes:
|
|
- 10.0.1.0/24
|
|
imports:
|
|
- vrf: blue
|
|
nodeSelector:
|
|
matchLabels:
|
|
kubernetes.io/hostname: ovn-worker
|
|
----
|
|
|
|
The generated `FRRConfiguration` object configures the subnet `10.0.1.0/24`, which belongs to network blue, to be imported into the default VRF and advertised to the `172.18.0.5` neighbor. An `FRRConfiguration` object is generated for each network and nodes selected by a `RouteAdvertisements` CR with the appropriate prefixes that apply to each node.
|
|
|
|
When the `targetVRF` field is omitted, the routes are leaked and advertised over the default VRF. Additionally, routes that were imported to the default VRF after the definition of the initial FRRConfiguration object are also imported into the blue VRF.
|
|
|
|
[id="advertising-pod-ips-from-a-user-defined-network-over-bgp-with-vpn_{context}"]
|
|
== Advertising pod IPs from a cluster user-defined network over BGP with VPN
|
|
|
|
In this scenario, a VLAN interface is attached to the VRF device associated with the blue network. This setup provides a _VRF lite_ design, where FRR-K8S is used to advertise the blue network only over the corresponding BGP session on the blue network VRF/VLAN link to the next hop Provide Edge (PE) router. The red tenant uses the same configuration. The blue and red networks are labeled as `export: true`.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
This scenario does not support the use of EgressIPs.
|
|
====
|
|
|
|
The following diagram illustrates this configuration:
|
|
|
|
image::524-openshift-bgp-ovn-k8s-vrf-lite-0325.png[Advertising pod IPs from a cluster user-defined network over BGP with VPN]
|
|
|
|
Red CUDN::
|
|
- A VRF named `red` associated with a CUDN named `red`
|
|
- A VLAN interface attached to the VRF device and connected to the external PE router
|
|
- An assigned subnet of `10.0.2.0/24`
|
|
|
|
Blue CUDN::
|
|
- A VRF named `blue` associated with a CUDN named `blue`
|
|
- A VLAN interface attached to the VRF device and connected to the external PE router
|
|
- An assigned subnet of `10.0.1.0/24`
|
|
|
|
[NOTE]
|
|
====
|
|
This approach is available only when you set `routingViaHost=true` in the `ovnKubernetesConfig.gatewayConfig` specification of the OVN-Kubernetes network plugin.
|
|
====
|
|
|
|
In the following configuration, an additional `FRRConfiguration` CR configures peering with the PE router on the blue and red VLANs:
|
|
|
|
.`FRRConfiguration` CR manually configured for BGP VPN setup
|
|
[source,yaml]
|
|
----
|
|
apiVersion: frrk8s.metallb.io/v1beta1
|
|
kind: FRRConfiguration
|
|
metadata:
|
|
name: vpn-blue-red
|
|
namespace: openshift-frr-k8s
|
|
labels:
|
|
routeAdvertisements: vpn-blue-red
|
|
spec:
|
|
bgp:
|
|
routers:
|
|
- asn: 64512
|
|
vrf: blue
|
|
neighbors:
|
|
- address: 182.18.0.5
|
|
asn: 64512
|
|
toReceive:
|
|
allowed:
|
|
mode: filtered
|
|
- asn: 64512
|
|
vrf: red
|
|
neighbors:
|
|
- address: 192.18.0.5
|
|
asn: 64512
|
|
toReceive:
|
|
allowed:
|
|
mode: filtered
|
|
----
|
|
|
|
The following `RouteAdvertisements` CR describes the configuration for the blue and red tenants:
|
|
|
|
.`RouteAdvertisements` CR for the blue and red tenants
|
|
[source,yaml]
|
|
----
|
|
apiVersion: k8s.ovn.org/v1
|
|
kind: RouteAdvertisements
|
|
metadata:
|
|
name: advertise-vrf-lite
|
|
spec:
|
|
targetVRF: auto
|
|
advertisements:
|
|
- "PodNetwork"
|
|
nodeSelector: {}
|
|
frrConfigurationSelector:
|
|
matchLabels:
|
|
routeAdvertisements: vpn-blue-red
|
|
networkSelectors:
|
|
- networkSelectionType: ClusterUserDefinedNetworks
|
|
clusterUserDefinedNetworkSelector:
|
|
networkSelector:
|
|
matchLabels:
|
|
export: "true"
|
|
----
|
|
|
|
In the `RouteAdvertisements` CR, the `targetVRF` is set to `auto` so that advertisements occur within the VRF device that corresponds to the individual networks that are selected. In this scenario, the pod subnet for blue is advertised over the blue VRF device, and the pod subnet for red is advertised over the red VRF device. Additionally, each BGP session imports routes to only the corresponding CUDN VRF as defined by the initial `FRRConfiguration` object.
|
|
|
|
When the OVN-Kubernetes controller sees this `RouteAdvertisements` CR, it generates further `FRRConfiguration` objects based on the selected ones that configure the FRR daemon to advertise the routes for the blue and red tenants.
|
|
|
|
.`FRRConfiguration` CR generated by OVN-Kubernetes for blue and red tenants
|
|
[source,yaml]
|
|
----
|
|
apiVersion: frrk8s.metallb.io/v1beta1
|
|
kind: FRRConfiguration
|
|
metadata:
|
|
name: ovnk-generated-abcde
|
|
namespace: openshift-frr-k8s
|
|
spec:
|
|
bgp:
|
|
routers:
|
|
- asn: 64512
|
|
neighbors:
|
|
- address: 182.18.0.5
|
|
asn: 64512
|
|
toReceive:
|
|
allowed:
|
|
mode: filtered
|
|
toAdvertise:
|
|
allowed:
|
|
prefixes:
|
|
- 10.0.1.0/24
|
|
vrf: blue
|
|
prefixes:
|
|
- 10.0.1.0/24
|
|
- asn: 64512
|
|
neighbors:
|
|
- address: 192.18.0.5
|
|
asn: 64512
|
|
toReceive:
|
|
allowed:
|
|
mode: filtered
|
|
toAdvertise:
|
|
allowed:
|
|
prefixes:
|
|
- 10.0.2.0/24
|
|
vrf: red
|
|
prefixes:
|
|
- 10.0.2.0/24
|
|
nodeSelector:
|
|
matchLabels:
|
|
kubernetes.io/hostname: ovn-worker
|
|
----
|
|
|
|
In this scenario, any filtering or selection of routes to receive must be done in the `FRRConfiguration` CR that defines peering relationships.
|