Peter van Oene wrote: > > 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)
You're right. I went back and looked at my lab config. I had had a link configured as non-0 when I thought it was in area 0. Thus the incorrect conclusion regarding externals and non-0 areas for transit. It's interesting that OSPF will, apparently, always prefer an OSPF intra-area path over an inter-area path to a destination, even when the inter-area path is less cost. This has implications for certain area 0 topologies (ie a ring built from p2p links) and thus can result in sub-optimal paths for certain source routers and destinations. This would happen when a router, R, in area 0 is trying to reach a destination, D in a non-0 area, and there are two ABRs. ABR_1 and ABR_2 will install intra-area routes to the destination D. ABR_1 and ABR_2 will advertise into area 0 their costs to D via type 3 LSAs. Router R will compute its cost to D through ABR_1 and ABR_2. It might determine that ABR_2 is the prefered ABR through which R should route traffic to D. However, if the path between R and ABR_2 causes the traffic to go through ABR_1, traffic from R to D will enter the non-0 area at ABR_1 (since OSPF prefers intra-area paths over inter-area path, even if more expensive; ABR_1 thus installs the intra-area routes). Thus, traffic from R->D takes a sub-optimal path. Note this behvaior has nothing to do with summarization. Given the topology of area 0, little might be possible in avoiding the sub-optimal routing. However, R would know, when it computes its tree to D, that traffic will flow through ABR_1 to get to ABR_2. Looking at the cost to D from router R (via show ip route) it shows the cost as if the path enters the non-0 area at ABR_2. However, this isn't the path traffic will follow. Now, R has the information to make the determination that traffic will flow into the non-0 area at ABR_1. Why would R not show the cost to D via ABR_1 as this is the path that traffic takes? Thanks > > > 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=58370&t=57990 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
