“ip ospf mtu-ignore” Is a Dangerous Command

A while ago, I wrote about the problems caused by MTU mismatch between OSPF neighbors and warned that the ip ospf mtu-ignore interface configuration command that supposedly solves the problem could cause significant headaches. Last week’s challenge was a simple illustration of what could happen if you force OSPF neighbors to establish a session even though their interface MTUs don’t match (the very first comment correctly identified the issue).

This is the router configuration I’ve used to generate the problem:

A1 Configuration
hostname A1
!
interface Serial1/0
 description Link to C1
 ip address 10.0.7.5 255.255.255.252
 encapsulation ppp
 ip ospf cost 100
 ip ospf mtu-ignore
!
router ospf 1
 log-adjacency-changes
 redistribute static subnets
 network 0.0.0.0 255.255.255.255 area 1
C1 configuration
hostname C1
!
interface Serial1/0
 description Link to A1
 mtu 512
 ip address 10.0.7.6 255.255.255.252
 encapsulation ppp
 ip ospf cost 100
 ip ospf mtu-ignore
 ip ospf 1 area 1
!
router ospf 1
 log-adjacency-changes 

The problem occurs when C1 drops the database description packet or a flooding packet sent by A1 because it exceeds the MTU size. The dropped packets appear as giants or overruns in the show interface printout.

And now for the entertaining part:

  • The problem is only partially reproducible. Sometimes, the routers are willing to accept oversized packets; sometimes, they drop them. This behavior is probably related to the IOS release and hardware platform used in the tests; it might also be triggered by a particular sequence of configuration commands.
  • The problem appears (if at all) only when the OSPF database grows. Tests in a small lab might work fine, but the production network might crash.
  • When the MTUs differ by only a few bytes, the setup might work for a long time until you happen to stumble across the correct combination of LSAs that generate the DBD or update packet of just the right size.

9 comments:

  1. I have a feeling such command popping up in the CCIE R&S Troubleshooting section... :)
  2. What should you do if you want OSPF to run between a 6500 and a 3750? The 6500 needs an MTU of 9216 for some other processes we're running. The 3750 only goes up to 1998 so ip ospf mtu-ignore seems to be the only answer. Thanks!
  3. Configure per-interface IP MTU on the 6500.
  4. What best solution if you running DMVPN and one of your spoke are running on MTU lower then 1500, lowering MTU on spoke? Well this is only solution I see, but other spokes will suffer lower MTU too, thus less effective usage of bandwidth.
  5. Best solution? Don't run OSPF over DMVPN ;)

    By definition, all hosts/routers connected to the same shared subnet must have the same MTU. Any workaround will eventually bite you.
  6. I have issue OSPF Neighbor is flapping after random interval and got error Too many retransmissions and ignore timer expired.

    Interface between two site is ethernet and Network in between is SP.

    MTU configure on both side is 1542 but one thing I observe that I can't ping packet-size more then 1500 (with df bit or without df bit).

    Kindly let me know, how I transparent SP issue for OSPF neighbor adjency.
  7. Add more...

    I have also enter command ip ospf mtu-ignore but no use
  8. @Jauhar: You can try correcting the MTU value. For e.g. http://blog.netbraintech.com/2013/07/22/mtu-mismatch-ospf/
  9. Ivan! You're the bomb baby. Dealing with this issue right now. Want to use that command but we are having issues. Love your blog.
Add comment
Sidebar