Re: Question RE: OSPF and MTU [7:59902]
At 8:24 PM + 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=7i=59931t=59902 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Question RE: OSPF and MTU [7:59902]
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. Any help on this topic would be helpful. I am trying to understand how all these 3 component can work together? Thanks. Faisal Khan CCIE Candidate. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59902t=59902 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question RE: OSPF and MTU [7:59902]
Khan Faisal 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. Any help on this topic would be helpful. I am trying to understand how all these 3 component can work together? ip ospf mtu-ignore on the interfaces in question this is as good a place as any to plug Parkhurst's OSPF Command and Configuration Handbook, which I got myself for Christmas. Like the BGP book, this one goes through all the ommands, and contains a lot of information which, while in the Cisco documentation, may not be easily found or clearly explained. I haven't done enough with this book to have a clear opinion of it, but I do believe that more training books should take this approach. I imagine the reason they don't is the sheer hard boring work for the author, the editors, and the tech reviewers. The good thing is that many of the examples can be tested with only two routers, and even the more complex example use only 3 or 4 routers, yet make their point quite clearly. Thanks. Faisal Khan CCIE Candidate. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=59906t=59902 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question RE: OSPF and MTU [7:59902]
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. 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=7i=59909t=59902 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question RE: OSPF and MTU [7:59902]
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=7i=59913t=59902 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Question RE: OSPF and MTU [7:59902]
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=7i=59916t=59902 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
