At 07:41 PM 7/10/2003 +0000, 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 +0000, Howard C. Berkowitz wrote: > >>At 5:40 PM -0700 7/9/03, Zsombor Papp wrote: > >>>At 11:07 PM 7/9/2003 +0000, Howard C. Berkowitz wrote: > >>>>At 12:43 PM +0000 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 all this with a grain of salt. >:) > >>>>> > >>>>>Thanks, > >>>>> > >>>>>Zsombor > >>>>> > >>>>>At 12:40 AM 7/9/2003 +0000, Howard C. Berkowitz wrote: > >>>>>>At 10:46 PM +0000 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 +0000, hebn9999 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=72130&t=72024 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
