skip to content

Two OSPF routers on one Ethernet segment never become neighbours; which parameters must agree, and where does OSPF check each one?

level: middleimportance: should knowfreq 38%

answer

  1. header checks, then Hello-body checks
  2. properties of the link, not the router
  3. stub flag in Options
  4. mask ignored on point-to-point
  5. MTU waits for Database Description

basics

~20 s

OSPF silently drops a Hello whose area ID, authentication, Hello or Dead interval, network mask (on broadcast and NBMA links) or stub-area E-bit disagrees with the receiving interface, so neither router even reaches Init. Interface MTU is checked later, in Database Description packets.

solid answer

~50 s

RFC 2328 checks in two places. First, every OSPF packet's header: version 2, an Area ID equal to the receiving interface's (and a source address on the interface's subnet), the same `AuType`, and authentication that verifies. Then the Hello body: `Network Mask`, `HelloInterval` and `RouterDeadInterval` must equal the interface's values, except that the mask is ignored on point-to-point links and virtual links; and the `E-bit` must match the area's external-routing capability, clear in a stub area and set otherwise. Any failure drops the packet before a neighbour entry is created, so the symptom is no neighbour at all. Router Priority and interface cost need not match, Router IDs must differ, and the interface MTU travels only in Database Description packets, so an MTU mismatch shows up later as a pair stuck in ExStart or Exchange.

go deeper

for a junior

Remember the list that must match: area, authentication, Hello and Dead intervals, the mask on a LAN, and stub-area agreement.

for a middle

Explain that mismatched Hellos are dropped silently before any neighbour entry exists, and which settings, like priority and cost, are allowed to differ.

for a senior

Use the symptom to place the fault: an empty neighbour table points at Hello checks, a stall after 2-Way points at the database exchange, usually MTU.

for a principal

Push link parameters into templates and change procedures so both ends of a link are always configured as one object, removing the half-changed-link class of outage.

## Why some parameters must agree OSPF (RFC 2328) treats several interface settings as **properties of the attached network** rather than of one router. If two routers disagree about them, they disagree about what the link is, and OSPF refuses to build a neighbour relationship on that basis. The receiving router enforces this by **silently discarding** any packet that fails the checks. Nothing is sent back, so the sender never learns why. The checks happen in two layers: the OSPF packet header, checked for every packet type, and then the body of a Hello. ## Layer 1: the packet header | Check | Rule in RFC 2328 | Result on mismatch | |---|---|---| | Version | must be 2 for OSPFv2 | packet dropped | | Area ID | must equal the receiving interface's area (a virtual link is the one exception) | packet dropped | | Source subnet | on a single-hop packet, the source must sit on the interface's subnet (not checked on point-to-point links) | packet dropped | | `AuType` | must equal the authentication type configured for the area | packet dropped | | Authentication | the configured procedure (simple password or cryptographic) must verify | packet dropped | `AuType` 0 is null authentication, 1 a simple password and 2 cryptographic authentication; RFC 5709 later added HMAC-SHA algorithms to the cryptographic type. ## Layer 2: the Hello body | Field | Rule | Exception | |---|---|---| | `Network Mask` | must equal the receiving interface's mask | ignored on point-to-point links and virtual links | | `HelloInterval` | must be identical | none | | `RouterDeadInterval` | must be identical | none | | `E-bit` in `Options` | clear if the area is a stub (no AS-external-LSAs), set otherwise | none | The E-bit check catches one router configured with the area as a stub and the other not; what a stub area changes is a matter of area design, but for adjacency the point is only that both ends must agree. ## What does not have to match - **Router Priority** — it is what the DR election compares, so it is expected to differ. Priority 0 only makes a router ineligible to become DR or BDR. - **Interface cost** — each router advertises its own outgoing cost, and the two directions of a link may legitimately differ. - **Router ID** — must be **different**: RFC 2328 says it uniquely identifies the router within the autonomous system. - **Interface MTU** — not in the Hello at all. It travels in Database Description packets. ## Reading the symptom 1. **No neighbour at all, on either side.** A header or Hello-body mismatch: the Hello is dropped before a neighbour entry is created, so neither router ever lists the other, not even in Init. 2. **One side lists the other in Init.** Hellos are getting through in only one direction, for example because of a filter or a one-way link fault. 3. **Neighbours reach 2-Way or ExStart, then stall.** The Hello checks passed; the trouble is in the database exchange, and a differing interface MTU is the classic cause. 4. **2-Way and stays there on a LAN.** Often normal: two routers that are neither DR nor BDR do not become adjacent. ## A short troubleshooting order - Confirm both interfaces are in the **same area** and the **same subnet with the same mask** on a multi-access link. - Compare **both timers** on both ends; changing one without the other is a common slip. - Compare the **authentication type and key**; a key rolled on one side only drops every packet. - Compare the **area type**: both stub or both not. - Only once neighbours appear, look at MTU and Router ID uniqueness. Because every one of these failures is a silent drop, a packet capture or the implementation's counters of discarded OSPF packets usually say more than the neighbour table, which simply stays empty.

  • Why does OSPF ignore the Hello's network mask on point-to-point links?
    A point-to-point link joins exactly two routers and has no subnet of its own in OSPF's model; RFC 2328 says the two ends' addresses are assigned independently, if they are assigned at all. There is nothing meaningful to compare, so the mask check is skipped there and on virtual links, along with the check that the source address is on the interface's subnet.
  • Do two OSPF routers need the same Router Priority to become neighbours?
    No. Router Priority is an input to the DR election, so routers on a LAN are expected to differ; the highest wins and 0 means never DR or BDR. What must differ is the Router ID, which RFC 2328 requires to be unique in the autonomous system.
  • Why is an OSPF MTU mismatch not caught by the Hello checks?
    The Hello packet has no MTU field. The interface MTU travels in Database Description packets, and a router rejects one that advertises a larger MTU than it can receive. So routers with different MTUs become neighbours normally and only stall once the database exchange begins, in ExStart or Exchange.

saying these in an interview costs you the question

  • Two OSPF routers need the same Router Priority to become neighbours.
  • An MTU mismatch stops OSPF routers from ever seeing each other's Hellos.
  • Different interface costs at the two ends block the OSPF neighbourship.
  • The Hello's network mask is compared on every link type, including point-to-point.
  • Duplicate OSPF Router IDs are harmless as long as the interface addresses differ.