At 02:23 PM 7/16/2003 +0000, Reimer, Fred wrote: >This sounds like a simplistic question, but on a link between two routers >why would you have a mis-matched MTU? I can see having a MTU in a multi-hop >conversation (path MTU) being less than the MTU on the outgoing, or >incoming, interface, but on a direct link between two routers shouldn't the >MTU be the same?
Different vendors might default to different values on the same interface type. In a mixed-media bridging environment the two interfaces that are supposed to exchange OSPF information might be of different types. > I can think of many more issues that OSPF having problems >if the MTU were mis-matched, like just general connectivity. Pretty much >every single file transfer would end up failing; you'd have intermittent >connectivity for everyone. Exactly. >Or, does an OSPF talk to routers that are beyond its directly connected >peers? Only over virtual links. Thanks, Zsombor > I always though that when it was said that OSPF routers flood LSAs >throughout the network that they just transmit those LSAs to their >neighbors, who transmit to their neighbors, etc, until all routers in the >area are updated. This as opposed to one OSPF router sending updates to >each and every OSPF router in the area, which necessarily may involve going >over links in which neither source or destination router was connected, and >may have an MTU less than either source or destination. Which one is it? > >Fred Reimer - CCNA > > >Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 >Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 > > >NOTICE; This email contains confidential or proprietary information which >may be legally privileged. It is intended only for the named recipient(s). >If an addressing or transmission error has misdirected the email, please >notify the author by replying to this message. If you are not the named >recipient, you are not authorized to use, disclose, distribute, copy, print >or rely on this email, and should immediately delete it from your computer. > > >-----Original Message----- >From: Karen E Young [mailto:[EMAIL PROTECTED] >Sent: Wednesday, July 16, 2003 7:34 AM >To: [EMAIL PROTECTED] >Subject: Re[3]: OSPF max Router-LSA links [7:72024] > >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_note09186a0080 >093f0d.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=72399&t=72024 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
