MTU size on physical and logical port in OSPF

Generally, all nodes on a given VLAN (L2 segment) need to use the same maximum frame size (or MTU, by derivation).

More specifically, all nodes in a segment need to be able to receive the largest frame size that any other node may transmit, ie. the receive maximum frame size may be larger than the transmit one.

the MTU of the physical interface should take priority over its sub-interfaces.

Not really. While many hardware interfaces only support a single maximum frame size value for reception - regardless of VLAN, the maximum transmitted size must be adjustable per VLAN.

The MTU of the physical interface will always need to be larger than the MTU of any L3 logical sub-interfaces. That's because when sending an IP packet from a sub-interface the physical port will also need to append a VLAN tag (4 bytes) to the ethernet header so that traffic from each sub-interface can be differentiated. Now, because the VLAN-tag is in the ethernet header and not the IP header, it isn't counted in the IP MTU of the sub-interface, but it is counted in the physical MTU of the parent interface.

At least that's how it works in Junos OS. It's been a long time since I've wrestled with IOS, but do I recall the way MTU is calculated being different and not particularly intuitive by comparison.

Could this cause issues with other routers or implementations? Have you encountered any implementation where the sub-interface MTU size changes when the physical interface MTU is modified?

In Junos OS if the sub-interface MTU size is not configured, it will change in lockstep with the physical interface e.g.: if you increase the physical port mtu by 10 bytes, the mtu of the logical sub-interface will increase by 10 bytes (but still always be 4 bytes less than the physical interface).

If however, you configure the IP MTU of the sub-interface and then increase the MTU of the interface, it will remain as per your setting, which is a sensible default (otherwise you'd be overriding configuration which is not good).

If you try to lower the interface MTU or raise the sub-interface MTU to within 4 bytes of the other, Junos OS will throw a commit error and not allow you to proceed.

The only reason to ever mess with the IP MTU in an OSPF scenario is if you have mis-matched interfaces - ADSL WAN circuits with PPPoEoA at one end (MTU 1492) talking to routers with Ethernet (MTU 1500) on the other end is a classic.

In this scenario, Cisco has a knob ip ospf mtu-ignore which will allow OSPF to form an adjacency regardless of the differences. You will then need to adjust segment sizes of TCP traffic transiting the link with ip tcp adjust-mss 1452.

Probably unrelated point in this topic is At ingress the egress port selection happen and packet mtu checking against the outbound interface In case of eth vs members and sub vs physical Result of outbound int check is eth or sub But in eth case it will override the members But sub result is fall back to vlan dot1q tag through the physical int so physical mtu take affect

And the catch is in case of sub some vendors does not even try to fragment the packet as its already encapsulated for forwarding . So it directly drop the packed