Back
Lesson 3 of 5

Troubleshooting: MTU Mismatch

Lab Objectives

  • Configure OSPF area 0 between R1, R2, R3 and R4 so neighbors form adjacencies.
  • Reproduce an MTU mismatch that causes OSPF neighbors to hang in ExStart/Exchange, identify the root cause, and correct it.
  • Verify correct adjacency and explain production implications of MTU mismatches.

Topology (BASE LAB TOPOLOGY — exact IPs shown)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP Scheme (for reference)

  • 10.10.10.0/24 — R1-R2 link
  • 10.10.20.0/24 — R1-R3 link
  • 10.10.30.0/24 — R1-R4 link
  • 10.10.40.0/24 — R2-S1 link
  • 192.168.1.0/24 — VLAN 10 (Sales)
  • 192.168.2.0/24 — VLAN 20 (Engineering)
  • 192.168.3.0/24 — VLAN 30 (Management)
  • 203.0.113.0/24 — Public/Internet simulation

Tip: In production, MTU mismatches frequently occur when an interface was configured for an overlay, tunnel, or an interface had a platform-specific MTU change. OSPF will attempt to exchange LSAs but fail during database description (DBD) exchange if MTU differs.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Configure OSPF on R1–R4

Enable OSPF process 1 on each router and advertise only the directly-connected point-to-point /24 networks that connect the routers (10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24). Use area 0.

Task 2: Introduce MTU mismatch

On R2, change the MTU on GigabitEthernet0/0 (the R1–R2 link) to 1400 bytes to intentionally create an MTU mismatch with R1 (which remains default 1500).

Task 3: Identify and fix the problem

Use OSPF and interface show commands to confirm neighbors are stuck in ExStart/Exchange and identify the MTU discrepancy; then restore adjacency by correcting the MTU or using the OSPF workaround.

Think About It: Why does OSPF fail during the DBD/Exchange stage when MTU differs, even though IP connectivity (ping) may still work between routers?

Lab Solution

Task 1 Solution: Configure OSPF on R1–R4

What we are doing: Start OSPF process 1 and advertise the point-to-point /24 networks so all routers become OSPF neighbors in area 0. This creates adjacency attempts on the router-router links.

! R1
configure terminal
router ospf 1
 network 10.10.10.0 0.0.0.255 area 0
 network 10.10.20.0 0.0.0.255 area 0
 network 10.10.30.0 0.0.0.255 area 0
end

! R2
configure terminal
router ospf 1
 network 10.10.10.0 0.0.0.255 area 0
 network 10.10.40.0 0.0.0.255 area 0
end

! R3
configure terminal
router ospf 1
 network 10.10.20.0 0.0.0.255 area 0
end

! R4
configure terminal
router ospf 1
 network 10.10.30.0 0.0.0.255 area 0
end

What just happened:

  • router ospf 1 starts an OSPF process with ID 1.
  • network <net> <wildcard> area 0 tells OSPF to enable the process on interfaces within that network and place them into area 0.
  • Routers will now try to form OSPF adjacencies on the specified interfaces.

Verify:

! On R1 - check neighbor state (expected: initially trying to form)
show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2      1     EXSTART/EXCHANGE 00:00:24   10.10.10.2      GigabitEthernet0/0
10.10.20.2      1     FULL/DR         00:00:36    10.10.20.2      GigabitEthernet0/1
10.10.30.2      1     FULL/ -         00:00:38    10.10.30.2      GigabitEthernet0/2

Note: The output above demonstrates that while R1 formed full adjacencies with R3 and R4, the R1–R2 adjacency is stuck in EXSTART/EXCHANGE. This is the symptom we will investigate.

Task 2 Solution: Introduce MTU mismatch on R2 Gi0/0

What we are doing: Configure the physical interface MTU on R2 Gi0/0 to 1400 bytes to create an MTU mismatch with R1 (1500). This simulates a real-world misconfiguration or platform-specific MTU change.

! On R2
configure terminal
interface GigabitEthernet0/0
 mtu 1400
end

What just happened:

  • interface GigabitEthernet0/0 selects the interface connected to R1.
  • mtu 1400 reduces the interface MTU to 1400 bytes. OSPF uses the interface MTU when exchanging Database Description (DBD) packets; a mismatch can prevent completing adjacency.

Verify:

! On R2 - confirm the MTU changed
show interfaces GigabitEthernet0/0

GigabitEthernet0/0 is up, line protocol is up
  Hardware is GigabitEthernet, address is 0001.0001.0001 (bia 0001.0001.0001)
  Internet address is 10.10.10.2/24
  MTU 1400 bytes, BW 1000000 Kbit
  reliability 255/255, txload 1/255, rxload 1/255

! On R1 - verify neighbor state remains stuck (EXSTART/EXCHANGE)
show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2      1     EXSTART/EXCHANGE 00:00:22   10.10.10.2      GigabitEthernet0/0

Why this matters: OSPF compares interface MTUs during adjacency establishment. If the MTU advertised in DBD headers differs, routers will not progress past ExStart/Exchange. Note that IP-level ping can still succeed despite OSPF failing to exchange LSAs.

Task 3 Solution: Identify and fix MTU mismatch

What we are doing: Use OSPF and interface show commands to identify the MTU mismatch, then restore consistent MTU to allow OSPF to complete adjacency. Also show alternative temporary workaround.

  1. Identify cause:
! On R1
show interfaces GigabitEthernet0/0

GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.10.10.1/24
  MTU 1500 bytes, BW 1000000 Kbit

! On R2
show interfaces GigabitEthernet0/0

GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.10.10.2/24
  MTU 1400 bytes, BW 1000000 Kbit

What just happened: These outputs confirm the MTU mismatch: R1 = 1500, R2 = 1400. This explains why OSPF is stuck in EXSTART/EXCHANGE.

  1. Fix by restoring R2 MTU to 1500:
! On R2
configure terminal
interface GigabitEthernet0/0
 mtu 1500
end

What just happened: We reset the physical interface MTU on R2 to match R1. With equal MTUs, OSPF can complete Database Description exchange.

Verify adjacency:

! On R1 after MTU correction
show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2      1     FULL/ -         00:00:34    10.10.10.2      GigabitEthernet0/0
10.10.20.2      1     FULL/DR         00:00:36    10.10.20.2      GigabitEthernet0/1
10.10.30.2      1     FULL/ -         00:00:38    10.10.30.2      GigabitEthernet0/2

Real-world note: In production, matching MTUs across a routed link is important because some protocols (like OSPF) use the interface MTU for control-plane exchanges; mismatches can silently break routing convergence while data-plane ping still works.

Optional workaround (not recommended long-term): If you cannot change MTU (e.g., mid-path device limits), enable the OSPF workaround to ignore MTU during adjacency formation on the affected interface(s):

! On both routers on that interface (example on R1)
configure terminal
interface GigabitEthernet0/0
 ip ospf mtu-ignore
end

! Verify neighbor will progress to FULL (if only applying mtu-ignore)
show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2      1     FULL/ -         00:00:34    10.10.10.2      GigabitEthernet0/0

Why this matters: ip ospf mtu-ignore tells OSPF to skip MTU validation during DBD exchange. It removes the safety check but permits adjacency. Use only as a last resort when MTU cannot be adjusted.

Troubleshooting Scenario

Scenario: MTU misconfigured on R2 Gi0/0

Symptom: R1 shows R2 neighbor stuck in EXSTART/EXCHANGE. Ping between R1 and R2 works.
Your task: Find and fix the issue.
Hint: Look at interface details (MTU) on both ends of the link.
Solution: Run show interfaces GigabitEthernet0/0 on both R1 and R2. If MTU differs, either set both to the same MTU (preferred) with mtu 1500 or enable ip ospf mtu-ignore on the interfaces to force OSPF adjacency despite mismatch.

Warning: Using ip ospf mtu-ignore bypasses a protocol safety check — prefer correcting MTU where possible.

Verification Checklist

  • OSPF process 1 configured on R1–R4 with correct networks.
  • R1–R2 adjacency transitions from EXSTART/EXCHANGE to FULL.
  • show interfaces confirms MTU parity on both ends (1500/1500) or ip ospf mtu-ignore set on both if used.

Common Mistakes

SymptomCauseFix
Neighbor stuck in EXSTART/EXCHANGE but pings succeedMTU mismatch between router interfacesCheck show interfaces; set mtu to same value on both sides (e.g., 1500)
Adjacency still fails after MTU matchWrong OSPF networks or area mismatchVerify router ospf network statements and area assignments
Used ip ospf mtu-ignore only on one sideWorkaround applied asymmetricallyConfigure ip ospf mtu-ignore on both neighbors or correct MTU on both devices

Challenge Task

Configure a lab where R1–R2 link must remain MTU-limited at 1400 (cannot be changed due to an upstream device). Make OSPF adjacency stable while preserving the 1400 MTU, but ensure other links remain at 1500 and all LSAs exchange correctly. Document the commands and explain why your solution is safe for the network.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security