One of the relatively few nice things about working with data communications these days is that people like John Moy design non-policy based routing protocols, and he's fairly conscientious about leaving clues regarding the motivations underpinning the design decisions.
In the case of OSPF, I note thematic commonalities between the intent to reserve the right to manufacture as large a packet as the medium will allow according to clues such as the mtu, and the assertion that running the protocol directly over ip is preferable to relying on udp partially because of the extra 8 bytes which are eligible to carry ospf data (section 3.2 of the book IIRC, and possibly in versions of the RFC as well). Maybe some routing anthropologist might be able to make something of that. In the interests of fairness, ospf might be said to not "care about" mtu, but in cases involving a large enough mtu disparity, it might be said not to "care to" form an adjacency either (this is particularly problematic given what organizations are willing to pay people who troubleshoot such issues, since ip connectivity & certain other routing protocols might very well be functional under these conditions). One way to characterize "weird interaction" might be as "indeterminism." After expending much effort to establish whether or not the difference in mtu calculation between the east coast router vendor and the west coast router vendor was 4 or 6 bytes, trying to remember which direction the difference ran, and trying to identify which part of the packet/frame/grouping-of-bits the one vendor was ignoring (as packet capturing products are sometimes said to do), scenarios would emerge whereby routers running identical operating systems over similarly provisioned lines of pupportedly identical capacity would require different offsets as revealed by means of debug messages/pcap traces/log entries. I lost the patience to even guess at what structural differences might account for the offset required to make a frame relay cross-vendor adjacency form. ----- Original Message ----- From: "Howard C. Berkowitz" To: Sent: Wednesday, April 17, 2002 8:32 PM Subject: Re: OSPF and MTU, spawned from the OSPF vs. EIGRP thread [7:41788] > At 3:43 PM -0400 4/17/02, Kane, Christopher A. wrote: > >In an attempt to find out why MTU is examined (more precisely, why it's > >examined in the Database Description packets instead of the Hello packets) > >one of my co-workers found this passage in IETF meeting minutes: > > > >"Editor's note: These minutes have not been edited. > > > >The OSPF Working Group met on Wednesday, December 11th from 1300-2500 at > >the San Jose IETF. Minutes of the meeting follow: > > > >The second problem, reported by Dan Senie of Proteon, concerns MTU > >mismatches between OSPF neighbors. This can cause flooding between > >the two neighbors to fail, with large Link State Updates being > >continually retransmitted. To fix this, we will report interface MTU > >in Database Description packets. A router will discard received > >Database Description packet which advertise an MTU that is larger > >than the router can receive. In this way, adjacencies will not form > >between routers having MTU mismatches. Tony Li expressed a desire > >for a more general purpose mechanism. There was also a question > >whether the same thing will have to be done for OSPF for IPv6 (we > >think so)." > > > > > >Very informative. Thank goodness for meeting minutes. Here's the link if > >anyone is as hung up on this as I seem to be. :) > > > >http://www.ietf.org/ietf/ospf/ospf-minutes-96dec.txt > > Hmmmm...I _think_ I was at that meeting...or at least one in SJ about > that time. > > In a broader sense, I've run into other operational issues involving > the MTU. There's been a weird interaction between Cisco and Bay RS > OSPF, where Bay thinks Cisco's 1500 MTU is 1472. Don't know if it > ever was fixed. Incidentally, Passport OSPF is a different > implementation than Bay RS. > > While, in principle, OSPF supports fragmentation, it's one of those > things that I avoid like the plague. It tends to exercise parts of > the code that were rarely tested. When I was at Nortel, a sales type > came running in announcing that some competitor could do, IIRC, 47 > neighbors per hello. He wanted us to say we could do more, just > because bigger numbers are better in sales. The sanity of having 47 > neighbors on an interface was not considered. > > Anyway, I did a back-of-the-envelope calculation, and this number > (might have been 46 or 48) was the maximum number of neighbors that > could fit into a 1500 byte Hello packet. Good, practical restriction, > that never should be approached in practice. > > -- > "What Problem are you trying to solve?" > ***send Cisco questions to the list, so all can benefit -- not > directly to me*** > **************************************************************************** **** > Howard C. Berkowitz [EMAIL PROTECTED] > Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com > Technical Director, CertificationZone.com http://www.certificationzone.com > "retired" Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=41803&t=41803 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
