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