Comments inline... *********** REPLY SEPARATOR ***********
On 7/12/2003 at 10:15 PM Hemingway wrote: >""Zsombor Papp"" wrote in message >news:[EMAIL PROTECTED] >> At 07:54 AM 7/12/2003 +0000, Hemingway wrote: >> >""hebn9999"" 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. > KY: According to the RFC (page 99) "If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected." With this in mind the only time fragmentation should occur is when a virtual link is used since the MTU of a virtual link is set to "0". The OSPF RFC is pretty complete, but you may have to look in multiple sections to find the information you need. In this case, it has nothing to do with sending DD packets and everything to do with receiving them. :-) > > (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 > KY: A DD sequence number only identifies the LSAs in that particular Neighbor Data Structure (see page 80 of the RFC). It only concerns the router's conversations with that particular neighbor, not the network as a whole so you might want to think of it more as a page number in a particular book rather than an absolute identifier. Basically, it just lets the router know whether or not it has new LSAs to process, a duplicate packet, or a missing packet. > >> >> 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- >> > >> > >> > >> > >> > > ______________________________________ >> > > >> > > =================================================================== Ah, to be muddying the waters again! Karen Y. A rose by any other name is Cisco specific terminology... Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72289&t=72024 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
