BIG-IP BGP Routing Protocol Configuration And Use Cases
Employee
EmployeeOh 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
Altocumulushi, 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.