MTU is not an OSPF specific value. It would be rather strange if OSPF could adjust it dynamically to its liking.
>"However, a vendor could choose to implement >something that, after getting no response to DD packets, would decrease the >packet size, How do you know you don't receive response due to packet size? > even sending a really tiny DD packet to continue negotiations >and receive DD from the other router, learning its MTU, then adjusting to >that. I *think* that would work." Sorry, which problem are you trying to solve here? If the MTUs are different on the two routers, then OSPF won't work as per the RFC. So the solution to the MTU mismatch problem IMHO is to make sure that the MTUs match. :) That (ie. that a router doesn't send a packet larger than what its neighbor can digest) sounds like a pretty basic requirement to me. Thanks, Zsombor At 11:34 AM 7/16/2003 +0000, Karen E Young wrote: >Sorry, accidentally sent the message before I finished my response and DNS >problems to boot... > > >If the Interface MTU field is larger than can be accepted without >fragmentation, then the packet is rejected. No acknowledgement is sent and >the behavior after that is dependent on the vendor. Usually it results in >neighbors getting stuck in Exchange or ExStart. In any case, the adjacency >will never form. Even if the MTU is smaller than the receiving interface the >exchange will fail. There's always one side that's larger and one that's >smaller, so one or the other of them will hang. > >This particular little hole is (unfortunately) due to a fault in OSPF itself >since no acknowledgement and situational handling was specified. > >As a CCIE friend of mine said, "However, a vendor could choose to implement >something that, after getting no response to DD packets, would decrease the >packet size, even sending a really tiny DD packet to continue negotiations >and receive DD from the other router, learning its MTU, then adjusting to >that. I *think* that would work." - I personally am not aware of any >vendors that implement anything like this but I could be wrong... > >Here's a good discussion of it: >http://www.riverstonenet.com/support/ospf/stuckexstart.htm#_Toc515894155 > >There's also a doc on Cisco about it: >http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080093f0d.shtml > > >Here's an interesting thought... what if the router with the larger MTU >checked the MTU size of its neighbor, and dynamically adjusted? No guessing >involved, just match the smaller MTU and deal with the mismatch? The MTUs >could remain mismatched, which might cause frame fragmentation, but the OSPF >multicast traffic would be sent with matching MTU sizes. Basically after >being hung in ExStart for x seconds, it would send its first DD packet using >the same size received by the adjacent router. > >Just a thought... > > >HTH, >Karen > >"A rose by any other name is Cisco specific terminology..." > >*********** REPLY SEPARATOR *********** > >On 7/15/2003 at 7:29 AM Zsombor Papp wrote: > > >At 09:48 AM 7/15/2003 +0000, Karen E Young wrote: > >>KY: According to the RFC (page 99) "If the Interface MTU field in the > >>Database Description packet indicates an IP datagram size that is larger > >>than the router can accept on the receiving interface without > >fragmentation, > >>the Database Description packet is rejected." > >> > >>With this in mind the only time fragmentation should occur is when a > >virtual > >>link is used since the MTU of a virtual link is set to "0". > > > >The "Interface MTU" field describes the MTU of the sending interface, not > >the size of the DD packet. Just because the MTU of the sending router is > >smaller than or equal to that of the receiving router, it doesn't follow > >that fragmentation can't occur. Fragmentation occurs because the data (ie. > >the DD packet) to be sent is larger than the MTU of the *sending* router. > > > >Thanks, > > > >Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72395&t=72024 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
