RE: OSPF max Router-LSA links [7:72024]
hebn wrote: > > hello,everyone: >OSPF use raw socket (datagram) to communicate with peers. In > general, layer 2 frame has a MTU of 1500 bytes. >how does cisco router propagate router-lsa whose size exceed > 1500 bytes(more than 122 links in one area)? Well, I don't have a definite answer, but I'll discuss it with you in the hopes of lighting a fire under one of the OSPF experts on this list. Howard? Chuck? Peter? Where's Pamela when we need her? :-) OSPF runs directly above IP. I don't know if that could be called "raw socket" which is a UNIX thing? My perception is that with Cisco IOS, OSPF calls IP with a set of parameters and lets IP handle the rest. So maybe that's sort of raw. I can say this: The OSPF packets I have seen coming out of Cisco routers have the IP fragmentation bit set to "May Fragment." This makes me think that Cisco's OSPF relies on IP to push the bytes into the data-link-layer frame and fragment if necessary. The OSPF RFC (RFC 2178) says this: "OSPF does not define a way to fragment its protocol packets, and depends on IP fragmentation when transmitting packets larger than the network MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header). The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible." Unfortunately, that's not very clear. It implies that the recommended method is for OSPF to split its own protocol packets. But that the method for doing this is undefined and that's OK because OSPF can depend on IP to do fragmentation. Cisco routers tell each other their MTU in database description packets, per RFC 2178. Until recently, if the routers didn't agree on the MTU, they wouldn't become adjacent. A recent IOS version supports telling a router to ignore the other side's MTU so they can still become adjacent. That doesn't answer your question, but maybe there are some hints in the article that discusse the "ip ospf mtu-ignore" feature here: http://www.cisco.com/warp/public/104/12.html ___ Priscilla Oppenheimer www.priscilla.com > __ > > === > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72043&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF max Router-LSA links [7:72024]
At 9:38 PM + 7/8/03, Priscilla Oppenheimer wrote: >hebn wrote: >> >> hello,everyone: > >> OSPF use raw socket (datagram) to communicate with peers. In > > general, layer 2 frame has a MTU of 1500 bytes. I'm not sure I'd call it a strict datagram protocol. In some cases, it's acknowledged datagram, either directly or indirectly acknowledged. In other cases, such as database initialization, there's clearly a connection -- just not a TCP connection. > >how does cisco router propagate router-lsa whose size exceed >> 1500 bytes(more than 122 links in one area)? > >Well, I don't have a definite answer, but I'll discuss it with you in the >hopes of lighting a fire under one of the OSPF experts on this list. Howard? >Chuck? Peter? Where's Pamela when we need her? :-) It's fairly simple in Wellfleet/Bay/Nortel code -- you send multiple LSAs. There's nothing that says all the database entries of one type have to fit in the same LSupdate. Certainly, in a large area, there will need to be more than one LSupdate to convey all the Type 2 LSAs. > >OSPF runs directly above IP. I don't know if that could be called "raw >socket" which is a UNIX thing? My perception is that with Cisco IOS, OSPF >calls IP with a set of parameters and lets IP handle the rest. So maybe >that's sort of raw. I'd have to go look at Moy's or another UNIX based implementation to see how the calling is done. IOS is not UNIX based. Several other vendor implementations run a realtime OS such as VXworks. > >I can say this: The OSPF packets I have seen coming out of Cisco routers >have the IP fragmentation bit set to "May Fragment." This makes me think >that Cisco's OSPF relies on IP to push the bytes into the data-link-layer >frame and fragment if necessary. > >The OSPF RFC (RFC 2178) says this: > >"OSPF does not define a way to fragment its protocol packets, and depends on >IP fragmentation when transmitting packets larger than the network MTU. If >necessary, the length of OSPF packets can be up to 65,535 bytes (including >the IP header). The OSPF packet types that are likely to be large (Database >Description Packets, Link State Request, Link State Update, and Link State >Acknowledgment packets) can usually be split into several separate protocol >packets, without loss of functionality. This is recommended; IP >fragmentation should be avoided whenever possible." > >Unfortunately, that's not very clear. It implies that the recommended method >is for OSPF to split its own protocol packets. But that the method for doing >this is undefined and that's OK because OSPF can depend on IP to do >fragmentation. Fragmentation gets scary when you are doing real-time control plane traffic. > >Cisco routers tell each other their MTU in database description packets, per >RFC 2178. Until recently, if the routers didn't agree on the MTU, they >wouldn't become adjacent. A recent IOS version supports telling a router to >ignore the other side's MTU so they can still become adjacent. > >That doesn't answer your question, but maybe there are some hints in the >article that discusse the "ip ospf mtu-ignore" feature here: > >http://www.cisco.com/warp/public/104/12.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72044&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
The LSA will be fragmented at the IP layer. Thanks, Zsombor At 11:39 AM 7/8/2003 +, hebn wrote: >layer 2 frame has a MTU of 1500 bytes. >how does cisco router propagate router-lsa whose size exceed 1500 >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72045&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 10:46 PM + 7/8/03, Zsombor Papp wrote: >The LSA will be fragmented at the IP layer. Do you know for certain this is what Cisco's implementation does? The OSPF code is aware of the MTU and can build OSPF packets for it. I don't think you're really going to simplify it by relieving it of the need to keep track of lengths. On the other hand, if you send a LSupdate that is at the MTU, the receiving router can immediately start checking and installing it in the LSDB, without waiting for fragments. This allows some concurrency between OSPF packet transmission and OSPF protocol processing. >At 11:39 AM 7/8/2003 +, hebn wrote: >>layer 2 frame has a MTU of 1500 bytes. >> how does cisco router propagate router-lsa whose size exceed 1500 > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72046&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
The original question (as I understood) was about a single LSA that is larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). I can't see how such an LSA could be divided into multiple OSPF messages so the only logical (implementation independent) solution seems to be to fragment the packet at the IP layer. Am I missing something? If you are asking about how LSAs that are individually smaller than 1500 byte are grouped together, then my (moderately educated :) answer is this: IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps packing the LSAs into the same packet as long as their total length is below MAX_OSPF_DATA, the net result being that the size of the IP packet can be up to 1500 bytes (and will in fact be close to it if the individual LSAs are not too big) if there are enough LSAs, regardless of the MTU. So for example if you set the IP MTU on an Ethernet interface to 500 bytes, and you have a large enough OSPF database, then you should see a lot of fragmented OSPF packets, regardless of how big the individual LSAs are. I didn't write the code though, so take all this with a grain of salt. :) Thanks, Zsombor At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >The LSA will be fragmented at the IP layer. > >Do you know for certain this is what Cisco's implementation does? >The OSPF code is aware of the MTU and can build OSPF packets for it. >I don't think you're really going to simplify it by relieving it of >the need to keep track of lengths. > >On the other hand, if you send a LSupdate that is at the MTU, the >receiving router can immediately start checking and installing it in >the LSDB, without waiting for fragments. This allows some concurrency >between OSPF packet transmission and OSPF protocol processing. > > >At 11:39 AM 7/8/2003 +, hebn wrote: > >>layer 2 frame has a MTU of 1500 bytes. > >> how does cisco router propagate router-lsa whose size exceed 1500 > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72048&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
Howard C. Berkowitz wrote: > > At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >The LSA will be fragmented at the IP layer. > > Do you know for certain this is what Cisco's implementation > does? > The OSPF code is aware of the MTU and can build OSPF packets > for it. > I don't think you're really going to simplify it by relieving > it of > the need to keep track of lengths. Can you think of a good way to test it in a lab?? The RFC says that dividing up the updates is recomended over letting IP do the fragmentation and Cisco is generally good at doing things the recommended way usually. Priscilla > > On the other hand, if you send a LSupdate that is at the MTU, > the > receiving router can immediately start checking and installing > it in > the LSDB, without waiting for fragments. This allows some > concurrency > between OSPF packet transmission and OSPF protocol processing. > > >At 11:39 AM 7/8/2003 +, hebn wrote: > >>layer 2 frame has a MTU of 1500 bytes. > >> how does cisco router propagate router-lsa whose size > exceed 1500 > > >bytes(more than 122 links in one area)? > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72047&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 2:42 AM + 7/9/03, Priscilla Oppenheimer wrote: >Howard C. Berkowitz wrote: >> >> At 10:46 PM + 7/8/03, Zsombor Papp wrote: >> >The LSA will be fragmented at the IP layer. >> >> Do you know for certain this is what Cisco's implementation >> does? >> The OSPF code is aware of the MTU and can build OSPF packets >> for it. >> I don't think you're really going to simplify it by relieving >> it of >> the need to keep track of lengths. > >Can you think of a good way to test it in a lab?? Lots of loopback interfaces, with appropriate coding so they don't present as host routes, coupled with small MTUs. Part of the problem in testing will be that any practical configuration doesn't press the limits. IIRC, I ran some calculations a while back that imposed a more stringent limit on the number of routers per segment -- the number you could fit into a Hello packet was around 47, a smaller number than you could type 1 LSAs. > >The RFC says that dividing up the updates is recomended over letting IP do >the fragmentation and Cisco is generally good at doing things the >recommended way usually. The person that I know who wrote most of the _good_ OSPF code has left Cisco, but I'll hunt around on the IETF list and find out if I can find someone who knows definitively. There are a lot of things in OSPF (and, for that matter, BGP) that experience have taught are simply not good ideas in practice. You'll find the latest BGP draft (I think it's 21 now, if it's reached the editor) is both considerably different from the BGP route selection process described in RFC 1771, and is also much closer to what Cisco, Juniper, NextHop/gateD, and Zebra actually do. OSPF will continue to evolve. The classic Dijkstra algorithm won't continue to serve as faster convergence requirements are placed on OSPF. To the best of my knowledge, most implementations save at least some intermediate Dijkstra results, and the trend is to do at least some incremental updating before committing to a full SPF recomputation. > >Priscilla > > >> >> On the other hand, if you send a LSupdate that is at the MTU, >> the >> receiving router can immediately start checking and installing >> it in >> the LSDB, without waiting for fragments. This allows some >> concurrency >> between OSPF packet transmission and OSPF protocol processing. >> >> >At 11:39 AM 7/8/2003 +, hebn wrote: >> >>layer 2 frame has a MTU of 1500 bytes. >> >> how does cisco router propagate router-lsa whose size >> exceed 1500 >> > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72050&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
The original question (as I understood) was about a single LSA that is larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). I can't see how such an LSA could be divided into multiple OSPF messages so the only logical (implementation independent) solution seems to be to fragment the packet at the IP layer. Am I missing something? If you are asking about how LSAs that are individually smaller than 1500 byte are grouped together, then my (moderately educated :) answer is this: IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps packing the LSAs into the same packet as long as their total length is below MAX_OSPF_DATA, the net result being that the size of the IP packet can be up to 1500 bytes (and will in fact be close to it if the individual LSAs are not too big) if there are enough LSAs, regardless of the MTU. So for example if you set the IP MTU on an Ethernet interface to 500 bytes, and you have a large enough OSPF database, then you should see a lot of fragmented OSPF packets, regardless of how big the individual LSAs are. I didn't write the code though, so take all this with a grain of salt. :) Thanks, Zsombor At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >The LSA will be fragmented at the IP layer. > >Do you know for certain this is what Cisco's implementation does? >The OSPF code is aware of the MTU and can build OSPF packets for it. >I don't think you're really going to simplify it by relieving it of >the need to keep track of lengths. > >On the other hand, if you send a LSupdate that is at the MTU, the >receiving router can immediately start checking and installing it in >the LSDB, without waiting for fragments. This allows some concurrency >between OSPF packet transmission and OSPF protocol processing. > > >At 11:39 AM 7/8/2003 +, hebn wrote: > >>layer 2 frame has a MTU of 1500 bytes. > >> how does cisco router propagate router-lsa whose size exceed 1500 > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72055&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF max Router-LSA links [7:72024]
>hebn wrote: >> >> hello,everyone: > >>OSPF use raw socket (datagram) to communicate with peers. In >> general, layer 2 frame has a MTU of 1500 bytes. >>how does cisco router propagate router-lsa whose size exceed >> 1500 bytes(more than 122 links in one area)? > >Well, I don't have a definite answer, but I'll discuss it with >you in the >hopes of lighting a fire under one of the OSPF experts on this >list. Howard? >Chuck? Peter? Where's Pamela when we need her? :-) > >OSPF runs directly above IP. I don't know if that could be called "raw >socket" which is a UNIX thing? My perception is that with >Cisco IOS, OSPF >calls IP with a set of parameters and lets IP handle the rest. So maybe >that's sort of raw. > >I can say this: The OSPF packets I have seen coming out of >Cisco routers >have the IP fragmentation bit set to "May Fragment." This >makes me think >that Cisco's OSPF relies on IP to push the bytes into the >data-link-layer >frame and fragment if necessary. > >The OSPF RFC (RFC 2178) says this: > >"OSPF does not define a way to fragment its protocol packets, >and depends on >IP fragmentation when transmitting packets larger than the >network MTU. If >necessary, the length of OSPF packets can be up to 65,535 >bytes (including >the IP header). The OSPF packet types that are likely to be >large (Database >Description Packets, Link State Request, Link State Update, >and Link State >Acknowledgment packets) can usually be split into several >separate protocol >packets, without loss of functionality. This is recommended; IP >fragmentation should be avoided whenever possible." > >Unfortunately, that's not very clear. It implies that the >recommended method >is for OSPF to split its own protocol packets. But that the >method for doing >this is undefined and that's OK because OSPF can depend on IP to do >fragmentation. > >Cisco routers tell each other their MTU in database >description packets, per >RFC 2178. Until recently, if the routers didn't agree on the MTU, they >wouldn't become adjacent. A recent IOS version supports >telling a router to >ignore the other side's MTU so they can still become adjacent. This is true. I vaguely remember reading some notes from an IETF meeting from one of the developers of OSPF. They were discussing checks for the MTU. Basically OSPF checks whether a neighbor is using the same maximum transimission unit (mtu) on a common interface. This check is performed when neighbors exchange (exchange stage) (DD's) database description packet. If the receiving MTU in the DD packet was higher then the IP MTU configured on the incoming interface, OSPF will not establish an adjacency. The DD packet were dropped. This was done on the DD phase because initially MTU mismatches could cause flooding between 2 neighbors to fail with large LSU's being continually retransmitted. -Mario >That doesn't answer your question, but maybe there are some >hints in the >article that discusse the "ip ospf mtu-ignore" feature here: > >http://www.cisco.com/warp/public/104/12.html > >___ > >Priscilla Oppenheimer >www.priscilla.com > > >> __ > >> >> === >> [EMAIL PROTECTED] (http://bizsite.sina.com.cn) >Report misconduct >and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72059&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
Zsombor Papp wrote: > > The original question (as I understood) was about a single LSA > that is > larger than 1500 bytes (think Type 1 LSA for a router with 200 > interfaces). > I can't see how such an LSA could be divided into multiple OSPF > messages so > the only logical (implementation independent) solution seems to > be to > fragment the packet at the IP layer. Am I missing something? OSPF could send multiple packets. That's what IP RIP would do. It used to be pretty common to see bunches of RIP packets every 30 seconds. Even more common for IPX RIP, (every 60 seconds). > > If you are asking about how LSAs that are individually smaller > than 1500 > byte are grouped together, then my (moderately educated :) > answer is this: > IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 > bytes and > another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs > keeps > packing the LSAs into the same packet as long as their total > length is > below MAX_OSPF_DATA, the net result being that the size of the > IP packet > can be up to 1500 bytes (and will in fact be close to it if the > individual > LSAs are not too big) if there are enough LSAs, regardless of > the MTU. So > for example if you set the IP MTU on an Ethernet interface to > 500 bytes, > and you have a large enough OSPF database, then you should see > a lot of > fragmented OSPF packets, regardless of how big the individual > LSAs are. Thanks for the info. As another example, say that the MTU is 1500 and there is so much info to advertise (links, routers, routes, depending on the type) that it requires more than 1500 bytes. Then OSPF would just send multiple packets, wouldn't it? And there wouldn't be any IP fragmentation? I think that was the original question. According to Howard, if I understood him correctly in his message, that's how Nortel, Bay, Wellfleet do it (send multiple messages). But is that what Cisco does? I think it is what the RFC recommends too when it says this: "The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible." Sorry to beat this to death, but I'm not sure we have an answer yet. Priscilla > > I didn't write the code though, so take all this with a grain > of salt. :) > > Thanks, > > Zsombor > > At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > > >The LSA will be fragmented at the IP layer. > > > >Do you know for certain this is what Cisco's implementation > does? > >The OSPF code is aware of the MTU and can build OSPF packets > for it. > >I don't think you're really going to simplify it by relieving > it of > >the need to keep track of lengths. > > > >On the other hand, if you send a LSupdate that is at the MTU, > the > >receiving router can immediately start checking and installing > it in > >the LSDB, without waiting for fragments. This allows some > concurrency > >between OSPF packet transmission and OSPF protocol processing. > > > > >At 11:39 AM 7/8/2003 +, hebn wrote: > > >>layer 2 frame has a MTU of 1500 bytes. > > >> how does cisco router propagate router-lsa whose size > exceed 1500 > > > >bytes(more than 122 links in one area)? > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72065&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 05:14 PM 7/9/2003 +, Priscilla Oppenheimer wrote: >Zsombor Papp wrote: > > > > The original question (as I understood) was about a single LSA > > that is > > larger than 1500 bytes (think Type 1 LSA for a router with 200 > > interfaces). > > I can't see how such an LSA could be divided into multiple OSPF > > messages so > > the only logical (implementation independent) solution seems to > > be to > > fragment the packet at the IP layer. Am I missing something? > >OSPF could send multiple packets. How would the receiver know that the second packet holds the second half of the LSA whose first half was transmitted in the first packet? OSPF doesn't have a way of coalescing fragments of an LSA, does it? > That's what IP RIP would do. It used to be >pretty common to see bunches of RIP packets every 30 seconds. Even more >common for IPX RIP, (every 60 seconds). RIP doesn't have a concept of LSAs. A good analogy would be to say that RIP could advertise a single prefix distributed into multiple packets, which is not true. > > If you are asking about how LSAs that are individually smaller > > than 1500 > > byte are grouped together, then my (moderately educated :) > > answer is this: > > IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 > > bytes and > > another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > > IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs > > keeps > > packing the LSAs into the same packet as long as their total > > length is > > below MAX_OSPF_DATA, the net result being that the size of the > > IP packet > > can be up to 1500 bytes (and will in fact be close to it if the > > individual > > LSAs are not too big) if there are enough LSAs, regardless of > > the MTU. So > > for example if you set the IP MTU on an Ethernet interface to > > 500 bytes, > > and you have a large enough OSPF database, then you should see > > a lot of > > fragmented OSPF packets, regardless of how big the individual > > LSAs are. > >Thanks for the info. > >As another example, say that the MTU is 1500 and there is so much info to >advertise (links, routers, routes, depending on the type) that it requires >more than 1500 bytes. Then OSPF would just send multiple packets, wouldn't >it? Yes. >And there wouldn't be any IP fragmentation? Unless there is a single LSA larger than 1500 bytes, there wouldn't be any. In case it confused anyone, MAXOSPFPACKETSIZE (ie. 1500 bytes) is *not* the size of the largest OSPF packet that IOS can generate. > I think that was the original question. Well, if the term "router-lsa whose size exceed 1500 bytes" refers to a set of LSAs whose size individually does *not* exceed 1500 bytes (as opposed to a single Type 1 LSA whose size does exceed 1500 bytes), then I misunderstood the question. :) Thanks, Zsombor >According to Howard, if I understood him correctly in his message, that's >how Nortel, Bay, Wellfleet do it (send multiple messages). But is that what >Cisco does? > >I think it is what the RFC recommends too when it says this: "The OSPF >packet types that are likely to be large (Database Description Packets, Link >State Request, Link State Update, and Link State Acknowledgment packets) can >usually be split into several separate protocol packets, without loss of >functionality. This is recommended; IP fragmentation should be avoided >whenever possible." > >Sorry to beat this to death, but I'm not sure we have an answer yet. > >Priscilla > > > > > > I didn't write the code though, so take all this with a grain > > of salt. :) > > > > Thanks, > > > > Zsombor > > > > At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > > >At 10:46 PM + 7/8/03, Zsombor Papp wrote: > > > >The LSA will be fragmented at the IP layer. > > > > > >Do you know for certain this is what Cisco's implementation > > does? > > >The OSPF code is aware of the MTU and can build OSPF packets > > for it. > > >I don't think you're really going to simplify it by relieving > > it of > > >the need to keep track of lengths. > > > > > >On the other hand, if you send a LSupdate that is at the MTU, > > the > > >receiving router can immediately start checking and installing > > it in > > >the LSDB, without waiting for fragments. This allows some > > concurrency > > >between OSPF packet transmission and OSPF protocol processing. > > > > > > >At 11:39 AM 7/8/2003 +, hebn wrote: > > > >>layer 2 frame has a MTU of 1500 bytes. > > > >> how does cisco router propagate router-lsa whose size > > exceed 1500 > > > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72068&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 12:43 PM + 7/9/03, Zsombor Papp wrote: >The original question (as I understood) was about a single LSA that is >larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). >I can't see how such an LSA could be divided into multiple OSPF messages so >the only logical (implementation independent) solution seems to be to >fragment the packet at the IP layer. Am I missing something? I missed the point that the LSA was for the same router. Without testing it, however, I don't immediately see why it wouldn't work to have multiple LSAs for the same router, as long as no prefixes were duplicated. Certainly, you send out a new type 2 when an additional prefix activates -- I don't immediately see why you couldn't send out a new type 1 with the additional new prefix. Neither are in an existing LSDB, so they shouldn't purge anything. Another argument about fragmentation hasn't been discussed. Consider Hello packets. IIRC, about 47 router entries can fit into an OSPF hello packet with a 1500 byte MTU. Consider the timing complexities of waiting to defragment before you can tell if another router is alive. Even scarier is if the load were heavy enough (unlikely, but possible) that you might hit the next hello update interval before you had finished sending (or at least processing) all the segments. > >If you are asking about how LSAs that are individually smaller than 1500 >byte are grouped together, then my (moderately educated :) answer is this: >IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and >another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - >IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps >packing the LSAs into the same packet as long as their total length is >below MAX_OSPF_DATA, the net result being that the size of the IP packet >can be up to 1500 bytes (and will in fact be close to it if the individual >LSAs are not too big) if there are enough LSAs, regardless of the MTU. So >for example if you set the IP MTU on an Ethernet interface to 500 bytes, >and you have a large enough OSPF database, then you should see a lot of >fragmented OSPF packets, regardless of how big the individual LSAs are. > >I didn't write the code though, so take all this with a grain of salt. :) > >Thanks, > >Zsombor > >At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: >>At 10:46 PM + 7/8/03, Zsombor Papp wrote: >> >The LSA will be fragmented at the IP layer. >> >>Do you know for certain this is what Cisco's implementation does? >>The OSPF code is aware of the MTU and can build OSPF packets for it. >>I don't think you're really going to simplify it by relieving it of >>the need to keep track of lengths. >> >>On the other hand, if you send a LSupdate that is at the MTU, the >>receiving router can immediately start checking and installing it in >>the LSDB, without waiting for fragments. This allows some concurrency >>between OSPF packet transmission and OSPF protocol processing. >> >> >At 11:39 AM 7/8/2003 +, hebn wrote: >> >>layer 2 frame has a MTU of 1500 bytes. >> >> how does cisco router propagate router-lsa whose size exceed 1500 > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72074&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
Howard C. Berkowitz wrote: > > At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single LSA > that is > >larger than 1500 bytes (think Type 1 LSA for a router with 200 > interfaces). > >I can't see how such an LSA could be divided into multiple > OSPF messages so > >the only logical (implementation independent) solution seems > to be to > >fragment the packet at the IP layer. Am I missing something? > > I missed the point that the LSA was for the same router. > Without > testing it, however, I don't immediately see why it wouldn't > work to > have multiple LSAs for the same router, as long as no prefixes > were > duplicated. Are you saying the router could send out one Link State Advertisement saying this router has link 1, 2, 3, etc. etc., for example. And then send out another LSA, saying this same router has link 101, 102, 103, etc.? That should work I would think, unless the recipient thought it was supposed to replace the old one with this new one. But that doesn't seem to be what Cisco does. I couldn't easily try the Hello with lots of neighbors in it that you mention below, but I did try a single router with gobs of loopbacks that it advertises to another router in a Type 1 LSA. It sends the info in one oversized message, that the IP layer fragmented, as Zsombor said it would. I had about 140 loopbacks all part of OSPF Area 0. The sending router sent this to another router in Area 0. The sending router's IP layer put it in two IP packets, one with 1500 bytes, and one with a few hundred. IP did the fragmentation. OSPF didn't divide it up. But I agree that it shouldn't have to work that way?? But it does, and I *think* that was the original question. I said that before, but now I'm much more sure that this was what the original poster wanted to know. :-) Priscilla >Certainly, you send out a new type 2 when an > additional > prefix activates -- I don't immediately see why you couldn't > send out > a new type 1 with the additional new prefix. Neither are in an > existing LSDB, so they shouldn't purge anything. > > Another argument about fragmentation hasn't been discussed. > Consider > Hello packets. IIRC, about 47 router entries can fit into an > OSPF > hello packet with a 1500 byte MTU. Consider the timing > complexities > of waiting to defragment before you can tell if another router > is > alive. Even scarier is if the load were heavy enough > (unlikely, but > possible) that you might hit the next hello update interval > before > you had finished sending (or at least processing) all the > segments. > > > > >If you are asking about how LSAs that are individually smaller > than 1500 > >byte are grouped together, then my (moderately educated :) > answer is this: > >IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 > bytes and > >another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > >IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the > LSAs keeps > >packing the LSAs into the same packet as long as their total > length is > >below MAX_OSPF_DATA, the net result being that the size of the > IP packet > >can be up to 1500 bytes (and will in fact be close to it if > the individual > >LSAs are not too big) if there are enough LSAs, regardless of > the MTU. So > >for example if you set the IP MTU on an Ethernet interface to > 500 bytes, > >and you have a large enough OSPF database, then you should see > a lot of > >fragmented OSPF packets, regardless of how big the individual > LSAs are. > > > >I didn't write the code though, so take all this with a grain > of salt. :) > > > >Thanks, > > > >Zsombor > > > >At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > >>At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >> >The LSA will be fragmented at the IP layer. > >> > >>Do you know for certain this is what Cisco's implementation > does? > >>The OSPF code is aware of the MTU and can build OSPF packets > for it. > >>I don't think you're really going to simplify it by relieving > it of > >>the need to keep track of lengths. > >> > >>On the other hand, if you send a LSupdate that is at the MTU, > the > >>receiving router can immediately start checking and > installing it in > >>the LSDB, without waiting for fragments. This allows some > concurrency > >>between OSPF packet transmission and OSPF protocol processing. > >> > >> >At 11:39 AM 7/8/2003 +, hebn wrote: > >> >>layer 2 frame has a MTU of 1500 bytes. > >> >> how does cisco router propagate router-lsa whose > size exceed 1500 > > > >bytes(more than 122 links in one area)? > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72076&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: >At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single LSA that is > >larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). > >I can't see how such an LSA could be divided into multiple OSPF messages so > >the only logical (implementation independent) solution seems to be to > >fragment the packet at the IP layer. Am I missing something? > >I missed the point that the LSA was for the same router. Without >testing it, however, I don't immediately see why it wouldn't work to >have multiple LSAs for the same router, I am not sure what you mean by "multiple LSAs for the same router", but if you mean "multiple type 1 LSAs originated by the same router", then my answer is "because it is impossible to distinguish them". If I am mistaken here, then I would like to understand how such LSAs can be distinguished. > as long as no prefixes were >duplicated. Certainly, you send out a new type 2 when an additional >prefix activates What is "prefix" in this context? Type 2 LSAs describe the routers attached to a network. Are you saying that if an additional router comes up on that network, then the DR should send only an "incremental" Type 2 LSA, containing a single entry, describing the new router that just came up? Which bit in the OSPF packet will let the receiver router know that this is an "incremental" LSA, not a replacement (because all the other routers died and a new one just came up)? > -- I don't immediately see why you couldn't send out >a new type 1 with the additional new prefix. Neither are in an >existing LSDB, so they shouldn't purge anything. How do you mean "neither are in an existing LSDB"? If an OSPF router receives two Type 1 LSAs, both originated by the same router, how will it differentiate between the two so that it can install both of them into the LSDB? IMHO the receiver will try to guess which one of the two is newer and install only the newer one. In fact it is not even correct to think about these two LSAs as "two LSAs"; they are two instances of the same LSA. >Another argument about fragmentation hasn't been discussed. Consider >Hello packets. IIRC, about 47 router entries can fit into an OSPF >hello packet with a 1500 byte MTU. Consider the timing complexities >of waiting to defragment before you can tell if another router is >alive. Even scarier is if the load were heavy enough (unlikely, but >possible) that you might hit the next hello update interval before >you had finished sending (or at least processing) all the segments. I think I am missing the point here. Yes, fragmentation is not good, but there are circumstances when you have to live with it. Thanks, Zsombor > > > >If you are asking about how LSAs that are individually smaller than 1500 > >byte are grouped together, then my (moderately educated :) answer is this: > >IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and > >another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - > >IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps > >packing the LSAs into the same packet as long as their total length is > >below MAX_OSPF_DATA, the net result being that the size of the IP packet > >can be up to 1500 bytes (and will in fact be close to it if the individual > >LSAs are not too big) if there are enough LSAs, regardless of the MTU. So > >for example if you set the IP MTU on an Ethernet interface to 500 bytes, > >and you have a large enough OSPF database, then you should see a lot of > >fragmented OSPF packets, regardless of how big the individual LSAs are. > > > >I didn't write the code though, so take all this with a grain of salt. :) > > > >Thanks, > > > >Zsombor > > > >At 12:40 AM 7/9/2003 +, Howard C. Berkowitz wrote: > >>At 10:46 PM + 7/8/03, Zsombor Papp wrote: > >> >The LSA will be fragmented at the IP layer. > >> > >>Do you know for certain this is what Cisco's implementation does? > >>The OSPF code is aware of the MTU and can build OSPF packets for it. > >>I don't think you're really going to simplify it by relieving it of > >>the need to keep track of lengths. > >> > >>On the other hand, if you send a LSupdate that is at the MTU, the > >>receiving router can immediately start checking and installing it in > >>the LSDB, without waiting for fragments. This allows some concurrency > >>between OSPF packet transmission and OSPF protocol processing. > >> > >> >At 11:39 AM 7/8/2003 +, hebn wrote: > >> >>layer 2 frame has a MTU of 1500 bytes. > >> >> how does cisco router propagate router-lsa whose size exceed 1500 > > > >bytes(more than 122 links in one area)? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72078&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosu
Re: OSPF max Router-LSA links [7:72024]
At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: > >Hello packets. IIRC, about 47 router entries can fit into an OSPF > >hello packet with a 1500 byte MTU. Consider the timing complexities Btw, neighbors are identified by their 4-byte router ID, so it would take more than 350 neighbors to fill up a 1500 byte packet. I guess it is rather academical to ask what would happen to the hello packet if we had more than 350 neighbors on a single interface :), but I briefly looked at the code and I think it would be fragmented at the IP level. Thanks, Zsombor Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72079&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: >At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: >>At 12:43 PM + 7/9/03, Zsombor Papp wrote: >>>The original question (as I understood) was about a single LSA that is >>>larger than 1500 bytes (think Type 1 LSA for a router with 200 interfaces). >>>I can't see how such an LSA could be divided into multiple OSPF messages so >>>the only logical (implementation independent) solution seems to be to >>>fragment the packet at the IP layer. Am I missing something? >> >>I missed the point that the LSA was for the same router. Without >>testing it, however, I don't immediately see why it wouldn't work to >>have multiple LSAs for the same router, > >I am not sure what you mean by "multiple LSAs for the same router", >but if you mean "multiple type 1 LSAs originated by the same >router", then my answer is "because it is impossible to distinguish >them". If I am mistaken here, then I would like to understand how >such LSAs can be distinguished. The relationship between type 1 and type 2 is essential in developing the SPF algorithm. If you think of the LSDB entries for both, they are trees. The type 1 bas the router ID as root and the attached interface IDs/prefixes as leaves. The type 2 has an interface ID/prefix as root and routers connected to that prefix as leaves. > >> as long as no prefixes were >>duplicated. Certainly, you send out a new type 2 when an additional >>prefix activates > >What is "prefix" in this context? Type 2 LSAs describe the routers >attached to a network. Are you saying that if an additional router >comes up on that network, then the DR should send only an >"incremental" Type 2 LSA, containing a single entry, describing the >new router that just came up? Which bit in the OSPF packet will let >the receiver router know that this is an "incremental" LSA, not a >replacement (because all the other routers died and a new one just >came up)? The receiving router knows the sending router is still up, at least through the hello mechanism. One of the fundamental points of using hellos is so you know if the originating router has gone down. Since you know from context it's still up, you don't need an incremental flag -- you know the update is supplemental information. Remember also that you can withdraw routes without killing the whole LSDB entry. > >> -- I don't immediately see why you couldn't send out >>a new type 1 with the additional new prefix. Neither are in an >>existing LSDB, so they shouldn't purge anything. > >How do you mean "neither are in an existing LSDB"? If an OSPF router >receives two Type 1 LSAs, both originated by the same router, how >will it differentiate between the two so that it can install both of >them into the LSDB? IMHO the receiver will try to guess which one of >the two is newer and install only the newer one. In fact it is not >even correct to think about these two LSAs as "two LSAs"; they are >two instances of the same LSA. Think not of the transmitted LSAs but its entries. You can have updates on existing information, or changes to the basic topology conveyed (such as a new interface coming up). That doesn't need a new LSA. Look at it this way: LSUpdates are encodings of information for transmission. The decision to install information in the LSDB is done after the packet is parsed into its components. > >>Another argument about fragmentation hasn't been discussed. Consider >>Hello packets. IIRC, about 47 router entries can fit into an OSPF >>hello packet with a 1500 byte MTU. Consider the timing complexities >>of waiting to defragment before you can tell if another router is >>alive. Even scarier is if the load were heavy enough (unlikely, but >>possible) that you might hit the next hello update interval before >>you had finished sending (or at least processing) all the segments. > >I think I am missing the point here. Yes, fragmentation is not good, >but there are circumstances when you have to live with it. > >Thanks, > >Zsombor > >> > >>>If you are asking about how LSAs that are individually smaller than 1500 >> >byte are grouped together, then my (moderately educated :) answer is this: >>>IOS defines a constant called MAXOSPFPACKETSIZE to be 1500 bytes and >>>another constant called MAX_OSPF_DATA to be MAXOSPFPACKETSIZE - >>>IPHEADERBYTES - OSPF_HDR_SIZE. The code that transmits the LSAs keeps >>>packing the LSAs into the same packet as long as their total length is >>>below MAX_OSPF_DATA, the net result being that the size of the IP packet >>>can be up to 1500 bytes (and will in fact be close to it if the individual >>>LSAs are not too big) if there are enough LSAs, regardless of the MTU. So >>>for example if you set the IP MTU on an Ethernet interface to 500 bytes, >>>and you have a large enough OSPF database, then you should see a lot of >>>fragmented OSPF packets, regardless of how big the individual LSAs are. >>> >>>I didn't write the code though, so take
Re: OSPF max Router-LSA links [7:72024]
At 5:48 AM -0700 7/10/03, Zsombor Papp wrote: >I guess our views on OSPF are slightly different. > >I will now release the stage to the next "how to increase the value >of the CCIE certification" thread... :) > >Thanks, > >Zsombor Zsombor, I appreciate the discussion. I've been running at low speed due to a leg infection, but will talk to some developers and reread both 2328 and some of the OSPF working group archives. Will get back when I have useful information. ANYTHING but another one of THOSE threads...maybe a discussion on what happens to bits routed to the null interface? Is there a true astronomical black hole into which they are dumped? Alternatively, might there be a bit dump somewhere in Northern New Jersey, which someday may explode? > >At 03:13 AM 7/10/2003 +, Howard C. Berkowitz wrote: >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: >>>At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: At 12:43 PM + 7/9/03, Zsombor Papp wrote: >The original question (as I understood) was about a single LSA that is >larger than 1500 bytes (think Type 1 LSA for a router with 200 >>interfaces). >I can't see how such an LSA could be divided into multiple OSPF messages >>so >the only logical (implementation independent) solution seems to be to >fragment the packet at the IP layer. Am I missing something? I missed the point that the LSA was for the same router. Without testing it, however, I don't immediately see why it wouldn't work to have multiple LSAs for the same router, >>> >>>I am not sure what you mean by "multiple LSAs for the same router", >>>but if you mean "multiple type 1 LSAs originated by the same >>>router", then my answer is "because it is impossible to distinguish >>>them". If I am mistaken here, then I would like to understand how >>>such LSAs can be distinguished. >> >>The relationship between type 1 and type 2 is essential in developing >>the SPF algorithm. If you think of the LSDB entries for both, they >>are trees. The type 1 bas the router ID as root and the attached >>interface IDs/prefixes as leaves. The type 2 has an interface >>ID/prefix as root and routers connected to that prefix as leaves. >> >>> as long as no prefixes were duplicated. Certainly, you send out a new type 2 when an additional prefix activates >>> >>>What is "prefix" in this context? Type 2 LSAs describe the routers >>>attached to a network. Are you saying that if an additional router >>>comes up on that network, then the DR should send only an >>>"incremental" Type 2 LSA, containing a single entry, describing the >>>new router that just came up? Which bit in the OSPF packet will let >>>the receiver router know that this is an "incremental" LSA, not a >>>replacement (because all the other routers died and a new one just >>>came up)? >> >>The receiving router knows the sending router is still up, at least >>through the hello mechanism. One of the fundamental points of using >>hellos is so you know if the originating router has gone down. Since >>you know from context it's still up, you don't need an incremental >>flag -- you know the update is supplemental information. >> >>Remember also that you can withdraw routes without killing the whole >>LSDB entry. >> >>> -- I don't immediately see why you couldn't send out a new type 1 with the additional new prefix. Neither are in an existing LSDB, so they shouldn't purge anything. >>> >>>How do you mean "neither are in an existing LSDB"? If an OSPF router >>>receives two Type 1 LSAs, both originated by the same router, how >>>will it differentiate between the two so that it can install both of >>>them into the LSDB? IMHO the receiver will try to guess which one of >>>the two is newer and install only the newer one. In fact it is not >>>even correct to think about these two LSAs as "two LSAs"; they are >>>two instances of the same LSA. >> >>Think not of the transmitted LSAs but its entries. You can have >>updates on existing information, or changes to the basic topology >>conveyed (such as a new interface coming up). That doesn't need a new >>LSA. >> >>Look at it this way: LSUpdates are encodings of information for >>transmission. The decision to install information in the LSDB is >>done after the packet is parsed into its components. >> >>> Another argument about fragmentation hasn't been discussed. Consider Hello packets. IIRC, about 47 router entries can fit into an OSPF hello packet with a 1500 byte MTU. Consider the timing complexities of waiting to defragment before you can tell if another router is alive. Even scarier is if the load were heavy enough (unlikely, but possible) that you might hit the next hello update interval before you had finished sending (or at least processing) all the segments. >>> >>>I think I am missing the point here. Yes, fragmentation is not good, >>>but there are circumstances when you have to live with it. >>> >>>Than
Re: OSPF max Router-LSA links [7:72024]
At 07:41 PM 7/10/2003 +, Howard C. Berkowitz wrote: >At 5:48 AM -0700 7/10/03, Zsombor Papp wrote: > >I guess our views on OSPF are slightly different. > > > >I will now release the stage to the next "how to increase the value > >of the CCIE certification" thread... :) > > > >Thanks, > > > >Zsombor > >Zsombor, I appreciate the discussion. I've been running at low speed >due to a leg infection, but will talk to some developers and reread >both 2328 and some of the OSPF working group archives. Will get back >when I have useful information. Sounds good. Thanks, Zsombor >ANYTHING but another one of THOSE threads...maybe a discussion on >what happens to bits routed to the null interface? Is there a true >astronomical black hole into which they are dumped? Alternatively, >might there be a bit dump somewhere in Northern New Jersey, which >someday may explode? > > > > >At 03:13 AM 7/10/2003 +, Howard C. Berkowitz wrote: > >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: > >>>At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: > At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single LSA that is > >larger than 1500 bytes (think Type 1 LSA for a router with 200 > >>interfaces). > >I can't see how such an LSA could be divided into multiple OSPF messages > >>so > >the only logical (implementation independent) solution seems to be to > >fragment the packet at the IP layer. Am I missing something? > > I missed the point that the LSA was for the same router. Without > testing it, however, I don't immediately see why it wouldn't work to > have multiple LSAs for the same router, > >>> > >>>I am not sure what you mean by "multiple LSAs for the same router", > >>>but if you mean "multiple type 1 LSAs originated by the same > >>>router", then my answer is "because it is impossible to distinguish > >>>them". If I am mistaken here, then I would like to understand how > >>>such LSAs can be distinguished. > >> > >>The relationship between type 1 and type 2 is essential in developing > >>the SPF algorithm. If you think of the LSDB entries for both, they > >>are trees. The type 1 bas the router ID as root and the attached > >>interface IDs/prefixes as leaves. The type 2 has an interface > >>ID/prefix as root and routers connected to that prefix as leaves. > >> > >>> > as long as no prefixes were > duplicated. Certainly, you send out a new type 2 when an additional > prefix activates > >>> > >>>What is "prefix" in this context? Type 2 LSAs describe the routers > >>>attached to a network. Are you saying that if an additional router > >>>comes up on that network, then the DR should send only an > >>>"incremental" Type 2 LSA, containing a single entry, describing the > >>>new router that just came up? Which bit in the OSPF packet will let > >>>the receiver router know that this is an "incremental" LSA, not a > >>>replacement (because all the other routers died and a new one just > >>>came up)? > >> > >>The receiving router knows the sending router is still up, at least > >>through the hello mechanism. One of the fundamental points of using > >>hellos is so you know if the originating router has gone down. Since > >>you know from context it's still up, you don't need an incremental > >>flag -- you know the update is supplemental information. > >> > >>Remember also that you can withdraw routes without killing the whole > >>LSDB entry. > >> > >>> > -- I don't immediately see why you couldn't send out > a new type 1 with the additional new prefix. Neither are in an > existing LSDB, so they shouldn't purge anything. > >>> > >>>How do you mean "neither are in an existing LSDB"? If an OSPF router > >>>receives two Type 1 LSAs, both originated by the same router, how > >>>will it differentiate between the two so that it can install both of > >>>them into the LSDB? IMHO the receiver will try to guess which one of > >>>the two is newer and install only the newer one. In fact it is not > >>>even correct to think about these two LSAs as "two LSAs"; they are > >>>two instances of the same LSA. > >> > >>Think not of the transmitted LSAs but its entries. You can have > >>updates on existing information, or changes to the basic topology > >>conveyed (such as a new interface coming up). That doesn't need a new > >>LSA. > >> > >>Look at it this way: LSUpdates are encodings of information for > >>transmission. The decision to install information in the LSDB is > >>done after the packet is parsed into its components. > >> > >>> > Another argument about fragmentation hasn't been discussed. Consider > Hello packets. IIRC, about 47 router entries can fit into an OSPF > hello packet with a 1500 byte MTU. Consider the timing complexities > of waiting to defragment before you can tell if another router is > alive. Even scarier is if the load were heavy enough (unlikely, but > possible) that yo
Re: OSPF max Router-LSA links [7:72024]
Howard C. Berkowitz wrote: > > At 5:48 AM -0700 7/10/03, Zsombor Papp wrote: > >I guess our views on OSPF are slightly different. > > > >I will now release the stage to the next "how to increase the > value > >of the CCIE certification" thread... :) > > > >Thanks, > > > >Zsombor > > Zsombor, I appreciate the discussion. I've been running at low > speed > due to a leg infection, but will talk to some developers and > reread > both 2328 and some of the OSPF working group archives. Will get > back > when I have useful information. > > ANYTHING but another one of THOSE threads... I learned a lot from the discussion. I'm still pondering the relationship between Type 1 and Type 2 LSAs and their tree topologies. And I'm pondering whether OSPF LSAs really need to be idempotent. I've always wanted to use that word in a sentence. :-) I hope your leg gets better and that the cats aren't sitting on it! :-) Priscilla > maybe a discussion > on > what happens to bits routed to the null interface? Is there a > true > astronomical black hole into which they are dumped? > Alternatively, > might there be a bit dump somewhere in Northern New Jersey, > which > someday may explode? > > > > >At 03:13 AM 7/10/2003 +, Howard C. Berkowitz wrote: > >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: > >>>At 11:07 PM 7/9/2003 +, Howard C. Berkowitz wrote: > At 12:43 PM + 7/9/03, Zsombor Papp wrote: > >The original question (as I understood) was about a single > LSA that is > >larger than 1500 bytes (think Type 1 LSA for a router with > 200 > >>interfaces). > >I can't see how such an LSA could be divided into multiple > OSPF messages > >>so > >the only logical (implementation independent) solution > seems to be to > >fragment the packet at the IP layer. Am I missing > something? > > I missed the point that the LSA was for the same router. > Without > testing it, however, I don't immediately see why it > wouldn't work to > have multiple LSAs for the same router, > >>> > >>>I am not sure what you mean by "multiple LSAs for the same > router", > >>>but if you mean "multiple type 1 LSAs originated by the same > >>>router", then my answer is "because it is impossible to > distinguish > >>>them". If I am mistaken here, then I would like to > understand how > >>>such LSAs can be distinguished. > >> > >>The relationship between type 1 and type 2 is essential in > developing > >>the SPF algorithm. If you think of the LSDB entries for > both, they > >>are trees. The type 1 bas the router ID as root and the > attached > >>interface IDs/prefixes as leaves. The type 2 has an interface > >>ID/prefix as root and routers connected to that prefix as > leaves. > >> > >>> > as long as no prefixes were > duplicated. Certainly, you send out a new type 2 when an > additional > prefix activates > >>> > >>>What is "prefix" in this context? Type 2 LSAs describe the > routers > >>>attached to a network. Are you saying that if an additional > router > >>>comes up on that network, then the DR should send only an > >>>"incremental" Type 2 LSA, containing a single entry, > describing the > >>>new router that just came up? Which bit in the OSPF packet > will let > >>>the receiver router know that this is an "incremental" LSA, > not a > >>>replacement (because all the other routers died and a new > one just > >>>came up)? > >> > >>The receiving router knows the sending router is still up, at > least > >>through the hello mechanism. One of the fundamental points of > using > >>hellos is so you know if the originating router has gone > down. Since > >>you know from context it's still up, you don't need an > incremental > >>flag -- you know the update is supplemental information. > >> > >>Remember also that you can withdraw routes without killing > the whole > >>LSDB entry. > >> > >>> > -- I don't immediately see why you couldn't send out > a new type 1 with the additional new prefix. Neither are in > an > existing LSDB, so they shouldn't purge anything. > >>> > >>>How do you mean "neither are in an existing LSDB"? If an > OSPF router > >>>receives two Type 1 LSAs, both originated by the same > router, how > >>>will it differentiate between the two so that it can install > both of > >>>them into the LSDB? IMHO the receiver will try to guess > which one of > >>>the two is newer and install only the newer one. In fact it > is not > >>>even correct to think about these two LSAs as "two LSAs"; > they are > >>>two instances of the same LSA. > >> > >>Think not of the transmitted LSAs but its entries. You can > have > >>updates on existing information, or changes to the basic > topology > >>conveyed (such as a new interface coming up). That doesn't > need a new > >>LSA. > >> > >>Look at it this way: LSUpdates are encodings of information > for > >>transmission. The decision to install information in the > LSDB is > >>done after the packet is parsed into its components. > >> > >>> >
Re: OSPF max Router-LSA links [7:72024]
""hebn"" wrote in message news:[EMAIL PROTECTED] > layer 2 frame has a MTU of 1500 bytes. >how does cisco router propagate router-lsa whose size exceed 1500 > bytes(more than 122 links in one area)? I've browsed through the other responses, and I did not see this particular piece of information, but it being late perhaps I missed it. I understand this question to mean "what if there are lots of routes, so many that the LSA would end up larger than the MTU" As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, beginning on page 194 of said document, OSPF knows the link MTU, and would contruct it's LSA's based on that information. Within the database description packet, there is the "M" bit, which indicates whether or not there are additional database description packets following. The receiving router would see that a particular DDP M bit is marked "on" and would expect more. When the last DDP is received ( M bit marked "off" ) then the current DD sequence number becomes the reference number for the link state database. Future LSA's would have to have a higher sequence number in order to be considered updates. Howard? I "think" this answers the original question, although one never can tell. -Hem- > __ > > === > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72173&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
At 07:54 AM 7/12/2003 +, Hemingway wrote: >""hebn"" wrote in message >news:[EMAIL PROTECTED] > > layer 2 frame has a MTU of 1500 bytes. > >how does cisco router propagate router-lsa whose size exceed 1500 > > bytes(more than 122 links in one area)? > > >I've browsed through the other responses, and I did not see this particular >piece of information, but it being late perhaps I missed it. I understand >this question to mean "what if there are lots of routes, so many that the >LSA would end up larger than the MTU" For the sake of clarity: OSPF, being a link-state protocol, doesn't advertise routes, and the size of the LSAs doesn't depend on the number of routes. Apologies if this is obvious; from the above statement and based on the previous discussion I thought it might not be. I would also like to mention that LSAs are not exchanged only between neighbors, they are flooded throughout the OSPF domain (depending on type and area configuration, as I am sure everybody knows :). I think this simple fact has far-reaching consequences as far as the nature and handling of LSAs are concerned. >As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, beginning >on page 194 of said document, OSPF knows the link MTU, and would contruct >it's LSA's based on that information. My understanding is that the only thing that influences how the LSAs are constructed is the topology. I would be curious to see where the RFC says otherwise. LSAs are not equivalent to DD packets. (And FWIW, page numbers in the RFCs are on the bottom of the pages... :) As for the OSPF *packets* being constructed based on MTU, that is surely a possibility. The IOS *implementation* however doesn't care about the MTU, as far as I can tell. > Within the database description >packet, there is the "M" bit, which indicates whether or not there are >additional database description packets following. > >The receiving router would see that a particular DDP M bit is marked "on" >and would expect more. When the last DDP is received ( M bit marked "off" ) >then the current DD sequence number becomes the reference number for the >link state database. Future LSA's would have to have a higher sequence >number in order to be considered updates. Which part of the RFC says that the DD sequence numbers have something to do with the identification of LSAs? How will this identification method work if the same (instance of an) LSA reaches the router from two directions (see flooding)? IMHO, DDPs constitute the transport mechanism, while LSAs are the data to be transported, so what you are saying above is alike to claiming that, for example, web pages are identified by TCP sequence numbers. Thanks, Zsombor >Howard? > >I "think" this answers the original question, although one never can tell. > >-Hem- > > > > > > __ > > > > === > > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72184&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF max Router-LSA links [7:72024]
""Zsombor Papp"" wrote in message news:[EMAIL PROTECTED] > At 07:54 AM 7/12/2003 +, Hemingway wrote: > >""hebn"" wrote in message > >news:[EMAIL PROTECTED] > > > layer 2 frame has a MTU of 1500 bytes. > > >how does cisco router propagate router-lsa whose size exceed 1500 > > > bytes(more than 122 links in one area)? > > > > > >I've browsed through the other responses, and I did not see this particular > >piece of information, but it being late perhaps I missed it. I understand > >this question to mean "what if there are lots of routes, so many that the > >LSA would end up larger than the MTU" > > For the sake of clarity: OSPF, being a link-state protocol, doesn't > advertise routes, and the size of the LSAs doesn't depend on the number of > routes. Apologies if this is obvious; from the above statement and based on > the previous discussion I thought it might not be. well, sure, but it advetises something, and those somethings end up in routing tables, correct? :-> rereading after a good night's sleep plus another stimulating afternoon on my current remodeling project, I see that I misunderstood the original question. Still, this remains an interesting topic for conversation. ( I gotta get a life ) > > I would also like to mention that LSAs are not exchanged only between > neighbors, they are flooded throughout the OSPF domain (depending on type > and area configuration, as I am sure everybody knows :). I think this > simple fact has far-reaching consequences as far as the nature and handling > of LSAs are concerned. > > >As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, beginning > >on page 194 of said document, OSPF knows the link MTU, and would contruct > >it's LSA's based on that information. > > My understanding is that the only thing that influences how the LSAs are > constructed is the topology. I would be curious to see where the RFC says > otherwise. LSAs are not equivalent to DD packets. IIRC, the RFC's state the result, but do not necessarily describe how the result is to be obtained. Not having access to the code or to the programmers, I can't say what is or is not done. I'm speculating that the MTU information is available, and it would, to me at least, not be that difficult to construct LSA's or DDP's such that packet fragmentation does not have to occur. (And FWIW, page numbers > in the RFCs are on the bottom of the pages... :) that certainly explains why I have a hard time finding things. looking at large text files on screen is difficult for these old eyes :-> > > As for the OSPF *packets* being constructed based on MTU, that is surely a > possibility. The IOS *implementation* however doesn't care about the MTU, > as far as I can tell. I've never worked in a network with enough routes to know. I certainly can't duplicate that in my home lab. or rather, I really have better things to do :-> > > > Within the database description > >packet, there is the "M" bit, which indicates whether or not there are > >additional database description packets following. > > > >The receiving router would see that a particular DDP M bit is marked "on" > >and would expect more. When the last DDP is received ( M bit marked "off" ) > >then the current DD sequence number becomes the reference number for the > >link state database. Future LSA's would have to have a higher sequence > >number in order to be considered updates. > > Which part of the RFC says that the DD sequence numbers have something to > do with the identification of LSAs? How will this identification method > work if the same (instance of an) LSA reaches the router from two > directions (see flooding)? well, I guess I'm being less than rigorous about my terminology. but the sequence number is part of the "authentication" process, isn't it. if a router receives a DDP with a lower sequence number than that which is current in it's OSPF database, the DDR is rejected, is it not? I see that I'm tending to mix my DDP's and my LSA's, although a DDP contains any number of LSA's. So it states on page 196 > > IMHO, DDPs constitute the transport mechanism, while LSAs are the data to > be transported, so what you are saying above is alike to claiming that, for > example, web pages are identified by TCP sequence numbers. sorry for my sloppy terminology. that's what happens when attemptinh intelligent thought when tired from to much whatever.. > > Thanks, > > Zsombor > > > >Howard? > > > >I "think" this answers the original question, although one never can tell. > > > >-Hem- > > > > > > > > > > > __ > > > > > > === > > > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72189&t=72024 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondis
Re: OSPF max Router-LSA links [7:72024]
At 10:15 PM 7/12/2003 +, Hemingway wrote: >""Zsombor Papp"" wrote in message >news:[EMAIL PROTECTED] > > At 07:54 AM 7/12/2003 +, Hemingway wrote: > > >""hebn"" wrote in message > > >news:[EMAIL PROTECTED] > > > > layer 2 frame has a MTU of 1500 bytes. > > > >how does cisco router propagate router-lsa whose size exceed 1500 > > > > bytes(more than 122 links in one area)? > > > > > > > > >I've browsed through the other responses, and I did not see this >particular > > >piece of information, but it being late perhaps I missed it. I understand > > >this question to mean "what if there are lots of routes, so many that the > > >LSA would end up larger than the MTU" > > > > For the sake of clarity: OSPF, being a link-state protocol, doesn't > > advertise routes, and the size of the LSAs doesn't depend on the number of > > routes. Apologies if this is obvious; from the above statement and based >on > > the previous discussion I thought it might not be. > > >well, sure, but it advetises something, and those somethings end up in >routing tables, correct? :-> Sure. The point I was trying to make is that this information flow is not bi-directional: the information in the LSAs will be transformed into routes and those routes will be installed into the routing table, however the LSAs sent out by a router are not based on the routes installed into the routing table. Consequently there is no close relationship between the number of routes and the size of the individual LSAs. > > >As I read the RFC ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt, >beginning > > >on page 194 of said document, OSPF knows the link MTU, and would contruct > > >it's LSA's based on that information. > > > > My understanding is that the only thing that influences how the LSAs are > > constructed is the topology. I would be curious to see where the RFC says > > otherwise. LSAs are not equivalent to DD packets. > >IIRC, the RFC's state the result, but do not necessarily describe how the >result is to be obtained. Not having access to the code or to the >programmers, I can't say what is or is not done. I'm speculating that the >MTU information is available, and it would, to me at least, not be that >difficult to construct LSA's or DDP's such that packet fragmentation does >not have to occur. I think we are discussing a theoretical question, not the implementation, so all you need to have access to is the RFC. I claim that it is sometimes impossible to avoid IP-level fragmentation, regardless of how big your MTU or how good your OSPF implementation is. Specifically, if a router has a large enough number of interfaces in the same OSPF area, then that router will have to generate a huge (type 1) LSA, and that LSA (more exactly *any* LSA, but let's focus on a specific example) can be fragmented only at the IP layer. If you disagree, then please describe how your OSPF implementation will generate two LSAs that are individually smaller than the MTU, and that my (RFC2328 compliant) OSPF implementation must understand (and recognize the second one as an "extension" to the first). I would start at the top of Page 116, where it says: "The LSA header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the LSA." Based on this, if my OSPF implementation receives two LSAs, both having the same LS type (1), Link State ID (your router's OSPF ID), and Advertising Router (again, your router's OSPF ID), one describing the first half of your interfaces, the other describing the second half of your interfaces, then it would consider the second LSA a newer instance of the first one and conclude that the first half of your interfaces suddenly disappeared and at the same time the second half came to life. Now tell me where I violated the RFC. :) > > As for the OSPF *packets* being constructed based on MTU, that is surely a > > possibility. The IOS *implementation* however doesn't care about the MTU, > > as far as I can tell. > >I've never worked in a network with enough routes to know. I certainly can't >duplicate that in my home lab. Again, it's not the number of routes... also, you can change the MTU easily to a lower number if you just want to verify this particular statement. > or rather, I really have better things to do :-> Then you will have to believe me, hehe. :) > > Which part of the RFC says that the DD sequence numbers have something to > > do with the identification of LSAs? How will this identification method > > work if the same (instance of an) LSA reaches the router from two > > directions (see flooding)? > >well, I guess I'm being less than rigorous about my terminology. but the >sequence number is part of the "authentication" process, isn't it. if a >router receives a DDP with a lower sequence number than that which is >current in it's OSPF database, the DDR is rejected, is it not? I think we are one layer above DD sequence numbe
