Re: OSPF ABR question [7:57990]
""p b"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Consider the following topology: > > area_0---ABR_1area_1-ABR_2area_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=57991&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
> 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" "I am Connor MacLeod of the Clan MacLeod. I was born in 1518 in the village of Glenfinnan on the shores of Loch Shiel. And I am a CCIE." Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57995&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
""B.J. Wilson"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > 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" > > "I am Connor MacLeod of the Clan MacLeod. I was born in 1518 in the village > of Glenfinnan on the shores of Loch Shiel. And I am a CCIE." > CL: hahahahahaha! lord knows he has plenty of time to study. wonder what would happen if two immortals showed up for the Lab on the same day? Not sure I'd want to be in the parking lot after the test. CL: hey, all those guys had multiple identities. He could hit the Lab several times under different identities, scope it out, and probably pass after just a couple of tries. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57996&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
> CL: hey, all those guys had multiple identities. He could hit the Lab > several times under different identities, scope it out, and probably pass > after just a couple of tries. Crude and slow, clansman. Your config was no better than that of a clumsy child. ;-) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57998&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
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?" 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. 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) Thanks The Long and Winding Road wrote: > > ""p b"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Consider the following topology: > > > > area_0---ABR_1area_1-ABR_2area_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=58006&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
""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_1area_1-ABR_2area_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=58009&t=57990 -- FAQ, list archives, and subscription info: http://
Re: OSPF ABR question [7:57990]
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... 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_1area_1-ABR_2area_0 > > > > > > > > There are two area 0's. > > > > > > CL: you have a partitioned area 0. can't
Re: OSPF ABR question [7:57990]
> > Consider the following topology: > > > > area_0---ABR_1area_1-ABR_2area_0 > > > > There are two area 0's. Use a virtual link to connect the area 0s. __ Do you Yahoo!? Yahoo! Mail Plus ^V Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=58022&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF ABR question [7:57990]
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
Re: OSPF ABR question [7:57990]
""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
Re: OSPF ABR question [7:57990]
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. 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. 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. 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? Consider two ABRs: area0ABR1area1ABR2area0 If the paritioning of area 0 gives ya the willies, assume they're connected together. It really doesn't matter. 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. 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. So, I (still) don't see an issue if the ABR behaved as described above. 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$
Re: OSPF ABR question [7:57990]
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: area0ABR1area1ABR2area0 > > 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 co
Re: OSPF ABR question [7:57990]
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? > > 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--1R3 (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. 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): 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
Re: OSPF ABR question [7:57990]
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--1R3 (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 networ
Re: OSPF ABR question [7:57990]
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 topo
Re: OSPF ABR question [7:57990]
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 summa
Re: OSPF ABR question [7:57990]
At 1:44 PM + 12/2/02, Peter van Oene wrote: > >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. > > >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 > > > >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 design >around, or live with these issues. > > Good points, Peter. I think one real-world nuance that doesn't come through in most routing classes is that people often worry too much about suboptimal routing and too little about instability. With today's transmission technologies and router speeds, you can often solve the first by throwing bandwidth at the problem and "neutralizing" the suboptimality. Instability, however, can kill your network, and, if on the Internet, other networks. It's my impression that the CCIE test strategy overemphasizes optimality and underemphasizes stability. Certainly, some of the major reasons to use hierarchical redistribution, blackhole routes, minimizing information sent to routers, etc., are stability -- and these techniques are usually forbidden in the lab. Sometimes I wonder if there needs to be a book or seminar, "OK, now you are a CCIE. This is what you need to unlearn." ;-) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=58397&t=57990 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
