At 8:24 PM +0000 12/28/02, 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.
There is a subtlety here, which may be getting hidden by the fact that labs and the test facility are mostly or completely routers, rather than hosts. If you think about it, the proper place to limit MTU (other than for medium conversion) is not on the router, but on the host. Admittedly, not all hosts have the ability to set their MTU. There is a TAC guide for altering host TCP/IP parameters, but for some obscure reason, it's buried under OSI Application Services: http://www.cisco.com/en/US/tech/tk472/tk473/technologies_tech_note09186a008011a218.shtml Another subtlety is that there can be very good reasons either to have different control and forwarding paths. I need to check into the details, but one approach might be to leave the basic MTUs at 1500 or so, but limit the MTU on MPLS or other tunnels such that host path MTU discovery gets a limit on data MTU size. A non-scalable (in the core) way to do things would be to policy route based on protocol type and associated MTU. Routing traffic gets handled differently than data traffic -- that's inherent in the IP precedence field, where the top two levels are reserved for control traffic. > > > >> > 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=59931&t=59902 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
