The Long and Winding Road wrote: > > ""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.
That's weird. Ping should have still worked with an MTU of 64. It's only 20 bytes of an IP header and 8 bytes of ICMP, if you don't add data. Probably your ping tool defaulted to adding data, but you could have changed that. > So it works find for pining and tcp connection but I > lose OSPF > > > Neighbor connection. That makes sense. The neighbors have to agree on MTU, as others have said. > > > > > > > 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. Using QoS features instead of futzing (to use your term ;-) with MTU sounds like good advice. You only need to futz with MTU if serialization delay is an issue, and it's not an issue on high-speed interfaces. What speed is this interface? >From a philosophical point of view, since Chuck kind of took us into that realm ;-), I would say that if you mess with a parameter and it wrecks something as fundamental as your routing protocol, then you probably shouldn't be messing with it. The other side of the coin might be, however, that a routing protocol that can get messed up by a change in a paramter to support a particular application is on shaky grounds to begin with. This may fit into the Simplicity Principle mentioned in RFC 3439! Priscilla > > > > > > > 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=59916&t=59902 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
