BGP and OSPF

[fatalXerror]

Hello, need your advice on how to choose whether to go for iBGP or OSPF for a production environment? What is typically the main factor to decide whether to go to either of the routing protocols?

Why is there an iBGP if there is already IGP like ospf or eigrp? This is where i think i am getting confused.

Thank you for your suggestions.

[MHM Cisco World]

Casr need ibgp

If you have two edge router connect to two ISP via ebgp then you need ibgp for redundacy.

Inside mpls cloud we need ibgp between PE's.

Why we not use opsf' bgp give more control on prefer prefix than other igp.

Ebgp vs ospf 

Ebgp used between AS ospf and other IGP used inside AS.

MHM

[Joseph W. Doherty]

Main factor for choosing?  What your needs are.  Generally, an IGP is a better choice for interior routing. Usually, iBGP would only be used in conjunction with eBGP.

Why is there a iBGP?  Mostly to work in conjunction with eBGP and avoid directly burdening all your interior routers.

[Joseph W. Doherty]

BTW, you didn't mention what kind of "production environment", but usually even in large ISPs, internally, an IGP (often IS-IS) is used in conjunction with BGP.  I.e., not unusual to see both an IGP and BGP used.  What would likely be unusual is BGP being used alone.

[liviu.gheorghe]

iBGP is usually used in Service Provider networks where you need BGP attributes transported throughout the network. BGP attributes are used for route manipulation in such networks.

Also, by redistributing eBGP routes into a IGP will lead to losing the BGP attributes. Redistribution of eBGP into a IGP being possible in cases where you don't have the full BGP table which is around 900K routes. An IGP isn't designed to handle this large amount of routes in it's routing table.

For Enterprise networks where you don't care about BGP attributes, you are better served by IGP's like OSPF or EIGRP.

[Blue_Bird]

Hello fatalXerror ,

The need for BGP within an AS typically occurs when multiple routing policies are needed or when transit connectivity is provided between autonomous systems.

You might assume that redistributing the BGP table into an IGP overcomes the problem, but this not a viable solution for the following reasons:

Scalability:  The Internet has 800,000+ IPv4 network prefixes, and it continues to increase in size. IGPs cannot scale to that level of routes.

Custom routing: Link-state protocols and distance vector routing protocols use metric as the primary method for route selection. IGP protocols always use this routing pattern for path selection which would normally be deemed suboptimal from an IGP’s perspective. BGP uses multiple steps to identify the best path  and allows for BGP path attributes to manipulate the path for a specific prefix (NLRI).

Loop Prevention: AS_Path can be used for detecting loops for eBGP neighbors because the ASN is prepended when advertising to another AS.However, iBGP peers do not prepend their ASN to AS_Path, No other method exists for detecting loops with iBGP sessions. For this reason for iBGP full mesh requirement with in the autonomous system.

Best regards
******* If This Helps, Please Rate *******

[Giuseppe Larosa]

Hello @fatalXerror ,

>> Why is there an iBGP if there is already IGP like ospf or eigrp? This is where i think i am getting confused.

The reasons to use both an IGP and iBGP are the following:

- the IGP is used to advertise loopback interfaces that are used as iBGP session endpoints

- iBGP cannot be run without an IGP . i BGP provides much more scalability then an IGP and also the multiple address families support for  large number of services : MPLS L3 VPN ,  MPLS L2VPN ,  EVPN , and so on .

So the modern approach in service provider networks is to use both . The IGP provides infrastructure and all services and customer routes are in BGP.

To be noted in an MPLS cloud internal device that act as P nodes don't need to know what they are switching they just change the topmost external MPLS label to send the packet on the LSP to the destination PE node.

For this reason there is no need to redistribute BGP routes into the IGP.

Hope to help

Giuseppe

[Joseph W. Doherty]

"iBGP cannot be run without an IGP"

Correct me if I'm mistaken, but technically, I believe it can be, although it often would be a freaking nightmare!  I have in mind a physical full mesh with iBGP running across shared network links.

[Giuseppe Larosa]

Hello @Joseph W. Doherty ,

yes iBGP might be run without an IGP but it can be  a nightmare and I have in mind peering with loopbacks. The most used solution is to have an IGP that advertises them.

I remember also some old thread of someone attempting to do this and results were not so good.

The key concept IMHO is that BGP is used for different services instead of overloading the IGP.

Just to make an example having 50,000 of OSPF external routes can become an issue when programming the forwarding plane for the simple reason that high end router platforms are not tested for this.

Hope to help

Giuseppe

[Joseph W. Doherty]

BTW, to all readers, I'm certainly not endorsing not using an IGP with iBGP.  As Giuseppe suggests, it's likely the most used solution, especially when dealing with more a than a couple or very few iBGP routers.

Even loopbacks, could be supported in iBGP without an IGP using static routing.  But, static routing also becomes a nightmare as you scale up.

Again to OP's question, when to chose an IGP vs. BGP, much depends on your requirements.  Generally, IGPs and BGP were designed for routing with some very different requirements in mind, many of which have been described in the many excellent replies in this thread by Giuseppe and others.  I will say, choosing between where to use an IGP vs iBGP is often much simpler than choosing between OSPF vs. EIGRP (on Cisco platforms).

Also BTW, to OP, it might help somewhat, if you consider iBGP a routing protocol, it's not, BGP is the routing protocol, just with different operational rules for dealing with peer BGP routers in the same AS (iBGP) vs. different ASs (eBGP).

Those rules probably have much to due with what an AS is expected to be.  A network assumed to work under different administrative control. There's much bound up in such an assumption.

Appreciation what an AS is, or might be, is much like appreciation of what the Internet is too.

Something many do not get to see first hand, or even read about, is what often goes on, behind the scenes, between major Internet "providers"; and I don't have the technology in mind, but the wheeling and dealing over $$$.

I mention this, because BGP supports aspects of networking beyond the technical issues of getting packets from A to B, things IGPs do not.

[Richard Burts]

I am going to take a slightly different approach in answering the original poster. Let us start by considering differences between "interior" protocols (like OSPF) and "exterior" protocols (BGP). The interior protocols are intended for use within a single administrative domain (typically within a single company or division of a company). The interior protocols evaluate and make decisions based on attributes of the path being used (how many hops, what is the bandwidth/capacity of the links, etc). The exterior protocol (BGP) is intended for use between administrative domains (between companies). The exterior protocol does not evaluate attributes of the path being used but evaluates things like how many AS are contained in the AS path, which is part of the advertisement.

BGP uses the concept of AS (Autonomous System). Within BGP there is a difference in whether the BGP neighbor is part of your AS (IBGP) or is in a different AS (EBGP). If your administrative domain/company wants to communicate with other administrative domains/companies on the outside, then it runs EBGP (typically with an ISP). If you are concerned with possible single points of failure you might run EBGP with a second ISP. If you are running EBGP on two (or more) routers then you would run IBGP between those routers.

The OP asks about why we might choose IBGP and that is pretty simple. You would choose IBGP if there were two (or more) routers in your administrative domain that were running EBGP.

[Joseph W. Doherty]

BTW, what Rick left out, multiple (same AS eBGP routers) would almost always use iBGP between them, if the intention is to share the BGP routes between them (without involving an IGP).  It's possible you might run eBGP just to obtain a default route from the other eBGP peer.  Redundancy is still possible without the iBGP peering.

iBGP peering, though, allows traffic hitting one of your eBGP routers, with actual eBGP routes (beyond the default route) to route over to another eBGP router with a better route path to the destination.

Also BTW, could you use iBGP as the only interior routing protocol?  You could, but it would be rather "ugly".  Try it in something like an emulator (e.g. Cisco's CML), or on real equipment in a lab, and experience the "pain".

So, as I wrote initially, and Rick's posting too, unlikely you would see iBGP being used without eBGP being used.

Also following Rick's different approach, consider a business with 3 departments, each running their own IGP of choice, in this case, departments A and C have chosen to use OSPF while department B uses EIGRP.

Departments A and C decide they want their networks to intercommunicate, using department B as a transit, all retaining their own/full administrative control, but share OSFP attributes.  How might you do this?

Well you could do route redistribution between A and B and also between B and C.  But, since different routing protocols are being used, you may bump into some issues during "translations" between OSPF and EIGRP.  Further, perhaps department B, although willing to act as a physical transit, doesn't, or shouldn't, share actual routes between its routes and the other departments.  What could you do?

Perhaps define a tunnel between departments A and C, crossing department B, and run OSPF across the tunnel, perhaps (or not) doing OSPF redistribution between A and C.  (The "or not" could be combining A and C into a single OSPF domain.)

If you understand the foregoing, basically that's what an iBGP peering connection provides, a way for BGP routers to share information across a transit network, yet without having to directly interact with the transit's routing information.  (NB: I'm trying to convey a common/major iBGP concept, but there's more to BGP/iBGP/eBGP; i.e. iBGP isn't just a GRE tunnel replacement.)

[Joseph W. Doherty]

Just a follow-up FYI:

You asked about using iBGP OR OSPF.  I, and others, noted iBGP (almost) always is used in conjunction with an IGP, not (usually) in lieu of an IGP.  I mentioned, you might use iBGP without an IGP, but beyond 2 or 3 routers it would likely be a nightmare.  (More on this in a moment.)

You also asked why there's iBGP at all if we have IGPs like OSPF or EIGRP.  As I, and also as others (better), described, usually iBGP is being used to pass along eBGP routes, which for multiple reasons, you do not wish to inject into your interior routing topology.

Back to iBGP, alone, being a nightmare.

Today, spent a few hours trying things in a CML lab with four routers, i.e.:

Set up the interfaces, and added a loopback on each router to represent other networks.

!iosv-2
en
conf t
int lo0
 ip address 192.168.6.1 255.255.255.0
int g0/0
 ip address 192.168.3.2 255.255.255.0
 no shut
int g0/3
 ip address 192.168.7.1 255.255.255.0
 no shut
end

Trivial to have all four routers up in OSPF, with all interfaces known to OSPF, i.e.:

!all
conf t
router ospf 10
 network 192.168.0.0 0.0.255.255 area 0
end

Removed OSPF and began to configure all 4 routers in iBGP.

I intentionally didn't have a full physical mesh, to see how difficult that would be to support without an underlying IGP.

I also decided to try to use loopbacks for peering, as you would with an IGP.  Unlike OSPF, don't believe BGP supports "wildcarding" its network statements to include networks, so between the network statements and peering statements, config does start to grow, e.g.:

!iosv-2
conf t
router bgp 10
 neighbor 192.168.1.1 remote-as 10
 neighbor 192.168.1.1 update-source lo0
 neighbor 192.168.4.1 remote-as 10
 neighbor 192.168.4.1 update-source lo0
 neighbor 192.168.8.1 remote-as 10
 neighbor 192.168.8.1 update-source lo0
 network 192.168.6.0
 network 192.168.3.0
 network 192.168.7.0
end

Interestingly, using loop backs, and not having a physical mesh, appears to work as well as it does for an IGP.

Where the nightmare really begins, is defining all the necessary static routes and trying to provide backup paths, via static routes, if there's a link failure.  Consider if one the four interconnecting router links fails, we should be able to maintain the iBGP logical full mesh connectivity between the routers, but I suspect it's impossible without something like SLA monitoring, and when you consider all the necessary static routes with such monitoring, an IGP is a much, much better approach!

[Richard Burts]

Following up the very nice response from Joseph about "why there's iBGP at all". I like his point that you probably do not want to inject all the EBGP routes into your IGP. I would add another aspect to that answer. The BGP advertisement carries multiple attributes which are unique to BGP. See this link for a discussion about these attributes: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

IBGP allows the EBGP routers to share these attributes with each other and to make path selection decisions based on all of the available information. If there was no IBGP then the only way that the EBGP neighbors could share information would be to redistribute their routes into the IGP and let the IGP carry the prefix to the other neighbor. But that loses the unique BGP attributes.