Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member


Can somebody tell me which one is better BGP or OSPF. We have a enterprise network using OSPF but somebody suggested to go for BGP. Wanted to take suggestions on the same.



New Member


How large is your enterprise network? BGP needs a lot of power behind it because the table are so large. You also need to be able to fulfill the requirements for BGP (Full Meshed). If you are having problems with OSPF you might want to look at what is wrong. I would stay with OSPF unless you really need BGP.


Corey Minch

All Area Networks Systems Engineer

GE Compunet

New Member


I went through this awhile back. Some really large global companies use BGP on the WAN, with OSPF, EIGRP, RIPv2 etc at the campus LAN level. I understand from what I heard that BGP does a better job of dealing with multiple paths and unequal cost load balancing. Everyone did agree, however, that BGP is good for WAN use, but not really fitted for campus use. Never really grasped why one and not the other...

Given the fact that I don't administer a global WAN with hundreds of locations (I'm involved in a national company with much fewer), and that the OSPF technical literature satisfied me that OSPF has very good scalability, and that it is "the internal routing protocol of choice", I feel comfortable with OSPF on the internal network. Also, since I haven't used BGP before, it seems difficult for me to justify learning another routing protocol (albeit a popular one) and introducing more complexity into the network.

Another idea for you is that if you are running an all Cisco router network, consider EIGRP. It is supposed to be much easier to configure, automates alot of functions that would need configuration in OSPF, and scale just about as well as OSPF.

I agree with the last response: Unless you really need alot of scalability, have a gigantic (probably global) WAN, or are somehow unhappy with what OSPF is doing for you today, I think sticking with OSPF is the way to go. Even if you are unhappy with OSPF, I'd analyze why it isn't doing what you want it to do and find out why. Even in a huge WAN, I have trouble understanding why OSPF doesn't fit.

The last idea for you is that I beleive OSPF proponents would lean toward using OSPF on any large internal network, while folks not as familiar with OSPF would lean towards BGP (internal BGP version 4 specifically) for large WAN use. I think the conversation has more to do with what you are more comfortable running and less to do with technical merits of the big protocols. As an example, I feel comfortable with OSPF, have used IGRP, RIP and some EIGRP, but never have used BGP. It seems to be a bit intimidating to me to have to go register for an AS number in order to run BGP on my internal WAN. I'm sure it's just what I grew up using, though!

New Member



I agree with your views & I am also very comfortable with OSPF but one of the consultants came & has told the management saying BGP is better than OSPF & hence the issue. Wanted to understand as to what difference would it make if I also started the process of going from OSPF to BGP & what's the amount of effort needed to do the same for a WAN of about 100 odd links.

New Member


It would be a full routing protocol migration, a very big deal. I would not want to do it, because it smacks of a political justification and not a technical one. From everything I have learned (recall that I was considering the same thing on my WAN, which is half the size of yours), it seems that BGP for WAN use would increasingly compelling as the size of the WAN increases. In other words, on smaller WANs (I'd say under 50 nodes) it doesn't make sense. On medium sized WANs (say, 50-150 nodes) a case could be made either way. On large WANs (above 150 nodes), BGP starts looking better. On huge WANs (above 500 nodes), BGP seems to be much stronger than OSPF mainly because you would probably start considering multiple Autonomous Systems.

But even then, that opinion above would be on an ideal situation where you would be able to design the network from the ground up. Even on a huge WAN, I see little benefit of migrating a stable network from one good protocol to another "peer-level" protocol. The fact is, both are suited very well on your network (and mine, and networks many times larger than both of ours). There is frankly few benefits from a technical perspective that BGP can offer that OSPF doesn't for networks our size. Secondly, whatever benefits there are appear to be so slight that they don't outweigh the risk of reconfiguring the network and disrupting something that probably works just great. Unequal cost load balancing is something that OSPF evidentally doesn't do, but there are other ways to balance traffic in OSPF.

If I were in your shoes, I would respond to the managers and the consultant who made the statement as follows. Heck, if you like it, you can use this to craft your response:

While is correct in that using BGP on the internal WAN is a popular and scalable method, OSPF is equally popular and many times more scalable than we need. Both are well suited to use on our WAN. The issue is not whether which one is "better" than the other, as both fit our needs well. Given the fact that we have used OSPF for some time, and we are familiar with it and it works well for us, the few advantages BGP *might* have over OSPF do not outweigh the risks in completely reconfiguring the WAN, disrupting the topology that is proven and stable, needlessly launching the network administration team on a learning curve to become proficient in supporting BGP and adding a new layer of complexity to our network.

One of the strongest reasons to stick with OSPF is that it is designed from the ground up to be an internal routing protocol and is perfectly suited for campus LAN as well as WAN use, whereas BGP is almost exclusively used internally on the WAN. Common thought dictates that BGP forces us to have at least two routing protocols, one for LAN and BGP for WAN. OSPF, on the other hand can be used in conjunction with another protocol, or can be used exclusively. In fact, a common strategy for large networks is to use OSPF for campus LANs, and BGP for the WAN. For these reasons, I strongly recommend that OSPF continues to be our preferred routing protocol. Further, for issues on our network that BGP may solve, I propose that we analyze them and discover the reason. The solution is most likely a configuration issue, not a routing protocol issue.



A WAN of only a hundred links should be far better off using OSPF than using BGP. You should only need BGP when the overall network is too large for a single well designed OSPF hierarchy, at which time you use BGP to allow splitting your backbone area into mutliple routing domains.

BGP is optimized for controlling routing between routing domains which do not share common metrics or otherwise cannot trust each other (think about the Internet). BGP still expects you to run OSPF or some other interior routing protocol within each routing domain, it does not replace your interior routing protocol.

Are you sure you are listening carefully? The consultant should be discussing splitting up your OSPF routing domain using BGP, not replacing OSPF with BGP. If the discussion truely is replacement, either you are using OSPF where you should not (such as through firewalls, in which case the advise could be legitimate) or the consultant is blowing smoke and you need to find a way to separate the consultant from your network before your network is destroyed.

BGP is not a substitute for proper design of an OSPF routing hierarchy. Sounds like you need a second opinion (there is way too little detail in what has been posted so far to make a rational judgment.

Good luck and have fun!

Vincent C Jones

CreatePlease to create content