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.

Dynamic Routing for Incoming Traffic in the Active-standby Topology

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.

MED Value

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:

  1. 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.

  2. Register the Topology manager.

  3. Select the Leader pod. The Active speaker pod is the default choice.

  4. Establish connection to all the BGP peers provided by the Ops Center CLI.

  5. Publish all existing routes from ETCD.

  6. Configure import policies for routing by using CLI configuration.

  7. Start gRPC stream server on both the speaker pods.

  8. 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.