OSPF Adjacency take longer to converge due to MTU Mismatch
1541
Created On 04/28/23 22:21 PM - Last Modified 08/14/25 21:08 PM
Symptom
- Due to a mismatch in MTU, OSPF adjacency takes longer to come up.
- OSPF be stuck in Exchange or EX-Start
- Global counter shows that the drop is due to flow_ipfrag_size_not_match.
- Routed logs shown below (less mp-log routed.log)
mp routed.log debug: panos_decap_data(pan_routed_cfg.c:8496): panos_decap_data(proto ospf)
mp routed.log **** AUDIT 0x3e01 - 199 (0000) **** I:0000a467 F:00000040
mp routed.log qoamnfsa.c 133 :at 04:19:43, 28 April 2023 (2819314 ms)
mp routed.log OSPF 2 i/f idx 0X00000400 rtr ID 10.1.2.5 IP addr 10.123.236.2 neighbor does not need to become adjacent. <<<<<<
mp routed.log DB DESCRIPTION packet received with mismatched interface MTU size 9216 >>> Neighbor MTU
...
mp routed.log Expected MTU size = 9192 <<<local defined MTU.
...
mp routed.log info routing default routed- 0 OSPF stopped graceful restart. Protocol: OSPFv2. Exit reason: restart completed
Environment
- Any Palo Alto Firewalls
- Supported PAN-OS
- High-Availability (HA) configured
- OSPF
Cause
MTU mismatch.
Resolution
- Configure MTU on both sides to match.
- The change can be done under Device > Setup > Session tab.
- Commit the changes.
- Reboot the device in order for this change to take effect.
Note: MTU mismatch can cause OSPF not to come up even in a standalone device.
Additional Information
- How to Enable/Use/Disable/Check Jumbo Frame Support on a Palo Alto Networks Firewall
- PCAP show IP fragmentation
- Below is Example of PCAP with OSPF stuck in Ex-start