BIG-IP BGP Routing Protocol Configuration And Use Cases
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.
EmployeeAbove: 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.
- Brandon_
To close the loop on this. More than likely the reason you were seeing the /24 from both locations is that while iBGP tells you that you need a full mesh and all iBGP routers should be peered. This is the one case where the two BIG-IPs should not be neighbors.
iBGP will advertise the route to the other BIG-IP. Then because the router is peered to an eBGP neighbor it will advertise it as well.B 192.168.123.0/24 [200/0] via 10.1.10.22, client, 00:00:03
Now if you're using a floating self-IP, they will both advertise it with the next-hop the same so the routing table will just install one route. But without the next-hop modification it will show up from both devices.