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=53079&t=53047 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
