IBGP as an IGP

BGP convergence can be improved with BFD. Turn up BFD on the interfaces, set 'fall-over bfd' on the neighbors. For platforms that don't support BFD, fast peering detection via 'fall-over' is also an option. The esteemed Ivan Pepelnjak has written just such an article: http://www.nil.com/ipcorner/DesigningBGPNetworks/

You can mitigate the configuration scalability issue on your route reflectors with BGP dynamic neighbor discovery, 'bgp listen' on IOS or 'allow' in Junos. Note, the IOS command seems to only be available on higher end platforms - e.g. the ASR.

Some remarks:
1) "No dynamic discovery" is not really a disadvantage. Actually, for OSPF network I prefer 'passive-interface default' in most cases.
2) Not so complex. Look at EIGRP. =)
3) May be. But not really the main problem. We can always play with route-reflectors, confederations and next-hop-self.

Number 4 (convergence) is really one of the main reasons. That's clear. BFD isn't enough. We have to consider bgp scanner, update batching, etc.
Here is a great post about BGP convergence:
http://blog.ine.com/2010/11/22/understanding-bgp-convergence/

Another significant reason not to use BGP as IGP is that it's "a bad idea". =)
It's simply impossible to configure that correctly in redundant topology. If loopback is the source for BGP updates, static or IGP is mandatory. If not, network will never work correctly.

Just to clarify. The post is very nice anyway. And it will be very useful for beginners.

BGP is designed as an exterior gateway protocol. iBGP facilitate the reachability to other iBGP peers such as BGP route reflectors. It should not be used as an IGP. There is generally no good reason to use BGP as an IGP.

It is true that BFD can increase the protocol awareness of the interface failure. However consider the case when your upstream eBGP interface is down due to a physical problem and then quickly recovered, you may not want to BGP to react to such temporal event. You would not want to update 300k prefixes for your BGP topology for such case.

@sam: IBGP is used whenever you need to run BGP internally; e.g. to share a full routing table between two edge routers.

@StuckInActive: I didn't bother covering BFD since it's really an independent protocol which can be employed by IGPs as well.

@Petr: 1) Like I said in the article, although you may not have a use for neighbor discovery, many organizations prefer it.

2) EIGRP employs a simple numeric metric. Yes, the calculation to arrive at the metric is a tad complex, but in the end it's just a number like OSPF's cost. By contrast, IBGP evaluates various route attributes including weight (on IOS), local preference, and origin. Further, IBGP assigns no useful metric by default.

3) As the article explains, using route reflectors does not solve the problem of excessive route recursion.

@misteryiz: Scale. Modern SP design suggests IGP such as OSPF or ISIS be used to reach loopbacks of routers only. This leads to a very small/fast converging IGP table. Then use iBGP to carry customer/external routes. Your IGP responds to internal path failures and your iBGP follows the path your IGP has setup. No need to rely on iBGP to detect the failure.

Your IGP would not respond as quickly if it had to carry thousands of prefixes being flooded on a state change.

iBGP communities are quite helpful categorizing prefixes and communicating cool tricks as RTBH.

@stretch
Example: for a large distributed enterprise network with no significant convergence time restrictions BGP would be the best choice.
Question: What considerations are really critical, when we have to choose between IGP based and BGP based network design?

I just mentioned, that problems 1-3 are not so big:
1) matter of taste, not critical
2) Path attributes are really good. On of the best BGP capabilities. Not really so complex, as it is usually described. Bestpath selection is always clear.
In contrast. EIGRP: metric is simple, but not informative, query propagation problem, etc. OSPF: nice metric, but have to think about various LSAs, hard to filter... really RFC2328 is great challenge. IS-IS: also assigns no useful metric by default.
3) Confederation. One router size subAS. No excessive recursion. I don't separate IBGP and EBGP sessions here, the protocol is always the same.

So, I'd focus on following reasons: a) convergence; b) not designed to work inside AS without IGP support (session restrictions, etc.); c) sometimes we don't need anything more powerful then IGP.

Really, I don't think that my description is better. Post content is good as always. Just want to preserve beginners from thinking that IGP vs BGP choice is simple.

The next question is usually: if OSPF, for example, is so good, why not to use it for inter AS routing? =)
And by the way, what's the real difference between IGPs and BGP, if I can use (and sometimes have to use) BGP for intra AS routing? (based on previous CCSI experience).

Interesting, but I'm not sure the real use case of iBGP is taken into account and only confuses people who have networks too small to even consider iBGP. You can't rely on IGP 'internally' for extremely large networks - and iBGP fills that void because it can handle full tables in appropriate architecture placements. Consider, an even small, ISP. Say 500k customers, spanning multiple states. Do you really think behind that AS number they're going to be running one large IGP? If you think so - think again. This is where iBGP is a requirement and a security improvement as, like, IPsec - it has to be specifically configured for distribution of these large networks. People make far more mistakes and/or run inefficient (i.e. improperly configured networks) who run IGP only networks. It has to do, partially, with the fact that if it works - there's nothing wrong. I've seen misconfigurations in almost ever large corporate network I've consulted for. Things like link costs have not been appropriately accounted for over the years (really your 10G link has the same cost as those 1Gs - interesting).

Are IGPs required with IGP? Most certainly - your core concept of the fact that iBGP is a bad IGP is correct, however reading this does not lend to the usefulness of iBGP in large networks.

Very glad to have come across this article, and some valid views shared thanks to all for that.

Let me first mention something before I forget, with a mixture of EGP and IGP, one often ends up with multiple of redistribution, and redistribution, if not understood intimately, can cause pain and even financial loss to any organisation.

The biggest ever drawback with OSPF is with its non-existent filtering capabilities.

Why do some of us believe a network cannot be built with just BGP, be it an small or large one.

I am currently working with a medium/large size non-mission-critical enterprise who are running OSPF as IGP and BGP to external providers. Fortunately the topology is relatively small. Networks have become 'flatter'in design over the past 7-8years since devices have become much more powerful.

In my particular case with 'flat'ish'design and low number of prefixes, I'm electing for eBGP between DCs. As you know there are a plethora of knobs to tweak paths etc for redundancy. OSPF allows for path limitations too, but with larger topologies one could run out of 'options'

Manually configuring neighbors is better in most situations, but where there are hundreds or thousands of neighbors, then perhaps not. That said some here have highlighted that in fact dynamic neighborships, if required, can be achieve with BGP.

I could go on here, but lets be straight about something. You can build a network with BGP (iBGP or eBGP) only if you wanted i.e. with no IGP.

BGP is complex but so is OSPF and so is EIGRP, and with redistribution it becomes even more challenging.

The route-recursion drawback highlighted by the author could be a concern in very large networks made up of routers that are NOT powerful and which have excessively large routing-table entries and volume traffic.

HI Stretch,

Nice article. Does the ibgp router need to have a route to its ibgp peer in its routing table to keep the ibgp session up?

I have two routers doing ibgp with one another using loopback interfaces and even i shutdown the one router, the other router keeps the ibgp peering up until end of the timer, even though it doesnt have the route to the peer's loopback anymore. Is this normal behavior?