> 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. >
Good point. I thought about that when I saw your post with the suggested ignore on MTU. This ties into some of the points that appear at the beginning of that great new RFC (3439). Should someone manipulate the behavior of the protocol or should they re-evaluate what they are trying to do and go a different route such as QOS. What could be the wider impacting results of changing the protocol? Same goes for deploying QOS. I guess one of the nice things to come away with here is the appreciation that sometimes we have a choice. -chris Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=59922&t=59902 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
