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.
AltostratusShame 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
- Brandon_
Welcome wtwiggs
Let's see if I can distill down your questions.
- 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
Well now we get in to some religious talk. At least it's less contentious than a political discussion.
OSPF and BGP have a long history of fighting over who is right and who's going to be the routing protocol of the data center. It's been a bloody battle, but there's a couple things to keep in mind. BGP generally needs to learn it's routes from somewhere else like an IGP. e.g. OSPF The usual argument is that OSPF has faster convergence, but there are timers that can be tuned if BGP convergence needs to happen quickly.
So if you're already set with running OSPF internally, and between security zones and OSPF and it's scaling for you then keep it up. I often recommend to people to think of the BIG-IP as and ASBR. In the OSPF case where you're set up as an NSSA that makes sense especially if you're advertising routes for the server networks behind it without knowing your network specifically it could likely just be a stubby area.
BGP works in providing separation of autonomous systems in the same way as OSPF areas. It also works well when the router team and the BIG-IP team aren't the same so the controls can be implemented in BGP similar to an ISP and a customer.
BGP and OSPF implementations both advertise the route from the active device if implemented properly. In Michael's case there's a slight deviation in the iBGP design consideration for a full mesh if you're not using a floating Self-IP in that you don't want to establish a neighbor relationship between the two BIG-IPs.- 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
I'm thinking a diagram would be better here. From what you're describing I would be concerned with asymmetric traffic flows without SNAT unless you're doing DSR. But it seems like you're trying to solve it with PBR? PBR is an established way to do this. You create tunnels to the servers and the return traffic bypasses the BIG-IP. That of course means you need to play nice with the server team. :-)
- any dependencies/limitations on bgp or ospf with big-ip next?
I don't think OSPF is available yet in BIG-IP v20/Next. So there's that.
It's been on my list to dig in to Next's BGP implementation a bit deeper, but I'm clearly running behind. I was consulted on some of the design/planning work and peeked at the final. It's in there and from what I've seen it's full featured. I know there's some changes coming to Next, so I'd give it a little time for the dust to settle.
- TSSRShot
So I’ve since learned that the upstream org will not provide an extra IP for a floating IP. Basically I get 2 x P2P circuits and a /30 each.
Am I sunk? Just going to have to accept minor loss during change over actives?- Brandon_
Sunk is such a negative word. This is a happy place. :-)
From what it sounds like you're looking at each BIG-IP device in a cluster peered with a different external router across the /30 links?