How to: Configure Border Gateway Protocol using Route Health Injection

Overview

The Border Gateway Protocol (BGP) Route Health Injection (RHI) is used in network routing to influence the selection of routes advertised through BGP based on their health status. In traditional BGP routing, routes are advertised based on their reachability and preference metrics, such as Autonomous System (AS) path length, local preference. However, the BGP RHI injects additional information about the health of a route into the BGP decision-making process. This health information can include metrics like route stability, latency, packet loss, or other factors indicative of the quality or reliability of a route. By injecting this health information into BGP updates, routers can make more informed decisions about which routes to prefer, considering not only reachability but also on the health and performance of those routes.
The BGP RHI is particularly useful in scenarios where there are multiple paths to the same destination, such as multi-homed networks or networks with redundant links. It helps optimise routing decisions to ensure that traffic is routed over the most stable and performant paths, thus improving overall network reliability and performance. The BGP uses a mechanism called peering, administrators designate specific routers as BGP peers. Peers represent devices at the edge or boundary of an autonomous system.
BGP peers perform the following functions:

• Route Discovery - BGP peers exchange routing information with neighbouring BGP peers through Network Layer Reachability Information (NLRI) and path attributes. NLRI contains connection information about neighbors. Path attributes include information such as delay, hop count, and transmission cost. After exchanging information, each BGP peer can create a graph of network connectivity around it.
  

• Route Storage – During the discovery process, each BGP router collects route advertisement information and stores it in the form of a routing table. It uses routing tables for path selection and is updated periodically. For example, a BGP router receives keep-alive messages from neighboring routers every 30 seconds. It will update the saved route accordingly.
  

• Path Selection - BGP routers use stored information to optimise traffic routing. The most important factor in route selection is the shortest path, which is determined using a saved route map. When a destination can be reached through multiple paths, BGP selects the best path by evaluating the other path attributes in turn.
  

Task Overview

• Configure BGP peers on a Default L3 Forward.

• Configure a RHI setting for the virtual address.

• Configure an Application.

• Verify Routing advertisement.

Prerequisites

• You must have Administrator or Application Manager user credentials to manage application services. Users with Instance Manager or Auditor credentials have read-only access to application services.
  

• If you plan to use an template to create an application service, you need to decide which template you’re going to use. There are three options:
  

  • Use the fields on the standard template to specify the application service you want to create.

  • Clone the default template and revise it so it defines the application service you want to create.

  • Create a new template that defines the application service you want to create.
    For details on how to work with templates, refer to How to: Manage FAST templates for a BIG-IP Next instance on BIG-IP Next Central Manager.

• Parameter details (for example, server names or addresses, pool names, and pool member addresses or names) that are required by the application template you plan to use for this application service.
  

• If you intend to attach a certificate to your application, you need to know the name of the certificate you plan to use. For details about managing certificates and keys, refer to How to: Manage Instance Certificates and Keys using BIG-IP Next Central Manager.

• You must be managing the BIG-IP Next instance you plan to deploy the application service to. For details, refer to How to: Create a BIG-IP Next instance in a VMware vSphere environment using an onboarding template.

How to: Configure BGP using BIG-IP Next Central Manager

Use this procedure to add an instance and configure BGP using BIP-IP next Central Manager:

1. Log in to BIG-IP Next Central Manager, click the workspace switcher next to the F5 icon, and click Infrastructure.
   

Note: If you have already managed instances, it will be shown in My Instances tab.

1. At the top of the screen, click + Start Adding Instances.
   

2. Enter the IP address for the BIG-IP Next instance and click Connect. You must use port 5443.
   

3. Enter the current username and password for this BIG-IP Next instance, click Next. The instance is added and listed in the My Instance page.
   

4. Click on the instance name, select Networking & Proxy, and click edit icon at top-right-corner.

5. Select Networking, provide the required inputs to L1 network, VLANs, and IP Address, click Next.

6. Click Deploy from Review and Deploy Tab.

7. Click on the Instance Name, select Networking & Proxy, and select Routes tab.

8. Click +Add to configure a new route.

9. Click Route tab > + Add to configure a new route.

10. Follow the below process to configure VRF:
    a. Enter Route Name.
    b. Select the Route Type as BGP.
    c. Provide router configuration under BGP raw configuration blob.
    d. Provide inputs as router address and password under Array of neighbour passwords.
    e. Click on Save.
    

How to: Configure RHI using BIG-IP Next Central Manager

Use this procedure to configure RHI for BGP configured instance:

1. Login to BIG-IP Next Central Manager.
   

2. Go to Infrastructure > Instances> My Instances. Click on the added instance Name.
   

3. Click on Networking & Proxy.
   

4. To add a new route select Route tab and update the required information:
   a. Enter the Route Name.
   b. Select the Route Type as RHI.
   c. In the Virtual IP Addresses, click + Create.
   d. In the RHI field, select one of the following:
   

   • ALWAYS: Always advertises the route for the virtual address, regardless of availability status.
     

   • ALL: The virtual address is up when all L4-clientsides are up.
     

   • ANY: The virtual address is up when any(at least one) L4-clientside is up.
     

   • NEVER: Do not advertise the route for the virtual address, regardless of the availability status.
     

   Note: Based on the RHI field value, the BGP configuration determines the scenario (Always, All, Any, or Never) to advertise the IP address.
   

   e. Click Save.

How to: Create an Application

Use this procedure to create an application that routes through the added IP address:

1. Log in to the BIG IP Central Manager.
   

2. Select Application and click on My Application Services.
   

3. To create an application click on + Add Application and enter below fields:
   a. Application Service Name
   b. Select what kind of Application Service are you creating?
   

   • Standard (CM will create automatic template)
     

   • From Template (Further, user should select the desired template)

4. Click Start Creating.
   

5. At least one virtual server and pool is required, so click on Start Creating to create a pool and virtual servers.

6. Click on the Pools tab, followed with + Create to create a Pool by Adding Pool name, and Service Port.
   

7. Return to Virtual Servers tab, enter Virtual Server Name and select the Pool created in previous step, click Review & Deploy.
   

8. Click Start Adding instance and select the IP from dropdown. Now click on +Add to List button.
   

9. Enter the Virtual Address and add **Pool Members.
   

10. To add new Pool members, click on the dropdown icon under Members and click on the + Pool Members. Now click on ** + Add Row** and enter the name and IP address. Save the changes and click Deploy changes.
    

11. Click Yes, Deploy to successfully deploy the instance you added.
    

The application service is created successfully and shown in ** My Application Services** tab.

How to: Verify Routing advertisement on BIG IP Next

Use this procedure to verify routing advertising on BIP-IP Next based on RHI value selection.

Note: Troubleshooting is supported only with VELOS.

1. Get the partition ID from the VELOS where the BIG-IP Next Tenant is running.

2. Use floating IP address to SSH as root to the system controller.

3. Get the Pod name for f5-fsm-tmm, run the following command.
   kubectl get pods -n partition-<partition ID>
   

Following is an example output where numbers and prefix in the Name are specific to the deployment.
[root@controller-1(velos-chassis1.f5demo.net) partition2]# kubectl get pods -n partition-2

NAME	READY	STATUS	RESTARTS	AGE
next-tenant-f5-eesv-licensing-64cff8d4b5-7p67j	1/1	Running	0	19m
next-tenant-f5-eesv-vault-6db5b645fc-25zmv	1/1	Running	0	19m
next-tenant-f5-fcdn-sync-79dbdff9f-4h72j	1/1	Running	0	19m
next-tenant-f5-fsm-tmm-59c579dd75-xv7rv	6/6	Running	0	19m
next-tenant-f5-onboarding-5db9f4c49b-zd5w4	1/1	Running	0	19m
next-tenant-f5-platform-agent-846c6954d4-nbrp7	1/1	Running	0	19m

4. Connect to route shell, run command.

kubectl exec -it -n partition-[id] [pod-name] -c f5-fsm-f5dr -- imish

For example:

1. There are two pools: one is up and the other is down.

2. There are four apps, all listening on the same IP but different ports: i.e 10.10.2.88:3000, 10.10.2.88:30001, 10.10.2.88:3002, 10.10.2.88:3003. Apps 1-3 use the up pool, while app 4 uses the down pool.

3. RHI with mode ALL for the IP address 10.10.2.88/32.

TODA should write to the DSSM for 10.10.2.88/32, and this IP address should not be advertised.