OSPF or iBGP for interior routing protocol?

Question

So the plan is, two core routers each with a eBGP session to one of two ISPs with full routes. Both routers publish their full tables to each other so they can control traffic flow more intelligently via iBGP.

For argument's sake three access routers have a path to each core router. I was going to configure iBGP and publish a default route from each core router so they have some resilience against hardware failure and use filters to control what routes are actually sent to the access devices.

I have heard that people use OSPF for their IGP generally, of course there's an element of it being case specific.

My question is: What would be the benefit of replacing iBGP with OSPF?

Answer 1

iBGP requires a full mesh or use of mitigation like confederations or route reflectors, BGP doesn't converge with anything like the speed of OSPF, etc.

Each OSPF router would have a full understanding of all the routes that are in the area in which it resides without needing a full mesh, and it converges very, very quickly.

Using an IGP is recommended with iBGP. Without the IGP, iBGP must neighbor on external-facing interfaces, with an IGP, iBGP can neighbor on loopback interfaces which never go down, and can have multiple paths to reach.

I have seen iBGP-only for local routing, but it is more difficult and fragile.

Answer 2

First off, I would dispute the assertion that some others have made that OSPF converges faster than BGP, but more on that later. To answer the OP question first.

You want both.

iBGP is designed to run between loopback interfaces on routers and it doesn't (at least without tweaking and turning some knobs) change any attributes (which includes next-hop) of the routes that it's advertising.

So what are the implications of that?

Let's call your border routers router A, and router B and your for-argument's-sake three access routers router 1, router 2, and router 3.

Router's A and B get full Internet feeds from your upstreams, with next-hop set to the upstream's interface address on the interconnecting link. When those routes get passed on via iBGP, again, unless you tweak, the next-hop of the route that routers 1, 2, and 3 receive is still the IP address on the far side of that interconnect link.

Routers will do a recursive lookup to find the path to that IP address and then use that next-hop when the route is installed in the forwarding table. "But," you say, "I'll use next-hop self." See the next paragraph for how this works out.

"But," you may also say, "I'm only advertising defaults down to routers 1, 2, and 3." OK, but that default route has to come from somewhere...if its an already existing default (say a static) it'll have a next-hop that'll get used. If its a generated default...it'll probably be using the loopback address that the iBGP session is running on as the next-hop. Again, this won't be seen as an interface, or directly connected route in routers 1, 2, and 3, so they'll still have to do a recursive lookup to find it.

So, you need some sort of IGP running, such as OSPF, IS-IS, or EIGRP, or even just a lot of pain-in-the-backside-to-manage statics, for the reachability to work for the recursive lookups.

"But," you say again, "I'll run the iBGP sessions on the interface addresses rather than the loopbacks. OK, but now your BGP peering session is dependent on the interface being "up" to work. So, for example, if the interface between router 1 and router A goes down, so does the iBGP peering session running on that interface. But router 1 still has the ability to send traffic to router A, it just has to do it via router B. So, you want the iBGP session to stay up, even when those interfaces go down, because your ultimate next-hop is still over yonder, and over yonder is still reachable through another path...OSPF (I use OSPF, but you can sub IS-IS and EIGRP anywhere you see OSPF here) will figure out that other internal path and take care of building the forwarding table correctly in that recursive lookup.

So, yes, you can probably tweak enough knobs and get a pure iBGP setup working without any IGP setup...but please don't...it'll be a lot of work, it'll almost certainly be flakey.

Do yourself a favor and turn on OSPF, or IS-IS, or even EIGRP if you're a pure Cisco shop (but please consider whether you really want to accept that vendor lock-in if you do...consider future potential decisions to use a different vendor's gear...even if only to try to keep Cisco honest on pricing with you). Turn it on for all of your interfaces between your routers, and also set it up on your upstream connection with the passive setting, and probably on your downstreams from your access routers with the passive setting as well. Then set up your iBGP peerings between your loopbacks. Consider route reflectors (probably on routers A and B) to cut down the configuration effort required...it makes sense at about 5 routers to start doing that.

It really is the sanest way to do this.

Now, to protocol convergence speeds.

Most people think BGP is slow and OSPF (or whatever) is fast because of the common use cases for these protocols. People typically pull full Internet, or at least a significant fraction thereof, into BGP, while only handling internal routes in OSPF (10s to 100s, maybe into the low thousands of routes). So, let's assume you're pulling half of the Internet routes into BGP...try building an OSPF area with 250,000+ routes and let me know how that goes for you. Let's see if that converges faster than BGP does...or ever unless you have a really beefy control plane on your routers.

BGP, for a given situation, can frequently converge, or reconverge, faster than OSPF and others, at least depending on how you measure it. If you include OSPF's neighbor discovery on a broadcast network, BGP is almost certain to win for a similar mix of routes.

The other difference is that BGP will start putting routes in routing and forwarding tables before its finished (re)converging, which can be a benefit, while OSPF implementations will almost certainly wait until the very end before it starts putting routes in routing and forwarding tables. Sometimes having a partial route set converged can be useful. Sometimes not.

Answer 3

While everything @RonMaupin says is true, in your particular case, with only five routers, there is not a lot to be gained by adding another routing protocol.

Since you don't have a full mesh, you will have to configure your core routers as route reflectors.

The only real downside is that BGP converges more slowly than OSPF, but there are ways to minimize that deficiency.