""chris kane"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Hi > > > > Happy Holiday to all. > > > > I have some question that I would like to ask the group regarding OSPF, > > Fragmentation and MTU working together. > > > > I have a home lab where OSPF is running find over frame-relay hub and > spoke > > configuration. The problem occurs when I tried to fragment traffic so > that > > Voice traffic will pass through the frame relay incase of congestion/or > > large traffic. So I decided to implement a Frame Relay Class with > > frame-relay fragment 64 (since most Voice traffic is 64). Now when I > enter > > this command, I notice that I lose connection with Spoke router. I can't > > even ping. So I enter the following command MTU 67 under Serial inter > face > > 0/0. So it works find for pining and tcp connection but I lose OSPF > > Neighbor connection. > > > > In order for OSPF neighbor relationships to form, MTU must match. This was > troubling to me a while back when I first started digging into OSPF. OSPF > has hello packets with certain parameters that must match. The troubling > part is that MTU is not one of those requirements. Rather, the MTU must > match issue gets introduced in the OSPF Database Description packet. > Interface MTU is part of this packet and therefore it is here that you'll > see your problem arise. I suspect that you are probably seeing everything > fine at the onset of the neighbor relationship and then when they begin to > share their database description packets, it breaks.
this brings up two aspects to me. one of "the standard" and one of design. Obviously, in practical terms, the OSPF standard calls for things that may or may not be practical in real world. So there are hacks, some of which are define, some of which are proprietary. virtual link is a defined hack. MTU appears to be proprietary. the design part come in, IMHO, because of situations like the original question raises. Probably a better solution than futzing with MTU is to initiate QoS features such as CBWFQ or LLQ. > > Set the interface MTUs to match on both sides. This should fix your problem. > If not, please re-post and provide debugs from OSPF. > > -chris > > For references see: Doyle TCP/IP Vol 1 page 500 for the OSPF Database > packet. Also, see Moy OSPF Anatomy of an Internet Routing Protocol, bottom > of page 90 where he discusses the 'link-level' difficulties. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=59913&t=59902 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
