Skip to content
Log in Sign up My account

1.10.b Neighbor Relationships and Authentication

Blueprint 1.10.b: Troubleshoot OSPF (v2/v3): Neighbor relationship and authentication

  • The neighbor state machine and what it means when a neighbor is stuck in each state
  • The parameters that must match before two routers become neighbors, and how each mismatch shows itself
  • OSPFv2 authentication: null, plain text, MD5 and HMAC-SHA with key chains, at interface and area level
  • Key rollover and the virtual link authentication trap
  • OSPFv3 authentication with IPsec and with the authentication trailer

Most OSPF trouble tickets end at a missing or stuck neighbor. The skill the exam tests is reading the state a neighbor is stuck in, knowing which checks happen before and after that state, and then proving the cause with one or two show or debug commands.

The neighbor state machine

graph LR
  D["Down"] -->|"hello received"| I["Init"]
  D -.->|"NBMA: unicast hello sent"| AT["Attempt"]
  AT --> I
  I -->|"own RID seen in neighbor hello"| W["2-Way"]
  W -->|"DR or BDR involved, or P2P"| XS["ExStart"]
  XS -->|"master and slave agreed"| X["Exchange"]
  X -->|"DBDs compared"| L["Loading"]
  L -->|"all LSRs answered"| F["Full"]
State What is happening Stuck here usually means
Down No hello received from this neighbor within the dead interval Link down, hellos filtered, neighbor not running OSPF on that interface, wrong area or mismatched hello parameters (the hello is discarded, so the neighbor never appears)
Attempt NBMA only: a unicast hello was sent to a configured neighbor, nothing came back Wrong neighbor address, no reachability, the other end not configured as non-broadcast
Init A hello arrived, but it does not list this router's RID One-way communication: an ACL or a switch drops hellos in one direction, or one side sends unicast and the other multicast
2-Way Bidirectional hellos; the DR/BDR election happens here Normal between two DROTHERs on a multiaccess segment. Abnormal if every router has priority 0, because no DR exists to form adjacencies with
ExStart Master/slave negotiation; the higher RID becomes master MTU mismatch, or a duplicate router ID
Exchange Database description (DBD) packets list the LSAs each side holds MTU mismatch (the side with the smaller MTU drops the larger DBDs)
Loading Link-state requests (LSR) are sent for missing LSAs and answered with updates (LSU) Rare. Corrupted or oversize LSUs, often again an MTU problem on the path
Full Databases synchronized Healthy. Routes can still be missing for non-adjacency reasons

Exam trap

2WAY/DROTHER between two DROTHER routers on an Ethernet segment is correct behavior, not a fault. DROTHERs only become FULL with the DR and BDR. If an exhibit shows four routers on a switch and two of them in 2WAY with each other, look elsewhere for the problem.

What must match

OSPF checks some parameters when a hello arrives and others later. Knowing which check happens where tells you which state the neighbor is stuck in.

Parameter Checked in Mismatch symptom
Area ID Hello No neighbor. Log %OSPF-4-ERRRCV ... mismatched area ID
Hello and dead intervals Hello No neighbor. Debug: Mismatched hello parameters with Dead R x C y, Hello R x C y
Subnet and mask (OSPFv2, not on point-to-point) Hello No neighbor. Same debug, Mask R ... C ...
Authentication type and key Every packet No neighbor. Debug: Mismatched Authentication type or Mismatched Authentication Key
Stub area flag (E bit) and NSSA flag (N bit) Hello No neighbor. Debug: mismatched Stub/Transit area option bit
OSPFv3 instance ID Hello No neighbor, nothing logged
Router ID unique Hello and LSAs %OSPF-4-DUP_RTRID_NBR when the duplicate is a direct neighbor; flapping or missing routes when it is elsewhere
Interface MTU DBD Stuck in EXSTART or EXCHANGE, eventually drops and restarts
Network type compatible LSAs and SPF, not the hello Neighbor may reach FULL, but routes across the link are missing (see network types)

The process ID does not need to match. It is locally significant. The router ID must be unique, not matching. Interface cost, reference bandwidth and priority do not need to match either.

Some reasons for a missing neighbor have nothing to do with parameters:

  • The interface is passive-interface, so no hellos are sent or processed on it. The connected network is still advertised.
  • The interface is not in OSPF at all, because a network statement has the wrong wildcard or an interface command is missing.
  • An inbound ACL or CoPP policy drops IP protocol 89. OSPF is not TCP or UDP, so an ACL that permits "OSPF port 89" never matches.
  • The addresses on the link are secondary addresses. OSPFv2 only forms adjacencies on the primary subnet.

Diagnostic output

Representative log and debug lines follow. Exact wording varies a little between releases, but the key phrases are stable and are what you should look for.

R1# debug ip ospf hello
OSPF-1 HELLO Gi0/1: Rcv hello from 10.255.255.2 area 0 10.1.12.2
OSPF-1 HELLO Gi0/1: Mismatched hello parameters from 10.1.12.2
OSPF-1 HELLO Gi0/1: Dead R 120 C 40, Hello R 30 C 10

R1# debug ip ospf adj
OSPF-1 ADJ   Gi0/1: Rcv pkt from 10.1.12.2 : Mismatched Authentication type. Input packet specified type 0, we use type 2
OSPF-1 ADJ   Gi0/1: Rcv pkt from 10.1.12.2 : Mismatched Authentication Key - Message Digest Key 1
OSPF-1 ADJ   Gi0/1: Nbr 10.255.255.2 has larger interface MTU

%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 10.255.255.1 from 10.1.12.2 on interface GigabitEthernet0/1
%OSPF-4-ERRRCV: Received invalid packet: mismatched area ID from backbone area from 10.1.12.2, GigabitEthernet0/1

In R x C y, R is the value received from the neighbor and C is the value configured locally. Authentication type 0 is null, type 1 is plain text and type 2 is cryptographic (MD5 or HMAC-SHA).

show ip ospf interface is the single most useful command because it shows almost every local parameter at once:

R1# show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.1.12.1/30, Interface ID 3, Area 0
  Attached via Interface Enable
  Process ID 1, Router ID 10.255.255.1, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:04
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1

Neighbor count 0 with a healthy-looking interface means hellos from the other side are not accepted. Compare this output line by line with the neighbor's. show ip ospf interface brief gives the one-line summary (area, cost, state, neighbor count) for every OSPF interface. show ip ospf traffic shows packet counters including discards, which helps when debugs are not allowed.

Exam trap

A neighbor stuck in EXSTART is an MTU problem far more often than anything else. The two classic fixes are to match the MTU (ip mtu or mtu on both ends) or, as a workaround, ip ospf mtu-ignore on the side that rejects the DBDs. On the exam, matching the MTU is the better answer unless the question says the MTU cannot be changed.

Troubleshooting flow

graph TB
  A["Neighbor not FULL"] --> B{"In show ip ospf neighbor?"}
  B -->|"No"| C{"Interface in OSPF and not passive?"}
  C -->|"No"| C1["Fix network statement, interface command or passive-interface"]
  C -->|"Yes"| E["debug ip ospf hello and adj: area, timers, mask, auth, stub flag"]
  E --> E1["No debug output at all: check ACL, CoPP, L2 path"]
  B -->|"Yes"| G{"Which state?"}
  G -->|"INIT"| G1["One-way: ACL or L2 drops in one direction"]
  G -->|"2WAY"| G2["Normal for DROTHERs; check priorities if no DR"]
  G -->|"EXSTART or EXCHANGE"| G3["MTU, duplicate RID"]
  G -->|"FULL but routes missing"| G4["Network type, LSDB, filtering: see other pages"]

OSPFv2 authentication

Types

Type Name Config to enable Key config
0 Null Default, or ip ospf authentication null to override an area setting None
1 Plain text ip ospf authentication or area N authentication ip ospf authentication-key <key> (up to 8 characters)
2 MD5 ip ospf authentication message-digest or area N authentication message-digest ip ospf message-digest-key <id> md5 <key>
2 HMAC-SHA (RFC 5709) ip ospf authentication key-chain <name> Key chain with cryptographic-algorithm hmac-sha-256 (or another SHA variant)

Authentication can be enabled at area level (under router ospf, for every interface in that area) or per interface. The interface command overrides the area command. The keys are always per interface (or in a key chain referenced by the interface). Mixing the two methods across a link is fine as long as the resulting type and key are the same on both ends.

MD5

interface GigabitEthernet0/1
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 Ospf-Key-1

router ospf 1
 area 0 authentication message-digest
!
interface GigabitEthernet0/1
 ip ospf message-digest-key 1 md5 Ospf-Key-1

Both ends need the same key ID and the same key string. The key ID is carried in the packet, so key 1 on one side and key 2 on the other fail even if the strings are identical. Key strings are case sensitive. If service password-encryption is on, the running config shows the key as type 7, so you cannot compare keys by reading show run. Re-enter the key on both sides if in doubt.

MD5 key rollover. To change keys without an outage, add the new key with a higher ID on every router. While any neighbor still uses an older key, the router sends each OSPF packet once per key. When all neighbors use the youngest key, it stops sending the old one, and you can remove it.

R1# show ip ospf interface GigabitEthernet0/1 | begin authentication
  Message digest authentication enabled
    Youngest key id is 2
    Rollover in progress, 1 neighbor(s) using the old key(s):
      key id 1

HMAC-SHA with a key chain

key chain OSPF-SHA
 key 10
  key-string Sha-Key-10
  cryptographic-algorithm hmac-sha-256
!
interface GigabitEthernet0/1
 ip ospf authentication key-chain OSPF-SHA

The key ID, key string and algorithm must match on both ends. A key with a string but no cryptographic-algorithm is not valid for OSPF. If you use send-lifetime and accept-lifetime on the keys, the routers' clocks matter: a router with a wrong clock may consider no key valid. Use NTP and check show key chain, which marks each key as valid or not at the current time.

R1# show key chain OSPF-SHA
Key-chain OSPF-SHA:
    key 10 -- text "Sha-Key-10"
        cryptographic-algorithm: hmac-sha-256
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]

show ip ospf interface then reports cryptographic authentication with the key chain name instead of Message digest authentication enabled.

Exam trap

A virtual link is an area 0 interface. If area 0 authentication message-digest is configured, the virtual link also expects MD5, and it goes down unless you give it a key: area 1 virtual-link 10.255.255.3 message-digest-key 1 md5 Ospf-Key-1 on both ends. Questions often show a virtual link that failed right after someone "secured area 0".

Plain text

interface GigabitEthernet0/1
 ip ospf authentication
 ip ospf authentication-key Cisco123

Plain text sends the key in the clear and is only there for legacy interoperability. The key is truncated to 8 characters, so Cisco1234 and Cisco123 are the same key, a detail that makes a nice trick question.

OSPFv3 authentication

OSPFv3 has no authentication fields in its header. IOS XE offers two methods.

IPsec (AH or ESP)

OSPFv3 relies on IPv6 IPsec. You configure a security parameter index (SPI) and a hex key. AH-style authentication uses authentication, ESP with optional encryption uses encryption. The SPI and keys must match on every router on the link, and the image must include IPsec crypto.

interface GigabitEthernet0/1
 ospfv3 authentication ipsec spi 500 sha1 1234567890ABCDEF1234567890ABCDEF12345678

router ospfv3 1
 area 0 authentication ipsec spi 600 sha1 1234567890ABCDEF1234567890ABCDEF12345678

interface GigabitEthernet0/1
 ospfv3 encryption ipsec spi 1001 esp aes-cbc 128 0123456789ABCDEF0123456789ABCDEF sha1 1234567890ABCDEF1234567890ABCDEF12345678

interface GigabitEthernet0/1
 ipv6 ospf authentication ipsec spi 500 sha1 1234567890ABCDEF1234567890ABCDEF12345678

Points that matter for troubleshooting:

  • The SPI range is 256 to 4294967295. Both ends of the link must use the same SPI and key.
  • An MD5 key is 32 hex digits and a SHA-1 key is 40 hex digits. A key of the wrong length is rejected when typed.
  • Interface configuration overrides area configuration.
  • show ospfv3 interface shows the method, SPI and whether the secure socket is up. show crypto ipsec sa interface <if> shows the SAs and packet counters.
R1# show ospfv3 interface GigabitEthernet0/1 | include SPI
  SHA-1 authentication SPI 500, secure socket UP (errors: 0)

A secure socket that is not UP, or a growing error count, points to an SPI or key mismatch.

Authentication trailer (RFC 7166)

Current IOS XE releases also support the OSPFv3 authentication trailer, which works like OSPFv2 key chain authentication and does not need IPsec:

key chain OSPFV3-KC
 key 1
  key-string V3-Key-1
  cryptographic-algorithm hmac-sha-256
!
interface GigabitEthernet0/1
 ospfv3 authentication key-chain OSPFV3-KC

Check the release notes of your image before relying on it. On the exam, IPsec-based OSPFv3 authentication is the method most likely to appear.

Exam trap

OSPFv3 IPsec authentication has no "key ID" in the OSPFv2 sense. The SPI plays that role. Two routers with the same 40-digit key but SPI 500 and SPI 501 do not become neighbors.

Lab: adjacency and authentication break/fix

Topology: four IOSv routers. Area 0 is R1, R2 and R3. Area 1 is R4. R2 is the ABR for area 1. All router links are point-to-point networks. Area 0 uses MD5 (key 1, string Area0-Key) and the R3 to R4 link in area 1 uses HMAC-SHA-256 with key chain A1-KC.

graph LR
  subgraph AREA0 ["Area 0, MD5"]
    R1["R1<br/>10.255.255.1"] -- "Gi0/1 10.1.2.0/30" --- R2["R2 ABR<br/>10.255.255.2"]
    R2 -- "Gi0/2 10.2.3.0/30" --- R3["R3<br/>10.255.255.3"]
  end
  subgraph AREA1 ["Area 1, SHA key chain"]
    R4["R4<br/>10.255.255.4"]
  end
  R2 -- "Gi0/3 10.2.4.0/30" --- R4

Baseline (R2 shown)

hostname R2
key chain A1-KC
 key 1
  key-string Area1-Key
  cryptographic-algorithm hmac-sha-256
!
interface Loopback0
 ip address 10.255.255.2 255.255.255.255
 ip ospf 1 area 0
interface GigabitEthernet0/1
 ip address 10.1.2.2 255.255.255.252
 ip ospf network point-to-point
 ip ospf message-digest-key 1 md5 Area0-Key
 ip ospf 1 area 0
interface GigabitEthernet0/2
 ip address 10.2.3.2 255.255.255.252
 ip ospf network point-to-point
 ip ospf message-digest-key 1 md5 Area0-Key
 ip ospf 1 area 0
interface GigabitEthernet0/3
 ip address 10.2.4.2 255.255.255.252
 ip ospf network point-to-point
 ip ospf authentication key-chain A1-KC
 ip ospf 1 area 1
!
router ospf 1
 router-id 10.255.255.2
 area 0 authentication message-digest

Expected baseline: show ip ospf neighbor on R2 shows three neighbors in FULL/ -, and R1 can ping R4's loopback. Save the baseline before breaking anything.

Tickets

Apply one fault at a time. For each ticket write down the stuck state, the command that proved the cause and the minimal fix.

# Fault to inject Symptom you should see Proof Fix
1 R1 Gi0/1: ip ospf hello-interval 5 R1 and R2 not neighbors debug ip ospf hello: Hello R 10 C 5 on R1 no ip ospf hello-interval 5
2 R3 Gi0/0: ip ospf 1 area 1 R2 to R3 adjacency gone Log on R3: ERRRCV ... mismatched area ID from backbone area Put R3 Gi0/0 back in area 0
3 R1 Gi0/1: change the key to ip ospf message-digest-key 1 md5 area0-key Adjacency drops after the dead interval debug ip ospf adj: Mismatched Authentication Key - Message Digest Key 1 Re-enter the correct case-sensitive key
4 R3: router ospf 1, no area 0 authentication message-digest R2 to R3 drops Debug on R2: Input packet specified type 0, we use type 2 Restore the area command on R3
5 R4 key chain: cryptographic-algorithm hmac-sha-512 R2 to R4 drops show key chain differs; adj debug shows an authentication failure Match the algorithm
6 R4: router-id 10.255.255.2 then clear ip ospf process Duplicate RID log on R2 %OSPF-4-DUP_RTRID_NBR Restore R4's unique router ID
7 R3 Gi0/0: ip mtu 1400 R2 shows R3 stuck in EXSTART or EXCHANGE show ip ospf neighbor, then show ip interface Gi0/0 \| include MTU on both Remove ip mtu 1400
8 R2 Gi0/1 inbound ACL: deny ip any host 224.0.0.5 then permit ip any any R1 shows R2 in INIT, R2 does not list R1 show ip ospf neighbor on both, show access-lists Permit OSPF (permit ospf any any) before the deny

Ticket 8 is the classic one-way problem. R1 still hears R2, so it lists R2 in INIT, but R2 never sees R1's hellos and never lists R1's router ID in its own hellos.

Quick check

R1 shows its neighbor in INIT. R2 does not list R1 at all. What does that tell you?

Hellos flow from R2 to R1 but not from R1 to R2. Look for something dropping traffic in one direction toward R2: an inbound ACL or CoPP policy on R2, or a Layer 2 problem in that direction. Parameter mismatches would stop R1 from listing R2 too.

Area 0 authentication is changed to MD5 on every router. Every physical adjacency stays up, but the virtual link to area 2 goes down. Why?

The virtual link belongs to area 0, so it inherits area 0 authentication message-digest, but it has no MD5 key. Add message-digest-key to the area <transit> virtual-link command on both ends.

Two OSPFv3 routers use ospfv3 authentication ipsec spi 300 sha1 <key> with identical keys. One router has SPI 300 and the other SPI 310. What happens?

They do not become neighbors. The SPI must match on both ends of the link, along with the algorithm and key.

References