On Sun, 2002-12-01 at 12:18, p b wrote: > 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.
A general concept in routing is to always prefer information from the most accurate source. In Link State routing, a given router always has the most accurate information about the area itself, and thus will always prefer information derived from there. This mechanism also prevents loops. > > 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. Issues like these often occur in OSPF. Pat Murphy, in his NSSA drafts, refers to this phenomenon as "hijacking". It is good to keep in mind that this only produces sub-optimalities, not routing instabilities. However, all routing impementations can be prone to sub-optimal routing if you do not optimally design the topology. BGP confederations often suffer from this as the length of the AS-Confed-Sequence is not used in the BGP path selection algorithm. > Given the topology of area 0, little might be possible in avoiding > the sub-optimal routing For ring topologies, I often mux the link between ABR_1 and ABR_2 to provide two logical links. If these are in a POP together, they likely run GigE or something similar in which case one can simply use 802.1q over the link and present an Area 0 link along with a non backbone link. This helps in the enterprise case where summarization is occuring, and also helps provide more optimal routing. The only cost is in IP addressing and a little more complexity. Should POS be in use, frame works well here in the same fashion. . 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? Actually R doesn't have this information. The SPF algorithm is used within the area to find the minimal cost path to each node in the area. For an inter area destination, the already known cost to an ABR is summed with the cost provided in the LSA to create an Inter Area Cost (IAC) to the given destination, the least of which (assuming there are more than one for a given destination) is chosen and used for next-hop selection. At no point does the router calculate an SPF to the inter-area destination specifically. It also doesn't look deeply at the composite nodes along a given path to determine whether or not they happen to be ABRs themselves, and certainly not ABRs which happen to provide transit to a particular area for which they might also be deriving IACs to in another process. Furthermore, they don't actually even know which areas a given ABR provides transit to as this information isn't relevant nor contained in a type3/4 LSA. As hopefully I've pointed out, there really isn't a way in OSPF to iron out all the potential for sub-optimality that a given topology might present. It is incumbent upon the designer to understand and architect around, or live with these issues. > 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=58373&t=57990 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
