On Sat, 2002-11-30 at 12:52, p b wrote: > Thanks for the comments. Some thoughts below. > > Peter van Oene wrote: > > > > > 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. > > Is the ABR behavior you describe (ABR looks in routing table > to determine what to regenerate in the summary LSA) part of the > spec or is this how a specific implementation works?
See 12.4.3 of 2328. > > > > > 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 > > Here's an example topology. It's very simple and somewhat > contrived, but illustrates the point. Note, link costs are > show on each link. > > > R2--1--ABR_1---100---ABR_2--1----R3 (area 0) > | | | | (area 1) > | |--1--R5--1--| | > | | > R1 R4 > > > R2, ABR_1, ABR_2 and R3 are in area 0 > > R1, ABR_1, ABR_2, R4 and R5 are in area 1 > > Now consider R2 sending packets to R3. R2 would > compute the SPF across area 0. R2 would expect the > path to be R2->ABR_1->ABR_2->R3. > > However, assume ABR_1 considers the Summary LSAs it > receives from ABR_2 and installs these into its > routing table. ABR_1's cost to R3 would be less > via area 1 than the 100 cost through area 0. Presumably, > ABR_1 would instead install the path to R3 to go through > area 1. > > So, traffic from R2, being sent to R3, would go: > > R2->ABR_1->R5->ABR_2->R3. So, if the ABR was to consider > non-0 summaries, better paths to a destination might be > possible. Sure, but again, in sample topologies where this fit might work. However, you could solve the above problem my making area 5 an ABR. In your design, you have not optimally built your OSPF network and are looking to break the protocol to suit a sub-optimal design. Most of these issues are better solved with design than kludging up protocols. > Note, there's very interesting behavior here when external's > are involved. Suppose R3 causes an external to be injected > into OSPF. This external get flooded through area 0 and area > 1. ABR_1 will compute the shortest path to this external. If > the cost through the non 0 area is better, ABR_1 does install > the path to the external to go through area 1. What this means > is that the spec apparently does allow non-0 areas to be transit > for externals. Traffic from area 0's R2 going to an external > hanging off of area 0's R3's transit area 1 (R5): Non intra-area ASBRs are found via type 4 LSAs (ASBR Summary) which follow the same rules as type 3 summaries and thus prevent non zero areas from providing transit toward ASBRs (that is where the non zero area contains neither the source nor ASBR) > R2->ABR_1->R5->ABR_2->R3 > > > > > > > > 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 ;-) > > See if the example above clarifies this situation. > > > > > > > > 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=58340&t=57990 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
