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 +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=72134&t=72024 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
