BIG-IP BGP Routing Protocol Configuration And Use Cases
Is the F5 BIG-IP a router? Yes! No! Wait what?
Can the BIG-IP run a routing protocol? Yes. But should it be deployed as a core router? An edge router?
Stay tuned. We'll explore these questions ...
Published Jan 11, 2024
Version 1.0
Brandon_
Employee
Employee
MichaelOLearyEmployee
EmployeeThanks for the article Brandon_
In my case, I have a single VIP which is a /32 route. My VIP is 192.168.100.100/32, but I want to advertise a summary route, like you've stated in your article. I used the imish command "aggregate-address 192.168.100.0/24" which does the trick. Now, the /24 route is advertised, not the /32. Great.
My problem is that both the Active and the Standby unit are advertising this route with equal weight, so I am seeing my BGP neighbors with 2x next hops for this VIP range (the self IP of the Active, and that of the Standby).
My client connections are working about 50% of the time :)
What am I doing wrong?
MichaelOLearyEmployee
EmployeeI seem to have a workaround, although I still need clarification on the recommended way to do this.
I believe I have 4 ways to share a route with my BGP neighbors from BIG-IP. In each case I need to run "redistribute kernel" and, as you point out, use a route map to filter out the 0.0.0.0/0 route and perhaps others I don't want to share, so that I don't send the BIG-IP's default route to the BGP peers and take down the network.
a) I can use the imish command "network 192.168.100.0/24" when configuring BGP on BIG-IP, as is done in this KB article from F5.
b) I could create a static route to share, using F5 GUI or tmsh. However, since I can't set a next hop IP address to my own self IP, I don't think this can help me when creating a VIP range to redistribute.
c) I could create a /32 VIP and use the imish command "aggregate-address 192.168.100.0/24", as is done this lab from F5. I think this is what you mean when you say we should summarize routes.
d) I can create a VIP where the VirtualAddress is 192.168.100.0/24 and set Route Advertisement to Enabled. It's a single VIP, and the imish command "show ip route" shows that it's directly connected to my Active device, and not my Standby.
I think that only option D gets me the VIP range advertised from the Active device only. Options A,B,C all seem to lead to the situation where both Active and Standby devices are advertised as equally-weighted next hops for the route.
Am I right?
- Brandon_
Well hello there Michael and thank you for stumbling on my article. I had the intention to write more of the series, but as there really wasn't a lot of feedback I didn't think anyone really wanted to hear from me. My goal was to cover how HA behavior works with BIG-IP and BGP in the second in the series. And well, your questions inspired me to pick this back up.
But to quickly summarize. If a BIG-IP HA-Pair is set up properly the kernel routes should only show up in the routing table IF the BIG-IP is active. The standby for the traffic-group will not have the kernel routes to redistribute.
This is why, in my lab which you also stumbled upon; I use aggregate-address. BGP is a different routing protocol in that it generally must learn a route from another routing protocol, or static, or in this case from the kernel. Without the /32 kernel route for the BGP process to learn something in the /24 aggregate it won't advertise the /24. This would leave me to believe that the /32 is active in the kernel on both devices which is why you saw it advertised from both.
One fun fact. When you use aggregate-address it will install a /24 route to null0 in the routing table to advertise. This is also why if there are individual VIPs in the range they all should have advertisement enabled assuming you don't want the route withdrawn if any particular /32 fails.
TSSRShotAltostratus
Shame on me! I’ve been sitting here patiently waiting on the next installment.
I am currently putting off a BGP config due to HA and lack of clear guidance, I should have just asked!
In my world, I don’t control the upstream neighbor router, so it’s something I have to plan extensively.
Simple First Question:
When forming a neighbor-ship with the upstream router, and I have a 2 - i7820 HA pair, do I give them the Floating IP? Or do I build basically two neighbors, one in each physical i7820 with their non-floating IP?
- Brandon_
Oh my! Now I'm getting motivated to finish part 2 which is focused on how HA works with a BIG-IP and BGP. So thanks for validating that there's some value there.
So to answer your question TSSRShot
When forming neighbor relationships with upstream routers, you will establish the neighbor with the local self-IP on each BIG-IP. So the router will have two neighbor statements and the BIG-IP will have 1 or 2 depending on your upstream configuration.
The value of the floating self-IP in this arrangement is that the Active router will advertise the networks you want with a next-hop of the floating self-IP.
Now why would that be good? Well in a failover scenario the next-hop doesn't change. So no matter which router is Active, the next-hop and all flows associated with it won't change. The upstream routers don't need to learn the new next-hop and redirect traffic that way so any flows in-flight aren't interrupted.
MichaelOLeary was nice enough to link to a BGP lab I developed and taught a couple years ago at our user conference. Its retirement is the inspiration for this intended series and it might help you with some additional thoughts. But feel free to fire away questions while I diligently come up with smart-alecky things to say for the second installment.
https://f5-agility-labs-adc.readthedocs.io/en/latest/class5/module1/lab1.html#create-an-aggregate-route-since-many-service-providers-will-not-accept-anything-less-than-a-24
- Brandon_
Above: Note the 'active' state and the 'K' route (and route to null0)
Below: Note the 'Standby' state and no additional routes.
- Brandon_
Now for a little bit on the difference between the network statement in BGP and the aggregate-address statement.
For the network statement to work by default back in the day, when dinosaurs configured routers with their little T-Rex hands there must be an exact match in the routing table.
I say by default; because that was the default behavior and many of us packet heads after configuring our BGP statement, the next immediate command was 'no auto-summary'. Which now is the default and doesn't show up in the configuration anymore.
So now, let's look at your other suggestion of creating a /24 virtual server.
A lot of times, the /24 virtual server gets created as a "catch all" for the subnet. This can be a good thing in that I can log what hits IPs within the range that don't have a more specific virtual server attached to them. This is especially good if you're migrating things around. Like an application moves over to another network and you can see if for some reason that route isn't getting honored somewhere. There's lots of ways to have fun with it.
And yes, if it's tied to the failover traffic-group it will only be a kernel route on the active device. The problem will be that the route won't be withdrawn without some failure situation. In this case I would think about creating a pool and assign a monitor with an alias configuration that monitors something downstream.
