""p b"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Consider this a question around the theory behind why OSPF > did things a certain way. Somewhere along the way, Moy > et. al. decided that there was an issue with an ABR processing > a summary LSA. Based on that, they decided to make a design > decision in OSPF to not allow this behavior. > > Apparently the restriction on ABR's processing of summary > LSA information is being relaxed. This relaxation is > described in the ID. You are right, the ID is slightly > different than the context of my question. In the ID, the > ABR is not connected to area 0, where's in my case, it is > connected to area 0. But the concepts are similar-- there > are times when an ABR should consider and use summary LSA > information. > > I'm not sure I understand your comment about adjacencies. > ABR_1 does receive the summary LSAs from ABR_2 and stores > these routes from these summaries in its LSDB for area 1. > So this isn't an adjcency issue. > > So, still looking for an answer to the question. Why is it > that an ABR can not use the information it receives in > a summary LSA as part of the route selection process? > There must be a reason why the spec indicates this is not > allowed, and thus I'm looking for this reason. > > Regarding the M$ comment. It really surprises me how > often folks will cookie-cutter a design based on what > was presented in the last book they skimmed and not try > to understand a topic beyond what's needed to pass an exam. > Just looking for some outside of the box thinking...
CL: since I am somewhat authority driven, it sometimes bothers me when folks spend time looking for ways to evade restrictions of one system, instead of using better suited alternatives. I admit I have not read every working paper, nor even every RFC regarding OSPF. I believe I have read enought to have an idea of why it was designed the way it was. I don't necessarily agree with the strict hierarchy. I believe, based on the existince of such things as virtual circuits, that the designers recognized certain inherant problems with strict hierarchy as well. CL: the question in my mind is why, if strict hierarchy is inconvenient, does one devote effort to circumventing it, instead of choosing a more appropriate protocol? Sure, EIGRP is proprietary. RIPv2 is not. IMHO, it would not be so difficult to modify RIP such that it offers more in summarization options, and reduces the frequency of routing table broadcasts. CL: in the working paper you referenced, I did not really understand the points, based on the examples presented. whether it made sense in the minds of the ISP involved, it still looked to me like a a poor response to something that "just happened". CL: I've done some writing on this in the past. The OSPF virtual link serves only to establish adjacency with area 0. It does not necessarily determine routing. That is, if a packet is rceived by a router, that router checks it's routing table, and forwards the packet out the appropriate interface. It does not look, determine that this is a packet from an OSPF area that is not directly connected to area zero, and therefore forward the packet to the nearest area 0 router. CL: I also understand the issue of the summary addresses. This "could" create suboptimal routing. OK - so now we are back to design. to solve a particular problem, someone decided to through in an ASBR somewhere, make it into it's own area, and assure that the particular area broke OSPF hierarchy. Then they want to modify OSPF such that this non connected area can still communicate with other areas directly. It's not that I am not "thinking out of the box" It's more like I am still wondering why, other than to make OSPF behave more like EIGRP or RIPv2 or IS-IS CL: the Microsoft comment is deliberate. Microsoft, God love 'em, has done great things in terms of making computers accessible and easy to use for most people. ( no I don't want to hear about Apple, who made the first step, but due to their elitist pricing and closed architecture, ended up losing the hearts and minds, not to mention the pocketbooks, of most people ) Microsoft has also created any number of problems with their peer to peer mentality. Microsoft's answer to just about everything is to make it possible, so that people can easily share information. Unfortunately, they have also made it easy for bad things to happen as a result. CL: lastly, please accept my apologies for being a bit uptight about this, in this response or others. I did misunderstand what you were originally asking, and I did take it a bit more seriously than I should have. I promise I will read more carefully in the future. > > > The Long and Winding Road wrote: > > > > ""p b"" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Thanks. But this doesn't really answer my question. I > > realize > > > that area 0 is partitioned. I'm not looking for an answer to > > > "is there a rule that prevents this", but instead, "what > > breaks > > > if ABR_1 were to consider routes learned via a non-area-0 > > summary > > > LSA in its computation of it's routing table?" > > > > CL: sorry to be inflexible on this, but in my mind what you are > > asking is > > "why doesn't OSPF behave in a way that it is not supposed to > > behave?" > > > > > > > > > > > > Note, I'm also not asking why ABR_1 should not flood ABR_2's > > > summary LSAs into ABR_1's area 0. > > > > > > So back to the scenario: all routers in area 1, including > > > ABR_1, receive summary LSAs from ABR_2 which contain the > > routes > > > from ABR_2's area 0. > > > > CL: no - becasue no adjacency can be formed between area 1 and > > area 2 > > routers. all adjacencies have to be formed between an area's > > ABR, which is > > connected to area zero. this changes if you either 1) > > unpartition area 0, > > with a tunnel or a virtual link or 2) set up a virtual link > > across either > > area 1 or area 2, ( which is probably the same as # 1 ) > > > > > > CL: you have an adjacency between area 1 and the area 0 it > > conects to, and > > area 2 and the area 0 it connects to. you do not get an > > adjacency between > > the area 1 and the area 2 routers. > > > > > > > > All non-ABR routers in area 1 will process the information > > > injected by ABR_2's summary LSAs. These routers will install > > > these routes into their routing table. These non-ABR routers > > > will not realize there is an area 0 parition and will have > > > reachability into both. (I've not tested this, but believe > > > this to be true.) > > > > > > Since ABR_1 is an ABR with a backbone connection, it's not > > > allowed to: > > > > > > - forward information from ABR_2's summary LSAs into it's > > area 0. > > > - consider any routes found in ABR_2's summary LSAs as > > candidates > > > for insertion into its routing table. > > > > > > My question is, what breaks if ABR_1 was to use the > > information > > > found in ABR_2's summary LSA and put these into it's routing > > > table? > > > > > > Note, it is possible for an ABR, which does not have an area 0 > > > connection (hence it's an ABR between 2 or more non-zero > > > areas) to consider and use summary LSAs in it's route > > > installation process. (see Zinin's "Cisco IP Routing", > > > page 491; and > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-abr-alt-05.txt) > > > > > > CL: I don't have the book you refer to. I did a quick read of > > the draft RFC > > in the link above. My quick read is that it looks to me that > > the authors are > > suggesting a reinterpretation of the definition and activity of > > an ABR to > > suit some particular situation that could also be solved other > > ways. Their > > examples do not match yours, so I won't comment further, except > > to wonder > > why it is that some folks want to take the Microsoft attitude - > > do whatever > > you want to don't bother with design. I mean, for goodness > > sake, if you want > > chaos, then set up using EIGRP ;-> > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > The Long and Winding Road wrote: > > > > > > > > ""p b"" wrote in message > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > Consider the following topology: > > > > > > > > > > area_0---ABR_1----area_1-----ABR_2----area_0 > > > > > > > > > > There are two area 0's. > > > > > > > > CL: you have a partitioned area 0. can't have two area > > zeros in > > > > ospf. to > > > > quote from my favorite movie of all time, "There can be only > > > > one!!!!" > > > > > > > > > > > > > > > > > ABR_1 and ABR_2 will generate > > > > > type 3 summary LSAs for the respective area 0s and > > > > > flood the information into area_1. An internal > > > > > router in area 1 will see the summary LSAs from ABR_1 > > > > > and ABR_2, determine the best routes, and then insert > > > > > them into it's routing table. > > > > > > > > > > Now consider ABR_1. It sees and stores in it's area 1 > > > > > LSDB the summary LSAs it got from ABR_2. > > > > > > > > > > The OSPF spec indicates that ABR_1, however, should > > > > > not forward this routing information into it's own area 0 > > > > > connection. This is done to prevent routing loops. > > > > > > > > > > My question is this: What is the reason why ABR_1 can > > > > > not use the routing information learned via ABR_2's > > > > > summary LSA and install these routes into it's own > > > > > routing table? > > > > > > > > > > > > CL: there can be only one area zero. them's the rules. > > > > > > > > > > > > > > > > > > Note, I believe if there was a virtual link between ABR_1 > > > > > and 2, ABR_1 would learn via ABR_2 the same set of routes > > via > > > > > summary LSAs and would be allowed to enter them into it's > > > > > routing table. > > > > > > > > > > There must be a routing loop issue here, but don't see > > > > > it. > > > > > > > > CL: interarea routing must transit area 0. what you are not > > > > seeing is that > > > > you have a partitioned area zero, not two area zero's. you > > have > > > > broken ospf, > > > > and now you need to repair it. > > > > > > > > > > > > > > > > > > Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=58037&t=57990 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
