Lessons (8, study in order)

Lesson 1 · Why link-state protocols beat distance-vector

Beginner · about 10 min

Goal: First get OSPF's design philosophy straight - every other mechanism follows from it.

The trouble with distance-vector

Distance-vector protocols like RIP work like this: a neighbor tells me "reaching X takes me 3 hops", so I record "reaching X takes 4 hops, next hop is that neighbor."

The problem is that I only get someone else's computed result - I never see the raw topology. That causes two consequences:
· If a neighbor's math is wrong, mine ends up wrong too, and loops form easily (which is why you need a pile of patches on patches: split horizon, poison reverse, hold-down timers).
· Slow convergence: bad news has to propagate hop by hop, and you have to wait out timers on top of that.

The link-state approach: flood the raw material, everyone computes their own

OSPF does the opposite: it only floods raw link information (LSAs), and never passes along its own computed result.

Every device assembles the LSAs it receives into a complete Link State Database (LSDB), then runs Dijkstra rooted at itself to compute shortest paths.

As a result:
· Every device is looking at the same complete graph, so loops naturally can't form (as long as the LSDB is consistent).
· Convergence is fast: an LSA gets flooded out and everyone recomputes on their own, with no hop-by-hop relay needed.
· The cost is more memory and CPU - which is exactly why areas exist.

Every OSPF mechanism follows from this

Follow the single thread "everyone must see the same graph" and the rest of OSPF's design falls out on its own:

· Keeping the LSDB consistent → needs a strict synchronization mechanism (four packet types: DD / LSR / LSU / LSAck)
· Knowing who to synchronize with → needs neighbor discovery and a neighbor state machine (Hello)
· Pairwise synchronization on a broadcast network is too wasteful → elect a DR to act as a relay
· An LSDB that's too big is unmanageable → carve out areas to limit flooding scope
· Routes need to cross areas without the topology crossing with them → Type3 summaries (which is why inter-area routing is vector-style)

Remember this one thread and you'll never have to memorize OSPF by rote.

Hands-on: watch an SPF run

Load "Single area, four devices", go to the ④ SPF Computation page, pick R1 as the root, and press play.
Notice that R1→R3's cost is only 5 and R1→R2's is 10, yet the final path to R4 goes through R2 - because 10+10 < 5+30. Greedily picking the cheapest first hop gets it wrong.

Key takeaways

• A link-state protocol only floods raw LSAs, never its own computed result
• Every device independently runs Dijkstra rooted at itself
• The LSDB must be identical across the whole area, or loops can form
• The whole point of areas is to limit flooding scope and control LSDB size

Lesson 2 · Neighbor and adjacency are not the same thing

Beginner · about 12 min

Goal: Tell 2-Way apart from Full - that's a prerequisite for reading a neighbor table.

Two concepts

· Neighbor relationship (reaching 2-Way): both sides' Hello packets list each other - they've recognized one another.
· Adjacency (reaching Full): the LSDB is fully synchronized, and only then does this link get counted into the SPF calculation.

Only links at Full show up in a Router LSA. So don't panic at the sight of 2-Way - first check whether it's "by design".

The seven-step state machine

Down → Init → 2-Way → ExStart → Exchange → Loading → Full

· Init: received the peer's Hello, but it doesn't list my Router-ID - the peer hasn't acknowledged me yet.
· 2-Way: both sides' Hellos list each other. The neighbor relationship is established.
· ExStart: negotiate master/slave (the larger Router-ID becomes Master) and the DD sequence number.
· Exchange: exchange DD packets to compare LSDB summaries.
· Loading: use LSR to request what's missing, the peer replies with LSU, and an LSAck is sent back.
· Full: synchronization complete.

On a broadcast network, DROthers stop at 2-Way with each other

This is by design, not a fault.

On a broadcast network, if n devices formed adjacencies pairwise you'd need n(n-1)/2 adjacencies, and the same LSA would get flooded over and over.
So OSPF elects a DR to act as a relay: every device only forms an adjacency with the DR and BDR (n-1 of them), and DROther-to-DROther pairs stop at 2-Way.

Hands-on: load "Broadcast segment DR election", go to the ② Topology & Neighbors page, and look at the neighbor table - you'll see a few pairs sitting at 2-Way, labeled "by design".

Key takeaways

• Neighbor = 2-Way, adjacency = Full
• Only links at Full get counted into the SPF calculation
• DROther-to-DROther pairs on a broadcast network stopping at 2-Way is normal
• The DR's job is to shrink n(n-1)/2 adjacencies down to n-1

Lesson 3 · How to troubleshoot a neighbor that won't come up

Troubleshooting · about 16 min

Goal: Two dividing lines locate every neighbor failure.

Remember two dividing lines first

① Stuck at Init → almost certainly a mismatched Hello parameter, with the peer simply discarding my Hello outright.
A Hello carries these fields, and any single mismatch breaks it:
· Hello interval / Dead interval
· Area number (an interface-level attribute!)
· Authentication method and key
· Mask (checked on broadcast networks, not on P2P)
· The Stub flag, E-bit

② Reaching 2-Way or ExStart but never Full → the Hello parameters are fine, and the problem is in the DD phase:
· Mismatched MTU (a Hello doesn't carry MTU, only DD does - which is why it can still reach 2-Way)
· A Router-ID conflict

Why the Hello interval so often ends up mismatched

The most common cause isn't someone manually changing the interval - it's the two ends being configured with different network types:
· Broadcast / P2P: Hello 10 seconds, Dead 40 seconds
· NBMA / P2MP: Hello 30 seconds, Dead 120 seconds

So if one end is set to broadcast and the other to nbma, the intervals automatically end up mismatched. Whenever you check the Hello interval, glance at the network type too.

Hands-on: four links, four faults

Load the "Fault diagnosis" scenario - R1 connects to four devices, and each link has a different classic fault buried in it.
Go to the ② Topology & Neighbors page, click through each one to see the state and diagnosis, then fix them yourself:
① mismatched Hello interval ② mismatched area number ③ mismatched MTU ④ authentication mismatch

While fixing them, notice which of the first three get stuck at Init and which one gets stuck at ExStart.

Real-device troubleshooting commands

display ospf peer brief        # check state first
display ospf interface         # area/cost/Hello/DR at a glance
display ospf error             # counters for parameter mismatches, a troubleshooting lifesaver
display ospf lsdb               # is the LSDB in sync

display ospf error will directly report counters like "Hello interval mismatch", far faster than diffing configs one by one.

Key takeaways

• Stuck at Init = mismatched Hello parameter (interval/area/authentication/mask/E-bit)
• Reaching 2-Way but never Full = mismatched MTU or a Router-ID conflict
• A mismatched Hello interval is often just a side effect of mismatched network types
• display ospf error tells you directly which parameter is mismatched

Lesson 4 · DR/BDR election

Beginner · about 10 min

Goal: Two rules plus two traps.

Only two election rules

① The interface with the higher priority wins; priority 0 means opting out of the election entirely.
② If priorities are tied, compare Router-ID; the larger one wins.

First place becomes DR, second place becomes BDR, everyone else is a DROther.
Note that priority is set at the interface level (ospf dr-priority), not at the device level.

Trap one: no preemption

A newly added device won't knock the current DR off its perch, even if its priority is higher.

Why design it this way? Because a DR change means rebuilding every adjacency and re-synchronizing the LSDB - an expensive operation. OSPF would rather stay stable than chase "optimal".

The consequence: after priorities are planned out on a live network, if a device added later is supposed to become the DR, you must restart the OSPF process (reset ospf process) for that to take effect. This is also why "the config looks right but the DR isn't the device I wanted" happens.

Trap two: only broadcast and NBMA elect one at all

P2P and P2MP don't elect a DR/BDR and don't generate a Type2 Network LSA either.
The logic is simple: with only two devices, electing a DR can't reduce the number of adjacencies at all.

So a common real-world optimization: manually set an Ethernet link with only two devices to P2P type, which skips the DR election, drops one Type2 LSA, and converges faster too.

Hands-on: watch the election happen

Load "Broadcast segment DR election": four devices on the same Ethernet segment, R1 has priority 1, R2 and R3 both have 100, and R4 has 0.
Go to the ② Topology & Neighbors page and click that segment to see the election result and the reason for each device's role - R2/R3 get split by Router-ID since their priority ties, and R4 opts out entirely because its priority is 0.

Key takeaways

• Higher priority wins first (0 means opting out), tied priorities are broken by the larger Router-ID
• No preemption: a newly added device with a higher priority doesn't bump the current DR
• Only broadcast and NBMA elect a DR; P2P doesn't elect one or generate a Type2
• It's recommended to manually set a two-device Ethernet link to P2P type

Lesson 5 · Seven LSA types and their flooding scope

Advanced · about 18 min

Goal: Remembering LSAs only takes remembering "who generates it and how far it goes".

One table settles it

| Type | Who generates it | Flooding scope | Contents |
|---|---|---|---|
| Type1 Router | Every router | This area | Its own links and cost |
| Type2 Network | DR only | This area | Which routers are on this broadcast segment |
| Type3 Summary | ABR | Across areas | Another area's prefix + cost |
| Type4 ASBR Summary | ABR | Across areas | How to reach that ASBR |
| Type5 AS External | ASBR | Whole AS (except Stub) | Imported external routes |
| Type7 NSSA External | The NSSA's ASBR | This NSSA area | Converted to Type5 at the ABR |

Type1 + Type2 are the raw material for SPF; every other type carries only a prefix and a cost, never any topology.

Why there's no SPF across areas

Because a Type3 carries only a prefix and a cost, no topology.

So inter-area routing is fundamentally vector-style: "the ABR tells me reaching X costs 20, and reaching the ABR costs me 10, so reaching X costs me 30". Same idea as RIP.

Corollary 1: inter-area routes can never be more trustworthy than intra-area routes - this is where the route-preference order "intra-area > inter-area" comes from.
Corollary 2: since it's vector-style, loops are possible, hence a hard rule - an ABR only accepts Type3s coming from the backbone area, area 0.
One more corollary: every non-backbone area must connect directly to area 0, or its routes can never make it out. If that's truly impossible, a virtual link can be used to reach through another area back to the backbone.

Why Type4 exists

The next hop written into a Type5 is the ASBR's Router-ID, not a routable address.
A device in another area receiving that Type5 knows "172.16.1.0/24 is behind ASBR 5.5.5.5", but has no idea how to reach 5.5.5.5.

So the ABR generates an extra Type4 stating "to reach 5.5.5.5, go through me, at cost X."
Conclusion: Type4 is only needed when the ASBR isn't in your own area. Within the same area, SPF can compute it directly.

Hands-on: watch the flooding scope

Load "Multi-area + ABR + ASBR", go to the ③ LSDB page:
① Look by area, and notice Type1/Type2 only ever appear within their own area;
② See which ABR generated a given Type3/Type4 and which area it got injected into;
③ Switch to the Stub scenario and watch Type5 get blocked at the door, replaced by a single default route.

Key takeaways

• Type1/2 are the raw material for SPF and only flood within their own area
• Type3/4 are generated by the ABR, carrying only prefix and cost, which is why inter-area routing is vector-style
• ABRs only accept area 0's Type3 → every non-backbone area must connect directly to the backbone
• Type4 is only needed when the ASBR is in a different area

Lesson 6 · How SPF actually computes

Advanced · about 14 min

Goal: Understand the candidate list and the shortest-path tree, and clear up cost along the way.

Five steps to the algorithm

① Put yourself into the shortest-path tree (SPT) at cost 0.
② Put your directly connected neighbors into the candidate list, at cost = the outgoing interface's cost.
③ Pick the entry in the candidate list with the smallest cumulative cost and move it into the SPT.
④ Use it to relax the candidate list: whenever a shorter path is found, lower that entry's cost.
⑤ Repeat ③④ until the candidate list is empty.

Handling ties in cost: routers are picked before other nodes, then sorted by ID - the point is to make every device across the network compute an identical result; otherwise loops could form.

The intuition mistake almost everyone makes

A cheap first hop does not mean a cheap whole path.

In the single-area scenario: R1→R3 costs 5, R1→R2 costs 10. Judging by the first hop alone, R3 looks like the way to go.
But R3→R4 costs 30, while R2→R4 only costs 10. So the shortest path to R4 is R1→R2→R4 (20), not R1→R3→R4 (35).

Dijkstra exists precisely to solve this - it advances by cumulative cost, not by next hop.

How cost gets computed

Huawei's default is cost = reference bandwidth / interface bandwidth, with a default reference bandwidth of 100 Mbps and a minimum value of 1.

Here's the catch: a gigabit interface computes 100/1000 < 1 → rounds up to 1; a 10-gigabit interface also gets 1. Gigabit and 10-gigabit end up indistinguishable.

So there's one thing every real network must do: raise the reference bandwidth (bandwidth-reference 100000).
⚠️ It must be changed to the same value across the whole network, or devices will compute inconsistent costs and routing will get messy.

Also, cost is interface-level and one-directional: A→B and B→A can differ, which can cause traffic to take different paths in each direction - check both ends' cost first when troubleshooting asymmetric routing.

Key takeaways

• Dijkstra advances by cumulative cost, not by first hop
• Ties in cost are broken by a fixed rule, keeping the result identical across the whole network
• cost = reference bandwidth / interface bandwidth; the default reference bandwidth of 100M makes gigabit and 10-gigabit indistinguishable
• Changing the reference bandwidth must be consistent network-wide; cost is one-directional

Lesson 7 · The routing table: four route types and their preference

Advanced · about 12 min

Goal: Understand who wins when several routes exist for the same prefix.

Four types, a hard-coded preference order

Intra-area (O) > Inter-area (O IA) > External Type1 (O E1) > External Type2 (O E2)

Note this order is absolute: an intra-area route with cost 100 beats an inter-area route with cost 2.
Compare type first; only compare cost once types are equal.

The reasoning was covered in Lesson 5: an intra-area route is computed yourself from the full topology, while an inter-area route is just a cost someone else told you - their trustworthiness is fundamentally different.

External Type1 vs Type2

· Type2 is the default at import time: route cost = only the external cost, with no internal cost added.
The upside is simplicity and stability; the downside is that with multiple ASBRs, you can't tell which is actually closer, and traffic might take a longer route.
· Type1: cost = internal cost + external cost, which does reflect differences in internal paths.
Writing type 1 at import time changes it.

When both Type1 and Type2 exist for the same prefix, Type1 wins.

Hands-on: compare them side by side

Load "Multi-area + ABR + ASBR", go to the ② Topology & Neighbors page, click different devices, and expand "OSPF Routing Table" in the detail panel on the right:
① Find which routes are O / O IA / O E1 / O E2;
② Expand a route to see "how it was computed", especially the cost accumulation for inter-area routes;
③ Find a route that got beaten out and see whether it lost on type or on cost.

R5 imports two external routes, one Type2 and one Type1, giving you a direct comparison.

Key takeaways

• Intra-area > inter-area > external Type1 > external Type2; compare type first, then cost
• Type2 only looks at the external cost, Type1 adds the internal cost
• For the same prefix, Type1 wins over Type2

Lesson 8 · Special areas: Stub and NSSA

Advanced · about 12 min

Goal: Trade area type for LSDB size.

Why special areas exist at all

A Type5 is flooded across the whole AS. If tens of thousands of external routes get imported, every device network-wide (including small branch-site devices) has to store all those LSAs and rerun SPF on every change.

But a branch site doesn't actually need to know the details - it has only one exit, so a single default route is enough.
That's the entire point of special areas: trade "knowing less" for "using fewer resources".

What the three types block

| Type | Blocks | What the ABR fills in |
|---|---|---|
| Stub | Type4 / Type5 | One Type3 default route |
| Totally Stub (stub no-summary) | Type3 / Type4 / Type5 | One Type3 default route |
| NSSA | Type4 / Type5, but allows Type7 | An optional default route |

What NSSA is for: wanting to keep out external routes from elsewhere, while still letting this area itself import external routes. An ASBR in this area generates a Type7, which gets converted into Type5 at the ABR before flooding to other areas.

Restrictions on a Stub area (a favorite exam question)

· Can't be the backbone area, area 0 (the backbone has to forward every route)
· The area can't contain an ASBR (since Type5 is blocked, an imported route couldn't get out anyway) - this is exactly the reason NSSA exists
· Can't have a virtual link passing through it
· Every router in the area must be configured as Stub: a mismatched E-bit in Hello will prevent the neighbor from coming up, and missing it on just one device breaks everything

Hands-on: watch Type5 get blocked

Load "Stub area" (area 1 is Stub), go to the ③ LSDB page and look at R3 (which is in area 1):
① Its LSDB has no Type5 at all;
② It has one extra Type3 default route, 0.0.0.0/0, pushed down by the ABR;
③ Then go to the ② Topology & Neighbors page, click R3, and expand "OSPF Routing Table" to confirm it has no O E1/O E2 routes, only the one default route.

Key takeaways

• Special areas trade "knowing less" for "using fewer resources"
• Stub blocks Type4/5, Totally Stub also blocks Type3, NSSA blocks 4/5 but allows Type7
• A Stub area can't be area 0, can't contain an ASBR, and can't have a virtual link through it
• Every router in the area must be configured as Stub, or missing it on one breaks the whole area