Re: Practical OSPF - Free Training Series

eddie.harmoush · ‎08-17-2022

Hey all,

Lately I've been working on a modern, practical training series covering OSPF. I wanted to share the videos with this community.

In the future, I'd like to also add videos covering:

Authentication
Passive Interfaces
MTU Issues
OSPF Route summarization
OSPF Route filtering
OSPF Route filtering into the routing table
Multiple ABR, considerations
Multiple ASBR, considerations

Beyond these, what other OSPF videos would you say are important to having a modern, practical understanding of OSPF in 2022?

Joseph W. Doherty · ‎08-18-2022

Just took a very quick glance at the beginning two of your videos, numbers seven and eight.

What I immediately noticed was description of OSPF's interface cost metric being "delay". Don't recall Cisco, or the OSPF RFC, using that term.

Further, I suspect your video shows how (Cisco's) OSPF is calculated based on interface bandwidth, which Cisco does. Having not viewed the whole video, I wonder if you make it clear that such a calculation is something Cisco has done beyond OSPF RFC, which, I recall, considers the cost metric "dimensionless".

Again, not having viewed any of your videos in full (i.e. following might already have been covered), I would suggest you make clear what Cisco's has done, that's not really part of the OSPF RFC, as, from personal experience, when you work with other vendor's OSPF implementations, especially for the first time, you suspect their OSPF implementation is faulty. Or, possibly when making clear OSPF cost might be used in ways beyond its Cisco default being calculated from interface bandwidth. (Examples of the latter might include, setting OSPF cost to reflect a path's CIR or bottleneck, or reflecting $ cost using one path vs. another, or making clear each side of a OSPF "link" need not use the same cost, etc.)

That said, I very much applaud your effort, especially sharing with the whole community. Hopefully, my or others critiques might further improve what you've done.

eddie.harmoush · ‎08-18-2022

Hi Joseph, thanks for the insight.

I understand what you are saying about the RFC stating "cost of a route is described by a single dimensionless metric". You're right, that it might have been worth a quick call out in the video (but alas it's already live).

In practice, the three major vendors I've worked with (Cisco, Juniper, Arista) all calculate the cost using the same formula. Given that, since my focus for the series was intended to be practical, I didn't want to get too lost with the minutia of the RFC.

But what do I know, maybe it isn't minutia -- we all have our blind spots =). Can you list other vendors which don't conform to the common "Reference Bandwidth / Link Bandwidth" formula? I'd be curious to hear what other mechanisms exist for path costs.

The practice of setting custom costs to reflect non bandwidth-related values is independent from how the OSPF cost are calculated without manual intervention. That can be touched on in later videos, or even inferred from engineers as they are working through various topologies.

Beyond that, the term "delay" is used in EIGRP to identify an additive value based upon link speed along the path to a target network. Since my strategy to describing OSPF's past cost went via RIP, then EIGRP, then to OSPF, I thought the term "delay" was appropriate -- despite it not being strictly mentioned in the OSPF RFC (perhaps because an actual cost formula is not explicitly defined in the RFC)

Either way, I appreciate your feedback and would welcome any further thoughts you have =). Cheers, Joseph.

Joseph W. Doherty · ‎08-18-2022

"In practice, the three major vendors I've worked with (Cisco, Juniper, Arista) all calculate the cost using the same formula."

Same formula, yes, but I recall they use different default reference bandwidths from Cisco's.

"Can you list other vendors which don't conform to the common "Reference Bandwidth / Link Bandwidth" formula?"

It was (many) years ago, but worked in a shop with Cisco and Cabletron/Enterasys equipment. The latter didn't auto calculate OSPF costs, you had to apply a cost statement to interface if you wanted a cost other than "1". (Don't quote me, but when I got my various Brocade certifications, I recall [?], at that time, their OSPF implementation didn't auto calculate OSPF cost either.)

"Beyond that, the term "delay" is used in EIGRP to identify an additive value based upon link speed along the path to a target network."

Laugh - I did wonder whether your were using "delay" from EIGRP, but even in the context of EIGRP's composite metric, which comprises several variables, "delay", represents path latency, in microseconds. EIGRP also incorporates "bandwidth" in its composite metric too. Of these two, less "delay" is "better" while more "bandwidth" is better, in the metric computation. So, personally, I think using "delay" sort of muddies the issue of OSPF calculating its cost using interface bandwidth, especially as, like EIGRP, more "bandwidth" is better for OSPF's path preference.

BTW, as an aside, I was surprised the day I leaned that OSPF's interface cost, by RFC, was not derived from the interface's bandwidth, as Cisco's approach seemed so intuitive.

Also BTW, possibly beyond practical, but for a suggestion for another possible subject training area, you might get into "things" Cisco's does in their OSPF implementation that are either not defined in the OSPF RFC to be provided, some "visible" (e.g. Cisco's cost calculation), some "invisible" (e.g. SPF throttling and LSA hold timers); or "things" defined in RFC, but exactly how they are to be done not defined (e.g. LSA pacing). These Cisco "things", are often why Cisco's OSPF works "better" than many other vendors' OSPF implementations.

eddie.harmoush · ‎08-21-2022

Hi again Joseph,

>> [In EIGRP] "delay", represents path latency, in microseconds

It was intended to, yes. That is what the RFC states. But in practice, Cisco uses an absolute value for delay based upon link speed for each link in the path. Regardless of the actual measured latency on the link or path.

So again, this is an intentional obfuscation to keep the series anchored to practical OSPF knowledge.

The EIGRP "bandwidth" measurement is the minimum bandwidth across the entire path -- so doesn't quite line up with OSPFs metric. Hence, I thought "delay" was a better word to use when discussing OSPF.

Either way, at the end of the day it's just words and semantics. As long as the actual knowledge of how the metric is determined is communicated in the video, that is what I care for.

Honestly, a lot of terminology is shop/team specific.... For instance, I worked for one team that insisted on the term "failure domain", and another team that insisted on the term "blast radius" ... in the end, both terms meant the same thing.

Joseph W. Doherty · ‎08-21-2022

"Honestly, a lot of terminology is shop/team specific.... For instance, I worked for one team that insisted on the term "failure domain", and another team that insisted on the term "blast radius" ... in the end, both terms meant the same thing."

Laugh, and let's not get started on terminology differences between vendors. . .

eddie.harmoush · ‎08-21-2022

@Joseph W. Doherty wrote:
Laugh, and let's not get started on terminology differences between vendors. . .

Oh boy! Yes, agreed let's avoid that conversation =).