Dynamic Routing
Border Gateway Protocol (BGP) allows you to create loop-free inter-domain routing between autonomous systems (AS). An AS is a set of routers under a single technical administration. The routers can use an Exterior Gateway Protocol to route packets outside the AS. The Dynamic Routing by Using BGP feature enables you to configure the next-hop attribute of a BGP router with alternate local addresses to service IP addresses with priority and routes. The App-Infra BGP speaker pods enable dynamic routing of traffic by using BGP to advertise pod routes to the service VIP.
This feature supports the following functionality:
-
Dynamic routing by using BGP to advertise service IP addresses for the incoming traffic.
-
Learn route for outgoing traffic.
-
Handling a BGP pod failover.
-
Handling a protocol pod failover.
-
Statistics and KPIs for the BGP speakers.
-
Log messages for debugging the BGP speakers.
-
Enable or disable the BGP speaker pods.
-
New CLI commands to configure BGP.
Incoming Traffic
BGP uses TCP as the transport protocol, on port 179. Two BGP routers form a TCP connection between one another. These routers are peer routers. The peer routers exchange messages to open and confirm the connection parameters.
The BGP speaker publishes routing information of the protocol pod for incoming traffic in the active standby mode. Use the following image as an example to understand the dynamic routing functionality. There are two protocol pods, pod1 and pod2. Pod1 is active and pod2 is in the standby mode. The service IP address, 209.165.200.225 is configured on both the nodes, 209.165.200.226 and 209.165.200.227. pod1 is running on host 209.165.200.226 and pod2 on host 209.165.200.227. The host IP address exposes the pod services. BGP speaker publishes the route 209.165.200.225 through 209.165.200.226 and 209.165.200.227. It also publishes the preference values, 110 and 100 to determine the priority of pods.

For high availability, each cluster has two BGP speaker pods with Active-standby topology. Kernel route modification is done at host network level where the protocol pod runs.
MED Value
The Local Preference is used only for IGP neighbours, whereas the MED Attribute is used only for EGP neighbours. A lower MED value is the preferred choice for BGP.
Bonding Interface Active |
VIP Present |
MED Value |
Local Preference |
---|---|---|---|
Yes |
Yes |
1210 |
2220 |
Yes |
No |
1220 |
2210 |
No |
Yes |
1215 |
2215 |
No |
No |
1225 |
2205 |
Bootstrap of BGP Speaker Pods
The following sequence of steps set up the BGP speaker pods:
-
The BGP speaker pods use TCP as the transport protocol, on port 179. These pods use the AS number configured in the Ops Center CLI.
-
Register the Topology manager.
-
Select the Leader pod. The Active speaker pod is the default choice.
-
Establish connection to all the BGP peers provided by the Ops Center CLI.
-
Publish all existing routes from ETCD.
-
Configure import policies for routing by using CLI configuration.
-
Start gRPC stream server on both the speaker pods.
-
Similar to the cache pod, two BGP speaker pods must run on each Namespace.
For more information on Dynamic Routing, see the Dynamic Routing by Using BGP chapter in the UCC Serving Gateway Control Plane Function - Configuration and Administration Guide.
For more information on Dynamic Routing, see the Dynamic Routing by Using BGP chapter in the UCC 5G Session Management Function - Configuration and Administration Guide.