In accordance with Kevin's theme, I would add that MTU is an interoperability problem because people use the term in different ways, refering to different OSI layers. Is it 1518? Yes, if you are talking about Ethernet and are counting the header and FCS, but not the pramble, and not adjusting for any VLAN or other tagging. Or should it be 1500 bytes? Yes, if you are talking about the payload in an Ethernet frame.
Or, you may see it set to 1480 bytes. That is the size of the payload in an IP packet (not counting the IP header, which is typically 20 bytes.) Another common value is 1460 bytes, which is really the size of the payload in a TCP/IP packet (not counting the IP or TCP headers, which are typically 20 bytes each). What if you're doing tunneling? GRE adds 24 bytes. Will that still fit into the data-link-layer MTU? And if it doesn't, are the IP fragments that result going to make it across the network problem-free? Or perhaps the Don't Fragment bit was set or firewalls don't allow fragments, etc. It can get kind of ugly. I once troubleshot an OSPF problem where one router was set to 1460 and another was set to 1500. The network admins hadn't coordinated their understanding of what MTU means. The routers couldn't establish adjacency until we diagnosed and fixed the MTU mismatch. Priscilla Kevin Cullimore wrote: > > Inline, starting from the very bottom on up. > > ----- Original Message ----- > From: "Frank Merrill" > To: > Sent: 10 September 2002 10:41 pm > Subject: RE: OSPF MTU [7:53047] > > > > Priscilla Oppenheimer wrote: > > > > > > OSPF routers that don't agree on the MTU can get stuck in > the > > > EXSTART phase and never succesfully exchange their database > > > description (DBD) packets, thus never becoming fully > adjacent. > > > > And I've actually seen this happen between a Cisco 6509 with > a Flexwan and > > A3 Port adapter at one end, and at the other end was a Nortel > BCN router > > with an ARE card. > > > > This was tested in a lab and the team who was implementing it > got it > working > > in the lab (it didn't work initially) by setting the > 'mtu-ignore'. > > Unfortunately when it went to production the adjacency > wouldn't come up > > because now the DBD's were too large. It turned out that in > the Lab the > > adjacency came up because the initial descriptors were rather > small, and > > hence the DBD's fell at less than a full MTU size, and came > up ok in the > lab > > once they told the Cisco to ignore the MTU mismatch. > > > > Fixed this in production by looking at what the Cisco box > recorded in it's > > log that the mismatch size was, and set them appropriately. > The Nortel box > > actually sent something different than what it was actually > set for, and > so > > that gave us a fit for a few minutes, until we saw what it > was actually > > sending in the Cisco log. > > It's been in operation for over a year now. > > The safest strategy is probably to synchronize the output by > adjusting the > parameters (which needs to be distinguished from a mere > synchronization of > the parameters) either by inspection of IOS debug/RS log output > or analyzing > packet capture (substitute vendor-specific marketing terms as > appropriate). > The defaults set by both vendors mentioned in this post > disagree often, and > attempts at establishing rules of thumb often require more > effort than most > networking types are willing to (or have time to) expend. It's > a relief to > see that people actually work through these issues instead of > behaving like > Ford is where their private exchange & vpn interoperability > issues are > concerned (network world has a recent feature on the subject, > but I don't > have the url handy-sorry). > > > > > Have fun, > > Frank Merrill > > > > > > > > Neither router should have the MTU set to bigger than the > > > maximum as specified by the relevant standards for the data > > > link in use, but one of the routers could be set with an MTU > > > that is smaller than the max allowed. This router might be > > > unable to receive full-sized DBD packets from its neighbor. > > > > > > One fix is just to make sure the routers do agree on the > MTU. > > > But what if the other router is Brand X router and doesn't > > > support such a change? > > > > > > In that case, you might want to use this new "ip ospf > > > mtu-ignore" command. > > On the bright side (for corporate leadership, at least), this > command & > analagous ones on competing platforms lower the technical skill > required to > establish connectivity between devices with dissimilar defaults. > > On the unbright side (for all concerned), the design > considerations > prompting the strict reactions to MTU mismatches seem to > involve (according > to passages from the Moy book featuring "anatomy" in the title) > a willful > reservation of the right to max out the payloads of ospf > packets in order to > avoid the prospect of ip-level fragmentation (and possibly > other unnamed > unacceptable scenarios). > > An all-too-shallow experience base leads me to conclude that > these > differences tend to involve less than 100 bytes, and often > under 10 > (although the range of possible sets of disparities within that > range is > striking in its magnitude and occasional lack of any defining > pattern), > which might legitimize a more widespread adoption of these > "parameter-negotiation-avoidance" strategies. Does anyone have > contrary > data? > > > > > > > Here's what Cisco says: > > > > > > "Cisco IOS . Software Release 12.0(3) introduced interface > MTU > > > mismatch detection. This detection involves OSPF advertising > > > the interface MTU in the DBD packets, which is in accordance > > > with the OSPF RFC 2178, appendix G.9. When a router > receives a > > > DBD packet advertising a MTU larger than the router can > > > receive, the router ignores the DBD packet and the neighbor > > > state remains in exstart. This prevents an adjacency from > > > forming. To fix this problem, make sure the MTU are the > same on > > > both ends of a link. > > > > > > In Cisco IOS Software 12.1(3), the interface-level ip ospf > > > mtu-ignore command was introduced to turn off the MTU > mismatch > > > detection; however, this is only needed in rare instances." > > > > > > See this URL for the full story: > > > > > > http://www.cisco.com/warp/public/104/12.html > > > > > > Priscilla Oppenheimer > > > > > > Hello Goodbye wrote: > > > > > > > > There is a command 'ip ospf mtu-ignore' that makes > > > > ospf ignore the mtu at the interface for neighbor > > > > establishment. This may be a dumb question but since > > > > all the neighbors have to be on the same media to > > > > establish wouldn't the mtus be the same. > > One important discontinuity that emerges as ever-more-prevalent > the further > back you look is the one between standards compliance and > interoperability. > > In general, > > standards compliance <> interoperability. > > A rather imprecise heuristic for navigating the continuum > inherent in that > relationship might read: the older the standard/specification > is, the > greater the gap between the two goals. At some juncture (most > emphatically > reached in this case), the lack of interoperability gives way > to a lack of > connectivity. > > > > > > > > Obviously > > > > there is not always the case or they wouldn't have the > > > > mtu-ignore command. > > > > > > > > Ben > > > > > > > > __________________________________________________ > > > > Yahoo! - We Remember > > > > 9-11: A tribute to the more than 3,000 lives lost > > > > http://dir.remember.yahoo.com/tribute > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=53126&t=53047 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
