Skip to content

Commit f554fe6

Browse files
committed
OSDOCS-10810: Add BGP routing
- https://issues.redhat.com/browse/OSDOCS-10810 Includes BGP only.
1 parent 6e028b5 commit f554fe6

25 files changed

+1319
-0
lines changed

_topic_maps/_topic_map.yml

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1721,6 +1721,22 @@ Topics:
17211721
File: metallb-troubleshoot-support
17221722
- Name: Associating secondary interfaces metrics to network attachments
17231723
File: associating-secondary-interfaces-metrics-to-network-attachments
1724+
- Name: BGP routing
1725+
Dir: bgp-routing
1726+
Topics:
1727+
- Name: About BGP routing
1728+
File: about-bgp-routing
1729+
- Name: Configuring BGP routing
1730+
File: configuring-bgp-routing
1731+
- Name: Route advertisements
1732+
Dir: route_advertisements
1733+
Topics:
1734+
- Name: About route advertisements
1735+
File: about-route-advertisements
1736+
- Name: Configuring route advertisements
1737+
File: configuring-route-advertisements
1738+
- Name: Example route advertisements setup
1739+
File: example-route-advertisement-setup
17241740
---
17251741
Name: Storage
17261742
Dir: storage

modules/nw-bgp-about.adoc

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/bgp_routing/about-bgp-routing.adoc
4+
5+
:_mod-docs-content-type: CONCEPT
6+
[id="nw-bgp-about_{context}"]
7+
= Route advertisements with BGP
8+
9+
With route advertisements enabled, {product-title} Networking supports the following features:
10+
11+
- Importing routes from the provider network
12+
- Exporting routes into the provider network
13+
- Supporting multi-homing, link redundancy, and fast convergence for provider network gateways
14+
////
15+
https://github.com/openshift/openshift-docs/pull/85842/files#r1900917285
16+
- Improving throughput and reducing packet overhead
17+
////
18+
19+
[id="supported-platforms_{context}"]
20+
== Supported platforms
21+
22+
BGP routing is supported on the following infrastructure types:
23+
24+
- Bare-metal
25+
- {vmw-full} on-premise
26+
27+
[id="prerequisites_{context}"]
28+
== Prerequisites
29+
30+
Use of BGP routing requires that you have properly configured BGP for your network provider. Outages or misconfigurations of your network provider might cause disruptions to your cluster network.
31+
32+
[id="considerations-for-use-with-the-metallb-operator_{context}"]
33+
== Considerations for use with the MetalLB Operator
34+
35+
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 and uses the FRR-K8s daemon installed by this feature.
36+
37+
[IMPORTANT]
38+
====
39+
If you are using the MetalLB Operator, you must manually copy any existing `FRRConfiguration` CRs in the `metallb-system` namespace to the `openshift-frr-k8s` namespace. This includes `FRRConfiguration` CRs created by both cluster administrators and by cluster components.
40+
====
41+
42+
[id="cluster-network-operator_{context}"]
43+
== Cluster Network Operator configuration
44+
45+
The Cluster Network Operator API exposes the following API field to configure BGP routing:
46+
47+
- `spec.additionalRoutingCapabilities`: Enables deployment of the FRR-K8S daemon for the cluster, which can be used independently of route advertisements. When enabled, the FRR-K8S daemon is deployed on all nodes.
48+
49+
[id="bgp-routing-custom-resources_{context}"]
50+
== BGP routing custom resources
51+
52+
The following custom resources are used to configure BGP routing:
53+
54+
`FRRConfiguration`::
55+
This custom resource defines the FRR configuration for the BGP routing. This CR is namespaced.

modules/nw-bgp-examples.adoc

Lines changed: 245 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,245 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/bgp-routing/about-bgp-routing.adoc
4+
5+
:_mod-docs-content-type: CONCEPT
6+
[id="nw-bgp-examples_{context}"]
7+
= Examples advertising pod IP addresses with BGP
8+
9+
The following examples describe several different configurations for advertising pod IP addresses with BGP. The external network border router has the `172.18.0.5` IP address.
10+
11+
Each example relies upon the following `FRRConfiguration` object:
12+
13+
.`FRRConfiguration` CR
14+
[source,yaml]
15+
----
16+
apiVersion: frrk8s.metallb.io/v1beta1
17+
kind: FRRConfiguration
18+
metadata:
19+
name: receive-all
20+
namespace: openshift-frr-k8s
21+
spec:
22+
bgp:
23+
routers:
24+
- asn: 64512
25+
neighbors:
26+
- address: 172.18.0.5
27+
asn: 64512
28+
disableMP: true
29+
toReceive:
30+
allowed:
31+
mode: filtered
32+
----
33+
34+
The OVN-Kubernetes controller checks that the `RouteAdvertisements` CR selected nodes are a subset of the nodes selected by the `RouteAdvertisements` CR selected FRRConfigurations.
35+
36+
For these examples a user-defined network named `blue` exists with a network of `10.0.0.0/16` and a matching VRF device exists in the Linux host. The slice of this supernet allocated to nodes with the `kubernetes.io/hostname: ovn-worker` label is `10.0.1.0/24`.
37+
38+
[id="advertising-pod-ips-from-a-user-defined-network-over-bgp_{context}"]
39+
== Advertising pod IPs from a user-defined network over BGP
40+
41+
In this scenario, the blue user-defined network is exposed to the external network so that the attached pods have IP addresses that are reachable from the external network. The user-defined networks are each attached to a different VRF device:
42+
43+
Red user-defined network::
44+
- A VRF named `mp0-red`
45+
- A subnet of `10.0.0.0/24`
46+
47+
Blue user-defined network::
48+
- A VRF named `mp0-blue`
49+
- A subnet of `10.0.1.0/24`
50+
51+
In this configuration, two separate user-defined networks 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.
52+
53+
The following `RouteAdvertisements` CR describes the configuration for the blue tenant:
54+
55+
.`RouteAdvertisements` CR for the blue tenant
56+
[source,yaml]
57+
----
58+
apiVersion: k8s.ovn.org/v1
59+
kind: RouteAdvertisements
60+
metadata:
61+
name: default
62+
spec:
63+
advertisements:
64+
- PodNetwork
65+
networkSelector:
66+
matchLabels:
67+
k8s.ovn.org/metadata.name: blue
68+
frrConfigurationSelector:
69+
matchLabels:
70+
routeAdvertisements: receive-all
71+
----
72+
73+
When the OVN-Kubernetes controller sees this `RouteAdvertisements` CR, it generates a `FRRConfiguration` object that configures the FRR daemon to advertise the routes.
74+
75+
.`FRRConfiguration` CR generated by OVN-Kubernetes
76+
[source,yaml]
77+
----
78+
apiVersion: frrk8s.metallb.io/v1beta1
79+
kind: FRRConfiguration
80+
metadata:
81+
name: ovnk-generated-abcdef
82+
namespace: openshift-frr-k8s
83+
spec:
84+
bgp:
85+
routers:
86+
- asn: 64512
87+
vrf: blue
88+
imports:
89+
- vrf: default
90+
- asn: 64512
91+
neighbors:
92+
- address: 172.18.0.5
93+
asn: 64512
94+
toReceive:
95+
allowed:
96+
prefixes:
97+
- 10.0.1.0/16
98+
le: 24
99+
ge:24
100+
toAdvertise:
101+
allowed:
102+
prefixes:
103+
- 10.0.1.0/24
104+
prefixes:
105+
- 10.0.1.0/24
106+
imports:
107+
- vrf: blue
108+
nodeSelector:
109+
matchLabels:
110+
kubernetes.io/hostname: ovn-worker
111+
----
112+
113+
The generated `FRRConfiguration` object configures the subnet `10.0.1.0/24`, which belongs to VRF blue, is imported into the default VRF and advertised to the `172.18.0.5` neighbor. An `FRRConfiguration` object is generated for each node selected by a `RouteAdvertisements` CR with the appropriate prefixes that apply to each node.
114+
115+
Because the `targetVRF` uses the default value, the routes are leaked and advertised in the default VRF. Additionally, routes are imported from the default VRF into the blue VRF.
116+
117+
[id="advertising-pod-ips-from-a-user-defined-network-over-bgp-with-vpn_{context}"]
118+
== Advertising pod IPs from a user-defined network over BGP with VPN
119+
120+
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 leveraged to advertise the blue network over only the corresponding VRF/VLAN link to the next hop PE router. The red tenant uses the same configuration.
121+
122+
Red user-defined network::
123+
- A VRF named `mp0-red`
124+
- A VLAN interface attached to the VRF device and connected to the external PE router
125+
- An assigned subnet of `10.0.2.0/24`
126+
127+
Blue user-defined network::
128+
- A VRF named `mp0-blue`
129+
- A VLAN interface attached to the VRF device and connected to the external PE router
130+
- An assigned subnet of `10.0.1.0/24`
131+
132+
[NOTE]
133+
====
134+
This approach is available only when using OVN-Kubernetes local gateway mode by setting `routingViaHost=true`.
135+
====
136+
137+
In the following configuration, an additional `FRRConfiguration` CR configures peering with the PE router on the blue and red VLANs:
138+
139+
.`FRRConfiguration` CR manually configured for BGP VPN setup
140+
[source,yaml]
141+
----
142+
apiVersion: frrk8s.metallb.io/v1beta1
143+
kind: FRRConfiguration
144+
metadata:
145+
name: vpn-blue-red
146+
namespace: openshift-frr-k8s
147+
labels:
148+
routeAdvertisements: vpn-blue-red
149+
spec:
150+
bgp:
151+
routers:
152+
- asn: 64512
153+
vrf: blue
154+
neighbors:
155+
- address: 182.18.0.5
156+
asn: 64512
157+
toReceive:
158+
allowed:
159+
mode: filtered
160+
- asn: 64512
161+
vrf: red
162+
neighbors:
163+
- address: 192.18.0.5
164+
asn: 64512
165+
toReceive:
166+
allowed:
167+
mode: filtered
168+
----
169+
170+
The following `RouteAdvertisements` CR describes the configuration for the blue and red tenants:
171+
172+
.`RouteAdvertisements` CR for the blue and red tenants
173+
[source,yaml]
174+
----
175+
apiVersion: k8s.ovn.org/v1
176+
kind: RouteAdvertisements
177+
metadata:
178+
name: default
179+
spec:
180+
targetVRF: auto
181+
advertisements:
182+
- PodNetwork
183+
networkSelector:
184+
matchExpressions:
185+
- { key: k8s.ovn.org/metadata.name, operator: In, values: [blue,red] }
186+
frrConfigurationSelector:
187+
matchLabels:
188+
routeAdvertisements: vpn-blue-red
189+
----
190+
191+
In the `RouteAdvertisements` CR the `targetVRF` is set to `auto` so that advertisements will occur within the VRF device corresponding to the individual networks 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.
192+
193+
When the OVN-Kubernetes controller sees this `RouteAdvertisements` CR, it generates a `FRRConfiguration` object that configures the FRR daemon to advertise the routes for the blue and red tenants.
194+
195+
.`FRRConfiguration` CR generated by OVN-Kubernetes for blue and red tenants
196+
[source,yaml]
197+
----
198+
apiVersion: frrk8s.metallb.io/v1beta1
199+
kind: FRRConfiguration
200+
metadata:
201+
name: ovnk-generated-abcde
202+
namespace: openshift-frr-k8s
203+
spec:
204+
bgp:
205+
routers:
206+
- asn: 64512
207+
neighbors:
208+
- address: 182.18.0.5
209+
asn: 64512
210+
toReceive:
211+
allowed:
212+
prefixes:
213+
- 10.0.1.0/16
214+
le: 24
215+
ge:24
216+
toAdvertise:
217+
allowed:
218+
prefixes:
219+
- 10.0.1.0/24
220+
vrf: blue
221+
prefixes:
222+
- 10.0.1.0/24
223+
- asn: 64512
224+
neighbors:
225+
- address: 192.18.0.5
226+
asn: 64512
227+
toReceive:
228+
allowed:
229+
prefixes:
230+
- 10.0.2.0/16
231+
le: 24
232+
ge:24
233+
toAdvertise:
234+
allowed:
235+
prefixes:
236+
- 10.0.2.0/24
237+
vrf: red
238+
prefixes:
239+
- 10.0.2.0/24
240+
nodeSelector:
241+
matchLabels:
242+
kubernetes.io/hostname: ovn-worker
243+
----
244+
245+
In this scenario, any filtering or selection of routes to receive must be done in the `FRRConfiguration` CR that defines peering relationships. An `FRRConfiguration` object is generated for each node selected by a `RouteAdvertisements` CR with the appropriate prefixes that apply to each node.
Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
// omit

modules/nw-bgp-routing-config.adoc

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * networking/bgp_routing/configuring-bgp-routing.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="nw-bgp-routing-config_{context}"]
7+
= Configuring BGP routing
8+
9+
As a cluster administrator, you can enable or disable BGP routing support for your cluster on bare-metal infrastructure.
10+
11+
If you are using BGP routing in conjunction with the MetalLB Operator, the necessary BGP routing support is enabled automatically. You do not need to manually enable BGP routing support.
12+
13+
[id="enabling-bgp-routing-support_{context}"]
14+
== Enabling BGP routing support
15+
16+
As a cluster administrator, you can enable Border Gateway Protocol (BGP) routing support for your cluster.
17+
18+
.Prerequisites
19+
20+
* Install the OpenShift CLI (`oc`).
21+
* Log in to the cluster with a user with `cluster-admin` privileges.
22+
* Cluster is installed on bare-metal infrastructure.
23+
24+
.Procedure
25+
26+
* To enable a dynamic routing provider, enter the following command:
27+
+
28+
[source,terminal]
29+
----
30+
$ oc patch network.operator cluster -p '{
31+
"spec": {
32+
"additionalRoutingCapabilities": ["FRR"]
33+
}
34+
}'
35+
----
36+
37+
[id="disabling-bgp-routing-support_{context}"]
38+
== Disabling BGP routing support
39+
40+
As a cluster administrator, you can disable Border Gateway Protocol (BGP) routing support for your cluster.
41+
42+
.Prerequisites
43+
44+
* Install the OpenShift CLI (`oc`).
45+
* Log in to the cluster with a user with `cluster-admin` privileges.
46+
* Cluster is installed on bare-metal infrastructure.
47+
48+
.Procedure
49+
50+
* To disable dynamic routing, enter the following command:
51+
+
52+
[source,terminal]
53+
----
54+
$ oc patch network.operator cluster -p '{
55+
"spec": {
56+
"additionalRoutingCapabilities": null
57+
}
58+
}'
59+
----

0 commit comments

Comments
 (0)