“ip ospf mtu-ignore” is a dangerous command

Two years 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:

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
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 exceeds because it exceeds the MTU size. The dropped packets appear as giants or overruns in the show interface printout.

And now for the really fun part:

  • The problem is not completely 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 which generate the DBD or update packet of just the right size.

Recent posts in the same categories

9 comments:

  1. Nish Vamadevan 29 November 2009 14:36
    I have a feeling such command popping up in the CCIE R&S Troubleshooting section... :)
  2. Guy Morrell 16 December 2009 13:50
    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. Ivan Pepelnjak 23 January 2010 20:57
    Configure per-interface IP MTU on the 6500.
  4. Nikolay Shopik 30 June 2011 21:06
    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. Ivan Pepelnjak 01 July 2011 19:12
    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. Jauhar 14 July 2011 05:54
    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. Jauhar 14 July 2011 05:57
    Add more...

    I have also enter command ip ospf mtu-ignore but no use
  8. Anonymous 23 July 2013 19:31
    @Jauhar: You can try correcting the MTU value. For e.g. http://blog.netbraintech.com/2013/07/22/mtu-mismatch-ospf/
  9. Anonymous 23 August 2014 19:47
    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
Home
Sidebar