8

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?

  • Did any of the answers help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively you can answer your own question and accept the answer. – Ron Maupin Aug 6 '17 at 4:17
10

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.

5

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.

  • 1
    I think you're making this more complicated than necessary., While I don't dispute your comments in general, in this case there's nothing to be gained by adding an IGP. In this scenario, BGP advertises a default route to the access routers. Whether that's an internal or external route is immaterial. Either the traffic is going to router A or router B. Adding OSPF isn't going to make that go any easier or faster. Using a loopback address for the iBGP peering doesn't buy much if you're advertising a default route.-- if the link to A goes down, there's no reason to send traffic to A. – Ron Trunk Aug 15 '15 at 21:44
  • Even if A is the best exit path, traffic will still get there via B. That's true if you use iBGP with a loopback, on the interface, or use an IGP. – Ron Trunk Aug 15 '15 at 21:45
  • 1
    You're not wrong, but you will have to have some sort of "IGP", even if that "IGP" is a manual static for the loopback of router A (and B). And, admittedly, I'm quite comfortable running BGP and OSPF, so I would want to set this up for some future proofing (ie, there are some pretty good arguments to allow those Internet routes down to routers 1, 2, and 3 so they can make better decisions on which exit to use and thus which of router A or B to forward to). And, yes, that can be done without a full IGP as well, but it really doesn't add much complexity to make it a cleaner setup. – Jeff McAdams Aug 15 '15 at 21:50
  • You didn't address the OP's question: "What would be the benefit of replacing iBGP with OSPF?" Running an IGP with iBGP is the preferred method, but question is specific, and it is not what you answered. – Ron Maupin Aug 15 '15 at 23:08
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.

  • I'm not sure that there effectively is a full mesh, unless the core routers are configured as route reflectors. The OP didn't say anything about each of the three access routers connecting to each of the other access routers, only to the core routers. A full mesh or a mitigation will need to be implemented. – Ron Maupin Aug 14 '15 at 17:36
  • You're right. I misread that. I'll edit my answer. – Ron Trunk Aug 14 '15 at 17:38
  • 1
    I'm not clear on your intentions regarding your advice on full-mesh, but to try to clarify...the full-mesh requirement is for iBGP sessions, not actually connectivity. Even if two routers have no link directly between them, they should have an iBGP peering session between them, because the IGP will recursively resolve the next-hop to whatever intermediate router it needs to get to the iBGP peer. Route Reflection is a good idea at around 5 routes just to cut down the management effort involved, it doesn't really have anything to do with physically connectivity paths. – Jeff McAdams Aug 15 '15 at 21:07
  • 1
    Without a full mesh (either logical or physical) or mitigation, iBGP can get into routing trouble because the AS-PATH isn't updated so iBGP won't advertise routes learned from an iBGP peer. Access router A will never learn the routes originated from Access routers B and C. Route reflectors mitigate this. iBGP has always had a full mesh requirement. – Ron Maupin Aug 15 '15 at 22:12
  • 2
    Scenario: Access router A active default route goes to Core router 1, and the link from Access router B to Core router 1 is down. What happens when a host on Access router A wants to send to a host on Access router B. The traffic will never reach Access router B because Core 1 no longer has a route to Access router B because it can't learn those routes from Core router 2. A full mesh or mitigation is required by iBGP, and it has always been required. – Ron Maupin Aug 15 '15 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.