On Wed, 2002-11-27 at 08:04, p b wrote: > Thanks. > > Went back and read through some of the relevant parts of > the RFC. I believe there is no routing loop issue if an ABR > was to consider summary LSAs received from non-zero areas. > (where "consider" means install routes from these type 3s. > "consider", above, does not mean propogate the summary info > into area 0). I believe this would maintain the DV properties > of the OSPF two-level hierarchy because the ABR would not > re-originate the information that was already re-orignated > at another ABR.
A subtle point here. Type 3 summaries, when sent inter area, are not flooded, but regenerated. The ABR generates them by looking at routes in the routing table. Hence, if the ABR put routes in the table from non backbone type 3's, those routes would be prone to readvertisement into the baackbone. > > In fact, if the ABR did install routes based on the non-0 summary > LSA information, better paths to destinations might be possible. However, since the ABR doesn't advertise these better paths > (remember, no taking non-0 summary info and sending into area0) > these better paths are not visible to the backbone area. Can you give an example of this? If all ABRs send accurate summaries to the backbone, from the backbones perspective, routing should be optimal. The only time it becomes less is is when the ABR coalesces information The > result with an ABR using non-zero summary information in its > routing table is that some intra area0 traffic might unexpectedly > transit a non-zero area. "Unexpectedly" here means that the > area0 SPF would compute a path to the destination, and from > the SPF perspective, traffic would remain on area0. But when > the traffic hit the ABR, it might forward the packets over > the non-0 area as that's a better path towards the destination. Ok, I'm losing you a bit here. Maybe an example would help. Forwarding decisions in OSPF are either source to destination, source to ABR, ABR to ABR, or ABR to destination. In all of these cases, the source and final or intermediary source shared an identical LSDB from which they will calculate similar SPF trees. Hence, there shouldn't be a case in a stable network where two nodes in the same area find a different best path through the area. In the Area 0 case, assuming the traffic is destined to a non-0 area, the ABRs simply forward that traffic to the nearest ABR, upon which all ABRs should agree with the exception of multi-abr areas whos ABRs will not be able to forward back toward the backbone due to route preference. This might be more confusing than your paragraph though ;-) > A virtual link is the mechanism to "formalize" the use > of a non-0 area for transit. The benefit of the VL mechanism > over the thinking above is that a VL allows routers in area0 to > be cognizant of the non-0 area as another way to reach destinations > in area0 and thus include these costs into it's LSDB and SPF calcs. > > Compare an ABR including summary LSA information in it's routing > table (what I've been asking about) and an ABR at the end if a > VL. How is the routing information received at this ABR > different? The virtual link allows LSAs to flood through the non-backbone area. These LSAs allow the backbone area databases to remain identical for all routers in the area which is a necessity for link state protocols. Breaking this will more than likely lead to routing instability. Certainly in some basic topologies, you might be able to relax some rules and still provide stable routing, but the question is, what are you gaining with this topology? > Consider two ABRs: area0----ABR1----area1----ABR2----area0 > > If the paritioning of area 0 gives ya the willies, assume > they're connected together. It really doesn't matter. It matters entirely as you either have backbone LDSB synchronization or you don't. > Consider ABR2. It will see type 1-5 LSAs from it's area 0. > If ABR1 and ABR2 had a VL between them, ABR2 would pass all > of these LSAs, intact, to ABR1 over the VL. Not quite true. ABR2 will not flood type 5 LSAs over a VL. However, since area 1 is not a stub, ABR 1 would see the type 5's anyway. ABR1 would be able > to use area1 to send traffic to ABR2's area0. > > Assume there is no VL between ABR1 and ABR2. Instead, ABR1 > learns about ABR2's area 0 via type 3-5 LSAs from ABR2. Well, > type 3 LSAs are really the info found in type 1-2 LSAs but > with just the RID information reflecting ABR2 instead of the > originating router's RID. In your simple topology, this might work ok. However, your topology is simple. I've never really thought about the behavior you describe, mostly because I can't see where it makes sense, but I could imagine lots of control loops, particularly in areas with multi-abrs. When networks transition, you'd likely run into counting to infinity issues which OSPF doesn't really have a mechanism to deal with (ie hop count limits etc). > > So, I (still) don't see an issue if the ABR behaved as described > above. Again, not in your simple topology as far as I can tell. > Thanks for the thoughts so far. Be interested in more feedback > on the above analysis. > > > > Peter van Oene wrote: > > > > On Sun, 2002-11-24 at 21:56, p b wrote: > > > 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. > > > > Intra area routing uses a distance vector methodology. Such > > mechanisms > > are prone to couting to infinity issues stemming from > > information > > feedback. Having a strict hierarchy prevents this. > > > > > 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. > > > > The concepts are not that similar in my opinion. The non > > backbone > > connected ABR will not be capable of feeding back routing > > information > > into the backbone so long as regular ABRs ignore his > > summaries. There > > are valid designs that support this requirement. However, I do > > not see > > any valid reason to intentially fragment ones OSPF backbone. > > > > What problem does your topology solve? > > > > > 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. > > > > Doing so would create the potential for routing loops, > > particularly when > > two ABRs sit within the same area. In equal cost situations, > > there are > > no additional bits to designated whether a summary has passed > > through > > the backbone or not (like the ISIS up/down bit for example). > > The ID you > > refer to introduces this type of functionality for the non > > backbone > > connected ABR. > > > > > 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... > > > > > > > > > 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=58185&t=57990 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
