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
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_Employee
EmployeeWell 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.
- 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.
TSSRShotNimbostratus
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
wtwiggsAltocumulus
hi, pardon me for jumping in... but also was waiting for part 2 and neglected to reply to show my active interest... thank you for this article and all the follow up comments!
here are a few comments/questions I also have:
- ospf vs bgp? and more specifically, if the big-ip is "inline" with the server subnet, any thoughts on using nssa configuration in ospf vs bgp aggregation/summarization to keep route tables optimized? since servers are all south of the big-ip and external/default/client routes all have to go north to the border router/firewall
- differences in behavior for HA in ospf vs bgp, and any pros/cons of each
- we are using a combination of ospf/nssa within a DC and ibgp across to the second DC via DCI link, with traffic groups shared across both DC big-ip's so we can "float" a VIP from one DC to the other and maintain a single configurations... virtual server, pool, monitor, etc. but this has also had side effect on bgp announcing the floating self-IP, and basically breaks this behavior... any thoughts/suggestions on a better approach?
- we're now looking at taking the big-ip and moving it to another part of the DC network, north of the border router/firewall, and not fully inline anymore but still inline for traffic related to the VIP - note we are avoiding snat and that is why we are inline or want to be inline - and then using bgp neighborship to each border router/firewall and the WAN fabric routers to attract/inject VIP traffic and policy based symmetric return from the border router/firewall - again avoiding snat
- any dependencies/limitations on bgp or ospf with big-ip next?
sorry if my comments/questions seem all over the place but we have been using routing for several years now and planning to migrate in the coming months/years to even more iterations of routing/rhi together with a fabric/vxlan based DC/DCI... so am very interested in any/all comments and articles you come up with... thanks in advance for considering my input to the topic