3 ms·

I would suggest the author also left out the consideration of skillset. In the sort of environment described, its pretty much guaranteed you'll be already mana

I would suggest the author also left out the consideration of skillset. In the sort of environment described, its pretty much guaranteed you'll be already managing EBGP sessions to the outside world. So why not capitalise on the BGP knowledge you have and use it internally too, instead of bringing another protocol (OSPF) into the mix. Jack of all trades, master of none. As the old saying goes.

thinkingkong 6y ago
The saying is “jack of all trades is a master of none but often better than a master of one.”
windexh8er 6y ago
Most network engineers are very well versed in OSPF. Having come up through the ranks of Cisco's early NetAcad curriculum in the early 2000s, when BGP was very rarely used in internal networks, thr content was 80% focused on IGP and large L2 design and troubleshooting. It seems to me the IGP has fallen out of favor partially due to simplicity over the right tool in the right context. I'm sure, as you state, part of that has to do with the responsible engineers lacking experience and shying away. But in many cases BGP can be slower and less forgiving where a focused IGP can add value and, most importantly control. I was part of a team running a multi-state network for an ISP around a decade ago. Even then we had a lot of design and architecture reviews of spreading BGP as far and wide as possible. But the IGPs, at regional node levels (HFC type networks) always had functionality for end user provisioning that allowed us to more easily provision and troubleshoot. While I don't agree or disagree that BGP can't be the right solution what it really comes down to is understanding the use cases compared to the protocols. I find that most engineers today only loosely understand BGP and OSPF. Fully vetted network engineers seem to be fewer and further between. I moved away from that as a role years ago but my experience in large networks and understanding those protocols, although admittedly not as well as when I was studying for the CCIE labs, has been a fundamental skill I still use day in and out. And as we move more to software defined overlays I find it coming up more and more these days.
candiddevmike 6y ago
The big advantage of using OSPF over BGP is during a network outage. OSPF can have extremely fast convergence due to the authoratative/hierarchal design, where as BGP is decentralized and it takes time for network changes to propagate. Additionally, BGP is not always available on layer three switches, either due to licensing (I've seen BGP excluded from basic licenses) or just not supported by the vendor. Finally, OSPF is a lot simpler to setup and secure (everything could live in area 0 without the world ending), whereas BGP requires some decent architecture chops to make sure you don't create suboptimal routes or loops. Most places run BGP at the border (ha) and OSPF on the inside, this gives them the agility of BGP with the convergence of OSPF.

thinkingkong 6y ago

The saying is “jack of all trades is a master of none but often better than a master of one.”

windexh8er 6y ago

Most network engineers are very well versed in OSPF. Having come up through the ranks of Cisco's early NetAcad curriculum in the early 2000s, when BGP was very rarely used in internal networks, thr content was 80% focused on IGP and large L2 design and troubleshooting. It seems to me the IGP has fallen out of favor partially due to simplicity over the right tool in the right context. I'm sure, as you state, part of that has to do with the responsible engineers lacking experience and shying away. But in many cases BGP can be slower and less forgiving where a focused IGP can add value and, most importantly control. I was part of a team running a multi-state network for an ISP around a decade ago. Even then we had a lot of design and architecture reviews of spreading BGP as far and wide as possible. But the IGPs, at regional node levels (HFC type networks) always had functionality for end user provisioning that allowed us to more easily provision and troubleshoot. While I don't agree or disagree that BGP can't be the right solution what it really comes down to is understanding the use cases compared to the protocols. I find that most engineers today only loosely understand BGP and OSPF. Fully vetted network engineers seem to be fewer and further between. I moved away from that as a role years ago but my experience in large networks and understanding those protocols, although admittedly not as well as when I was studying for the CCIE labs, has been a fundamental skill I still use day in and out. And as we move more to software defined overlays I find it coming up more and more these days.

candiddevmike 6y ago

The big advantage of using OSPF over BGP is during a network outage. OSPF can have extremely fast convergence due to the authoratative/hierarchal design, where as BGP is decentralized and it takes time for network changes to propagate. Additionally, BGP is not always available on layer three switches, either due to licensing (I've seen BGP excluded from basic licenses) or just not supported by the vendor. Finally, OSPF is a lot simpler to setup and secure (everything could live in area 0 without the world ending), whereas BGP requires some decent architecture chops to make sure you don't create suboptimal routes or loops. Most places run BGP at the border (ha) and OSPF on the inside, this gives them the agility of BGP with the convergence of OSPF.