At 10:15 PM 7/12/2003 +0000, 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? :->
Sure. The point I was trying to make is that this information flow is not bi-directional: the information in the LSAs will be transformed into routes and those routes will be installed into the routing table, however the LSAs sent out by a router are not based on the routes installed into the routing table. Consequently there is no close relationship between the number of routes and the size of the individual LSAs. > > >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. I think we are discussing a theoretical question, not the implementation, so all you need to have access to is the RFC. I claim that it is sometimes impossible to avoid IP-level fragmentation, regardless of how big your MTU or how good your OSPF implementation is. Specifically, if a router has a large enough number of interfaces in the same OSPF area, then that router will have to generate a huge (type 1) LSA, and that LSA (more exactly *any* LSA, but let's focus on a specific example) can be fragmented only at the IP layer. If you disagree, then please describe how your OSPF implementation will generate two LSAs that are individually smaller than the MTU, and that my (RFC2328 compliant) OSPF implementation must understand (and recognize the second one as an "extension" to the first). I would start at the top of Page 116, where it says: "The LSA header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the LSA." Based on this, if my OSPF implementation receives two LSAs, both having the same LS type (1), Link State ID (your router's OSPF ID), and Advertising Router (again, your router's OSPF ID), one describing the first half of your interfaces, the other describing the second half of your interfaces, then it would consider the second LSA a newer instance of the first one and conclude that the first half of your interfaces suddenly disappeared and at the same time the second half came to life. Now tell me where I violated the RFC. :) > > 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. Again, it's not the number of routes... also, you can change the MTU easily to a lower number if you just want to verify this particular statement. > or rather, I really have better things to do :-> Then you will have to believe me, hehe. :) > > 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 think we are one layer above DD sequence numbers. Can we just assume that the database exchange works properly and focus on what the receiver router learns in terms of LSAs? >I see that I'm tending to mix my DDP's and my LSA's, although >a DDP contains any number of LSA's. Any positive (or non-negative?) *integer* number of LSAs, to be precise. So for example it can *not* contain half an LSA (and hence help to avoid IP-level fragmentation), right? Thanks, Zsombor >So it states on page 196 > > > > > > 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- > > > > > > > > > > > > > > > > ______________________________________ > > > > > > > > =================================================================== > > > > [EMAIL PROTECTED] (http://bizsite.sina.com.cn) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72193&t=72024 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
