> On Sep 21, 2023, at 13:06, Alexander Okonnikov > <[email protected]> wrote: > > Hi Owen, > > RFC 2328 doesn't require MTUs to be matched. It unambiguously says that > "Interface MTU ... is larger than the router can accept on the receiving > interface ...". RFC 2328 even doesn't say something about MTU of receiving > interface. So, if implementation on router A performs check for MTU mismatch > (i.e. from router A point of view they are expected to be equal), it is > misinterpretation of RFC 2328.
Perhaps… However, it’s such a widespread misinterpretation that if you do a search for “OSPF stuck in EXSTART”, almost every result is a discussion of how this happens when the interface MTUs don’t match: https://www.google.com/search?client=safari&rls=en&q=ospf+stuck+in+exstart&ie=UTF-8&oe=UTF-8 🔎 ospf stuck in exstart - Google Search google.com > > Yes, RFC 5838 says something another - it, for unknown reason, says, that RFC > 2328 says that DBD to be rejected if Interface MTU value in DBD is greater > than the receiving interface's MTU. I don't know why it is needed to compare > those two values, but, again, even in this case there is no requirement for > MTU matching. There is requirement for to be not larger, and this is > different requirement. Please, correct me if I'm wrong. Well… sort of… If A must not be larger than B and B must not be larger than A, then A must equal B. True, the router with the larger MTU will accept the smaller MTU (theoretically, though FRR OSPFD does report the received smaller MTU in the DBD as a problem and won’t progress the negotiation and this is also true of many other implementations). Hard to imagine how one could send a package complaint with a 0 MTU, so this doesn’t seem all that unreasonable absent special casing for MTU 0 beyond the “OSPF virtual-link” scenario intended in RFC5340 and RFC5838. Owen
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
