Re[3]: OSPF max Router-LSA links [7:72024]
If the Interface MTU field is larger than can be accepted without fragmentation, then the packet is rejected. No acknowledgement is sent and the behavior after that is dependent on the vendor. Usually it results in neighbors getting stuck in Exchange or ExStart. In any case, the adjacency will never form. This particular little hole is (unfortunately) due to a fault in OSPF itself since no acknowledgement and situational handling was specified. As a CCIE friend of mine said, However, a vendor could choose to implement something that, after getting no response to DD packets, would decrease the packet size, even sending a really tiny DD packet to continue negotiations and receive DD from the other router, learning its MTU, then adjusting to that. I *think* that would work. - I personally am not aware of any vendors that implement anything like this Here's a good discussion of it: http://www.riverstonenet.com/support/ospf/stuckexstart.htm#_Toc515894155 There's also a doc on Cisco about it: http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080093f0d.shtml HTH, Karen A rose by any other name is Cisco specific terminology... *** REPLY SEPARATOR *** On 7/15/2003 at 7:29 AM Zsombor Papp wrote: At 09:48 AM 7/15/2003 +, Karen E Young wrote: KY: According to the RFC (page 99) If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. With this in mind the only time fragmentation should occur is when a virtual link is used since the MTU of a virtual link is set to 0. The Interface MTU field describes the MTU of the sending interface, not the size of the DD packet. Just because the MTU of the sending router is smaller than or equal to that of the receiving router, it doesn't follow that fragmentation can't occur. Fragmentation occurs because the data (ie. the DD packet) to be sent is larger than the MTU of the *sending* router. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72377t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re[3]: OSPF max Router-LSA links [7:72024]
Sorry, accidentally sent the message before I finished my response and DNS problems to boot... If the Interface MTU field is larger than can be accepted without fragmentation, then the packet is rejected. No acknowledgement is sent and the behavior after that is dependent on the vendor. Usually it results in neighbors getting stuck in Exchange or ExStart. In any case, the adjacency will never form. Even if the MTU is smaller than the receiving interface the exchange will fail. There's always one side that's larger and one that's smaller, so one or the other of them will hang. This particular little hole is (unfortunately) due to a fault in OSPF itself since no acknowledgement and situational handling was specified. As a CCIE friend of mine said, However, a vendor could choose to implement something that, after getting no response to DD packets, would decrease the packet size, even sending a really tiny DD packet to continue negotiations and receive DD from the other router, learning its MTU, then adjusting to that. I *think* that would work. - I personally am not aware of any vendors that implement anything like this but I could be wrong... Here's a good discussion of it: http://www.riverstonenet.com/support/ospf/stuckexstart.htm#_Toc515894155 There's also a doc on Cisco about it: http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080093f0d.shtml Here's an interesting thought... what if the router with the larger MTU checked the MTU size of its neighbor, and dynamically adjusted? No guessing involved, just match the smaller MTU and deal with the mismatch? The MTUs could remain mismatched, which might cause frame fragmentation, but the OSPF multicast traffic would be sent with matching MTU sizes. Basically after being hung in ExStart for x seconds, it would send its first DD packet using the same size received by the adjacent router. Just a thought... HTH, Karen A rose by any other name is Cisco specific terminology... *** REPLY SEPARATOR *** On 7/15/2003 at 7:29 AM Zsombor Papp wrote: At 09:48 AM 7/15/2003 +, Karen E Young wrote: KY: According to the RFC (page 99) If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. With this in mind the only time fragmentation should occur is when a virtual link is used since the MTU of a virtual link is set to 0. The Interface MTU field describes the MTU of the sending interface, not the size of the DD packet. Just because the MTU of the sending router is smaller than or equal to that of the receiving router, it doesn't follow that fragmentation can't occur. Fragmentation occurs because the data (ie. the DD packet) to be sent is larger than the MTU of the *sending* router. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72382t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Re[3]: OSPF max Router-LSA links [7:72024]
This sounds like a simplistic question, but on a link between two routers why would you have a mis-matched MTU? I can see having a MTU in a multi-hop conversation (path MTU) being less than the MTU on the outgoing, or incoming, interface, but on a direct link between two routers shouldn't the MTU be the same? I can think of many more issues that OSPF having problems if the MTU were mis-matched, like just general connectivity. Pretty much every single file transfer would end up failing; you'd have intermittent connectivity for everyone. Or, does an OSPF talk to routers that are beyond its directly connected peers? I always though that when it was said that OSPF routers flood LSAs throughout the network that they just transmit those LSAs to their neighbors, who transmit to their neighbors, etc, until all routers in the area are updated. This as opposed to one OSPF router sending updates to each and every OSPF router in the area, which necessarily may involve going over links in which neither source or destination router was connected, and may have an MTU less than either source or destination. Which one is it? Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Karen E Young [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: Re[3]: OSPF max Router-LSA links [7:72024] Sorry, accidentally sent the message before I finished my response and DNS problems to boot... If the Interface MTU field is larger than can be accepted without fragmentation, then the packet is rejected. No acknowledgement is sent and the behavior after that is dependent on the vendor. Usually it results in neighbors getting stuck in Exchange or ExStart. In any case, the adjacency will never form. Even if the MTU is smaller than the receiving interface the exchange will fail. There's always one side that's larger and one that's smaller, so one or the other of them will hang. This particular little hole is (unfortunately) due to a fault in OSPF itself since no acknowledgement and situational handling was specified. As a CCIE friend of mine said, However, a vendor could choose to implement something that, after getting no response to DD packets, would decrease the packet size, even sending a really tiny DD packet to continue negotiations and receive DD from the other router, learning its MTU, then adjusting to that. I *think* that would work. - I personally am not aware of any vendors that implement anything like this but I could be wrong... Here's a good discussion of it: http://www.riverstonenet.com/support/ospf/stuckexstart.htm#_Toc515894155 There's also a doc on Cisco about it: http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080 093f0d.shtml Here's an interesting thought... what if the router with the larger MTU checked the MTU size of its neighbor, and dynamically adjusted? No guessing involved, just match the smaller MTU and deal with the mismatch? The MTUs could remain mismatched, which might cause frame fragmentation, but the OSPF multicast traffic would be sent with matching MTU sizes. Basically after being hung in ExStart for x seconds, it would send its first DD packet using the same size received by the adjacent router. Just a thought... HTH, Karen A rose by any other name is Cisco specific terminology... *** REPLY SEPARATOR *** On 7/15/2003 at 7:29 AM Zsombor Papp wrote: At 09:48 AM 7/15/2003 +, Karen E Young wrote: KY: According to the RFC (page 99) If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. With this in mind the only time fragmentation should occur is when a virtual link is used since the MTU of a virtual link is set to 0. The Interface MTU field describes the MTU of the sending interface, not the size of the DD packet. Just because the MTU of the sending router is smaller than or equal to that of the receiving router, it doesn't follow that fragmentation can't occur. Fragmentation occurs because the data (ie. the DD packet) to be sent is larger than the MTU of the *sending* router. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72391t=72024 -- FAQ, list archives
RE: Re[3]: OSPF max Router-LSA links [7:72024]
At 02:23 PM 7/16/2003 +, Reimer, Fred wrote: This sounds like a simplistic question, but on a link between two routers why would you have a mis-matched MTU? I can see having a MTU in a multi-hop conversation (path MTU) being less than the MTU on the outgoing, or incoming, interface, but on a direct link between two routers shouldn't the MTU be the same? Different vendors might default to different values on the same interface type. In a mixed-media bridging environment the two interfaces that are supposed to exchange OSPF information might be of different types. I can think of many more issues that OSPF having problems if the MTU were mis-matched, like just general connectivity. Pretty much every single file transfer would end up failing; you'd have intermittent connectivity for everyone. Exactly. Or, does an OSPF talk to routers that are beyond its directly connected peers? Only over virtual links. Thanks, Zsombor I always though that when it was said that OSPF routers flood LSAs throughout the network that they just transmit those LSAs to their neighbors, who transmit to their neighbors, etc, until all routers in the area are updated. This as opposed to one OSPF router sending updates to each and every OSPF router in the area, which necessarily may involve going over links in which neither source or destination router was connected, and may have an MTU less than either source or destination. Which one is it? Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -Original Message- From: Karen E Young [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 7:34 AM To: [EMAIL PROTECTED] Subject: Re[3]: OSPF max Router-LSA links [7:72024] Sorry, accidentally sent the message before I finished my response and DNS problems to boot... If the Interface MTU field is larger than can be accepted without fragmentation, then the packet is rejected. No acknowledgement is sent and the behavior after that is dependent on the vendor. Usually it results in neighbors getting stuck in Exchange or ExStart. In any case, the adjacency will never form. Even if the MTU is smaller than the receiving interface the exchange will fail. There's always one side that's larger and one that's smaller, so one or the other of them will hang. This particular little hole is (unfortunately) due to a fault in OSPF itself since no acknowledgement and situational handling was specified. As a CCIE friend of mine said, However, a vendor could choose to implement something that, after getting no response to DD packets, would decrease the packet size, even sending a really tiny DD packet to continue negotiations and receive DD from the other router, learning its MTU, then adjusting to that. I *think* that would work. - I personally am not aware of any vendors that implement anything like this but I could be wrong... Here's a good discussion of it: http://www.riverstonenet.com/support/ospf/stuckexstart.htm#_Toc515894155 There's also a doc on Cisco about it: http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080 093f0d.shtml Here's an interesting thought... what if the router with the larger MTU checked the MTU size of its neighbor, and dynamically adjusted? No guessing involved, just match the smaller MTU and deal with the mismatch? The MTUs could remain mismatched, which might cause frame fragmentation, but the OSPF multicast traffic would be sent with matching MTU sizes. Basically after being hung in ExStart for x seconds, it would send its first DD packet using the same size received by the adjacent router. Just a thought... HTH, Karen A rose by any other name is Cisco specific terminology... *** REPLY SEPARATOR *** On 7/15/2003 at 7:29 AM Zsombor Papp wrote: At 09:48 AM 7/15/2003 +, Karen E Young wrote: KY: According to the RFC (page 99) If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. With this in mind the only time fragmentation should occur is when a virtual link is used since the MTU of a virtual link is set to 0. The Interface MTU field describes the MTU of the sending interface, not the size of the DD packet. Just because the MTU of the sending router is smaller than or equal to that of the receiving router, it doesn't
Re[3]: OSPF max Router-LSA links [7:72024]
MTU is not an OSPF specific value. It would be rather strange if OSPF could adjust it dynamically to its liking. However, a vendor could choose to implement something that, after getting no response to DD packets, would decrease the packet size, How do you know you don't receive response due to packet size? even sending a really tiny DD packet to continue negotiations and receive DD from the other router, learning its MTU, then adjusting to that. I *think* that would work. Sorry, which problem are you trying to solve here? If the MTUs are different on the two routers, then OSPF won't work as per the RFC. So the solution to the MTU mismatch problem IMHO is to make sure that the MTUs match. :) That (ie. that a router doesn't send a packet larger than what its neighbor can digest) sounds like a pretty basic requirement to me. Thanks, Zsombor At 11:34 AM 7/16/2003 +, Karen E Young wrote: Sorry, accidentally sent the message before I finished my response and DNS problems to boot... If the Interface MTU field is larger than can be accepted without fragmentation, then the packet is rejected. No acknowledgement is sent and the behavior after that is dependent on the vendor. Usually it results in neighbors getting stuck in Exchange or ExStart. In any case, the adjacency will never form. Even if the MTU is smaller than the receiving interface the exchange will fail. There's always one side that's larger and one that's smaller, so one or the other of them will hang. This particular little hole is (unfortunately) due to a fault in OSPF itself since no acknowledgement and situational handling was specified. As a CCIE friend of mine said, However, a vendor could choose to implement something that, after getting no response to DD packets, would decrease the packet size, even sending a really tiny DD packet to continue negotiations and receive DD from the other router, learning its MTU, then adjusting to that. I *think* that would work. - I personally am not aware of any vendors that implement anything like this but I could be wrong... Here's a good discussion of it: http://www.riverstonenet.com/support/ospf/stuckexstart.htm#_Toc515894155 There's also a doc on Cisco about it: http://www.cisco.com/en/US/tech/tk365/tk480/technologies_tech_note09186a0080093f0d.shtml Here's an interesting thought... what if the router with the larger MTU checked the MTU size of its neighbor, and dynamically adjusted? No guessing involved, just match the smaller MTU and deal with the mismatch? The MTUs could remain mismatched, which might cause frame fragmentation, but the OSPF multicast traffic would be sent with matching MTU sizes. Basically after being hung in ExStart for x seconds, it would send its first DD packet using the same size received by the adjacent router. Just a thought... HTH, Karen A rose by any other name is Cisco specific terminology... *** REPLY SEPARATOR *** On 7/15/2003 at 7:29 AM Zsombor Papp wrote: At 09:48 AM 7/15/2003 +, Karen E Young wrote: KY: According to the RFC (page 99) If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. With this in mind the only time fragmentation should occur is when a virtual link is used since the MTU of a virtual link is set to 0. The Interface MTU field describes the MTU of the sending interface, not the size of the DD packet. Just because the MTU of the sending router is smaller than or equal to that of the receiving router, it doesn't follow that fragmentation can't occur. Fragmentation occurs because the data (ie. the DD packet) to be sent is larger than the MTU of the *sending* router. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=72395t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
