OSPF MTU mismatch between IOS XE and IOS XR

[dundient]

Hello everybody, could anybody explain me about the MTU mismatch logic between IOS XE and IOS XR routers .

I have 2 routers(IOS XE and IOS XR) that are connected directly. I've configured the ospf between them and got stuck in EXSTART state. As I know EXSTART state indicates that there is a mtu mismatch between the routers but even after matching the mtu's still can't solve the problem. For now, the interfaces are in default mtu state: IOS XE L2&L3 mtu 1500, IOS XR L2&L3 MTU 1514

CONFIGS:

IOS XE:

interface GigabitEthernet3
ip address 1.1.29.2 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0

IOS XR:

interface GigabitEthernet0/0/0/2
ipv4 address 1.1.29.9 255.255.255.0
!
router ospf 1
router-id 9.9.9.9
address-family ipv4 unicast
area 0
interface GigabitEthernet0/0/0/2
network point-to-point
!

There are "debug ip ospf adj" the outputs of the 2 routers:

IOS XE:

IOS XR:

Any ideas how to solve the MTU mismatch? Thank you in advance

[MHM Cisco World]

Add to ios xe 

Ip ospf mtu ignore 

And check 

MHM

[dundient]

Thank you for your response.

I've tried the "ip ospf mtu-ignore" command and cleared ip ospf process but the result is still the same.

[MHM Cisco World]

mtu-ignore <<- add this in ospf of ios xr 

MHM

[Ramblin Tech]

"Hello everybody, could anybody explain me about the MTU mismatch logic between IOS XE and IOS XR routers ."

A couple of general references, not specific to OSPF...

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html

https://community.cisco.com/t5/service-providers-knowledge-base/differences-in-mtu-configuration-between-ios-and-ios-xr/ta-p/3122869

[Joseph W. Doherty]

I was reading your first reference last night.  My understanding, if both devices are using default MTU settings, on "ordinary" Ethernet interfaces, they should be using the same MTU, although XE doesn't show L2 overhead as part of MTU while XR does.

Might be worthwhile to see a show interface for each, to confirm what each interface's MTU is.

[Ramblin Tech]

Hey Joe,

I believe your assessment is confirmed in the second reference (and in Harold's post) as:

"By default, IOS and IOS XR will have matching MTU settings.  Values are 1514B(IOS-XR)/1500B(IOS) for Ethernet ... L3 protocols will inherit their MTU from interface MTU and they will be automatically aligned between IOS and IOS-XR. There is no need to change those settings unless required. Typical scenario where increase of MTU is needed is MPLS core of the network."

[Joseph W. Doherty]

Jim, yup, from information OP provided, it seems, to me, uncertain that the problem is a device MTU configuration mismatch, although it can easily be taken that way because of the different ways XE and XR report MTU.  Further, often posters don't provide all relevant configuration snippets, so I also wondered if jumbo Ethernet might be in play, especially as not all Cisco platforms, I recall (?), support identical jumbo MTU.  Hense, my prior reply's mention seeing running interface info worthwhile (to insure what MTU being used by interfaces).

I suspect OP is "chasing" this issue as being a MTU issue as it's the classical cause of the described OSPF EXSTART hang.

Both @Harold Ritter and @paul driver are looking (rightly, I think) for causes beyond the classical device MTU interface configuration.

Paul wonders about the actual topology, a good question as the connecting subnet is a /24 using OSPF p2p (which can be just fine, but perhaps just a bit unusual, especially with a Class A public IP).

Paul also suggests not using MTU ignore, even if it fixes the issue, but rather fix the MTU issue.  I would recommend the same, if possible.

[Joseph W. Doherty]

---

@Joseph W. Doherty wrote:

Paul also suggests not using MTU ignore, even if it fixes the issue, but rather fix the MTU issue.  I would recommend the same, if possible.

---

This TechNote describes why it is best practice not to use the command ip ospf mtu-ignore.

[Harold Ritter]

Hi @dundient ,

The L2 MTU on XR is 1514 and the L3 MTU is 1500. The L3 MTU is 1500 on the XE side as well. So no MTU mismatch issue there.

From the output you provided the XE side does not seem to receive the DBD packets from the XR side.

Could you validate that the path MTU between the two devices is 1500 using the following command from the XE side:

ping 1.1.29.9 size 1500 df-bit

Regards,

[paul driver]

Hello
those debug do not mention MTU issue, if the suggested ignore mtu command fixes the peering i would say not to stay with it, as you would still have an mtu issue on the network.

You dont say if these twp rtrs are directly connected or if they are attached to a lan segment or in p2p or hub/spoke topology?
Can the rtrs ping each other correctly - if not you may have a L2 issue

Do you have the correct ospf network type  for example with hub/spoke the hub needs to be P2M not P2P)