Salman left an interesting comment on my Running BGP on Servers blog post:
My prior counterparts thought running OSPF on Mainframes was a good idea. Then we had a routing blackhole due to misconfiguration on the server. Twice! The main issue was the Mainframe admins lack of networking/OSPF knowledge.
Well, there’s a reason OSPF is called Interior Routing Protocol.
Honestly, mainframe administrators have no other options: IBM in their infinite wisdom implemented only RIP and OSPF, and OSPF seems to be the lesser evil.
However, even some networking engineers didn’t get the memo. Long time ago I encountered a service provider who ran OSPF with their customers, and all customers happily shared area 0 with the provider… until a customer accidentally managed to create an intra-area default route (don’t ask me how), which was preferred over provider’s external default route. And so an early attempt at plug-and-pray networking (because it’s oh-so-much-easier to run OSPF with your customers than to configure static routes) failed miserably.
30K Foot View
Ignoring the technicalities, the main difference between OSPF (which I would never run on a host) and BGP (which I’d recommended in some cases) is the intended use:
- OSPF is an Interior Routing Protocol designed to exchange information within an autonomous system.
- BGP is an Exterior Routing Protocol with enough safeguards to be used between autonomous systems.
You might claim that the mainframe Salman mentioned belongs to the same autonomous system as the data center switches. However, even the early definitions of AS (going all the way back to RFC 1654) don’t talk about physical proximity:
The classic definition of an Autonomous System is a set of routers under a single technical administration…
Obviously the mainframe team and the networking team weren’t a single technical administration.
The intended use cases heavily influenced the design and behavior of OSPF (or IS-IS) and BGP:
- BGP uses a pretty conservative approach to information propagation: receive -> filter -> evaluate -> filter -> propagate best information.
- OSPF is focused on speed-of-convergence and uses a radically different approach: receive -> flood everything -> evaluate.
In other words, anyone who’s part of an OSPF domain can insert any stupidity they wish into the domain and there’s nothing anyone else can do to stop the propagation of that stupidity within an area, and it stays in the area for at least half an hour. There are (as expected) vendor-specific kludges one can use between areas, but within area flooding rules (and external routes get flooded across area boundaries unless you use NSSA areas).
As I wrote 2.5 years ago: Don’t ever run OSPF with a third party, even if that third party happens to be your friendly server administrator. It’s not that you wouldn’t trust him, it’s just that you don’t need so many additional sources of semi-reliable information plugged straight into the heart of your network.
Finally, to learn more about running BGP between servers and ToR switches, register for the upcoming Leaf-and-Spine Fabric Designs live webinar in which I’ll cover the various design scenarios and Dinesh Dutt will talk about implementation details and real-life deployments.