How to: Configure Routes¶
Overview of routes¶
The BIG-IP Next supports advanced routing features, including static routes and dynamic BGP routing, enabling efficient packet forwarding, DNS resolution, and optimized path selection for network reliability.
Use the static routes: route gateway, route interface, or route reject type for destinations that are not located on the directly-connected network. Depending on the route settings you choose, the BIG-IP Next can forward packets to a specified network device (such as a next-hop router or a destination server), or can drop packets altogether.
The DNS net resolver route type is a resolver cache used by BIG-IP Next to perform DNS resolution, it caches DNS responses so that it can respond to subsequent DNS queries.
The validity of the cached DNS responses is determined by their respective Time-To-Live (TTL) and the oldest entries are removed by the cache to make space for new entries when the cache size is breached. Additionally, the DNS resolver does not perform prefetch to keep entries in the cache or prevent them from expiring.
When you configure the DNS net resolver with a forward zone, the DNS net resolver sends DNS queries that match the forward zone to one server from the list of configured servers for resolution. While the BIG-IP Next load-balances the queries among the list of configured servers using its internal algorithm, it does not allow you to configure this algorithm. When no forward zone is configured, the DNS net resolver randomly picks a root hints server to resolve DNS queries. If the root hints server takes too long to respond, the DNS net resolver continues DNS resolution recursively through the list of root hints servers until the query is resolved.
Also, the BIG-IP Next advanced routing supports the Border Gateway Protocol (BGP) protocol for external networks that supports the IPv4 and IPv6 addressing formats. The 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 reachability and preference metrics, such as Autonomous System (AS) path length, local preference. The BGP RHI checks for the availability of a virtual IP address, if it is available, then the RHI injects the virtual IP address in the BGP message.
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 optimize 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 neighboring 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 optimize 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.
Use the following topics to manage routins:
Note: After creating required routes, create an application that routes through the added IP address. For more information, refer Create an application service.
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.
View routes¶
Use this procedure to view routes:
Log in to BIG-IP Next Central Manager, click the Workspace icon next to the F5 logo, and then click Infrastructure.
Click on the instance name. The instance properties display.
Select the Networking & Proxy tab. Select the Routes tab. The list of routes displays. If no route is available, then click Add to add a route.
To create Route Gateway, Route Interface, or Route Reject type routes, refer Manage static routes.
To create DNS net resolver route type, refer Manage DNS net resolver.
To create BGP and RHI, refer Manage BGP route and Manage RHI.
Click Save.
Manage DNS net resolver¶
Use this procedure to manage DNS net resolvers.
1. Log in to BIG-IP Next Central Manager, click the Workspace icon next to the F5 logo, and then click Infrastructure.
2. Click on the instance name. The instance properties display.
Select the Networking & Proxy tab. Select the Routes tab. The list of routes displays. If no route is available, then click Add to add a route.
In the Name field, specify the name for the route.
In the VRFs field, select the default or non-default VRF.
In the Route Type, select DNS net resolver.
7. In the Name field, specify the name of the DNS cache net resolver.
8. In the Description field, specify the description for the DNS resolver.
9. In the Answer Default Zones field, when enabled, the system answers DNS queries for the default zones localhost, reverse 127.0.0.1 and ::1, and AS112. When disabled, the system passes along the DNS queries for the default zones.
In the Forward Zones section, specify the forward zones in FQDN format with their corresponding IP addresses and service ports of a recursive nameserver that answers DNS queries when the response cannot be found in the DNS resolver cache. You can specify multiple nameservers for a forward zone. The BIG-IP Next sends DNS queries that match the name of the forward zone to the list of configured nameservers.
In the Message Cache Size field, specify the number of bytes allocated for the message cache. The default value is 1MB.
In the Nameserver Cache Count field, specify the maximum number of DNS nameservers to cache.
13. In the Nameserver TTL field, specify the time to live in seconds for DNS nameservers in the cache. The default value is 900 seconds.
14. In the Negative Cache Size field, specify the number of bytes allocated for the negative cache. The default value is 1 MB.
15. In the Random Query Name Case field, when enabled, the BIG-IP Next randomizes character case in DNS queries issued to the root DNS servers.
In the Use IPv4 field, when enabled, the BIG-IP Next can use IPv4 to query back-end nameservers.
In the Use IPv6 field, when enabled, the BIG-IP Next can use IPv6 to query back-end nameservers.
In the Use TCP field, when enabled, the BIG-IP Next answers and issues UDP-formatted queries.
In the Use UDP field, when enabled, the BIG-IP Next answers and issues TCP-formatted queries.
20. Click Save.
Manage static routes¶
Use this procedure to manage static routes.
Log in to BIG-IP Next Central Manager, click the Workspace icon next to the F5 logo, and then click Infrastructure.
Click on the instance name. The instance properties display.
Select the Networking & Proxy tab. Select the Routes tab. The list of routes displays. If no route is available, then click Add to add a route.
In the Name field, specify the name for the route.
In the VRFs field, select the default or non-default VRF.
In the Route Type, select one of the following method through which the BIG-IP Next forwards the packets:
Route Gateway: Select this option when you want the next hop in the route to be a network IP address. This choice works well when the destination is a pool member on the same internal network as this gateway address. The Destination, Gateway, and VLAN Name fields are available when Route Gateway option is selected.
Route Interface: Select this option if you want the route packet to pass through the interface of the next hoop.
The Destination and VLAN Name fields are available when Route Interface option is selected.Route Reject: Select this option when you want the BIG-IP Next to reject packets sent to the specified destination.
The Destination and IP Address Prefix fields are available when Route Reject option is selected.
Click Save.
Manage BGP route¶
Use this procedure to manage BGP routes:
Log in to BIG-IP Next Central Manager, click the Workspace icon next to the F5 logo, and then click Infrastructure.
Click on the instance name. The instance properties display.
Select the Networking & Proxy tab. Select the Routes tab. The list of routes displays. If no route is available, then click Add to add a route.
In the Name field, specify the name for the route.
In the Route Type field, select BGP.
In the BGP raw configuration blob field, specify the router configuration.
In the Array of neighbor passwords section, specify the IP address and neighbor password details
Click on Save.
Manage RHI¶
Use this procedure to manage Route Health Injection (RHI) in dynamic routes:
Log in to BIG-IP Next Central Manager, click the Workspace icon next to the F5 logo, and then click Infrastructure.
Click on the instance name. The instance properties display.
Select the Networking & Proxy tab. Select the Routes tab. The list of routes displays. If no route is available, then click Add to add a route.
In the Name field, specify the name for the route.
In the Route Type field, select RHI.
6. In the Virtual IP Addresses section, specify the IP address.
In the RHI section, select the type of route advertisement, the following options are available:
Any (default): The virtual address is up when any (at least one) L4-clientside is up.
Always: Always advertises the route for the virtual address, regardless of availability status.
Never: Do not advertise the route for the virtual address, regardless of the availability status.
All: The virtual address is up when all L4-clientsides are up.
Click Save.
Verify routing advertisement¶
Use this procedure to verify routing advertising on BIP-IP Next based on RHI value selection:
Access the BIP-IP Next instance through SSH.
Run kubectl get pods. Once all pod details are available, users must log into the TMM pod to access
f5dr
.
3. Run this command to get into f5dr mode by accessing the TMM pod.
kubectl exec \-it <tmm\_pod name> \-c f5-fsm-f5dr – imish
4. Use imish command to enter the imi shell terminal, and use the enable or en command for accessing debug mode.
5. Verify the BGP configuration and view currently advertised routes on the BIG-IP Next by using the command show ip route to confirm routes to the virtual as entry K from the list.
Note: Dynamic routing debugging is supported for VE, VELOS, and iSeries.
Following is an example routing advertisement scenario:
Consider the following configuration:
An RHI is created with virtual address (192.10.2.88) with the RHI value set to ALL.
There are four applications, each listening on the same IP but with different ports:
192.10.2.88:30
192.10.2.88:31
192.10.2.88:32
192.10.2.88:33
Each application has two pool members configured on the L4 server side.
One application L4 server side is down, with both pool members in a down state.
For the other three applications, the L4 server side is up, with either one or both the pool members active.
This configuration creates four L4 stacks (L4 client and L4 server sides) pointing to the same virtual address (192.10.2.88). Out of these four stacks, one is down, while the other three remain up.
The route will not be advertised because the RHI value is set to ALL for the virtual address, and all four stacks are not in up state.