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