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--1----R3 (area 0)
| | | | (area 1)
| |--1--R5--1--| |
| |
R1 R4
R2, ABR_1, ABR_2 and R3 are in area 0
R1, ABR_1, ABR_2, R4 and R5 are in area 1
Now consider R2 sending packets to R3. R2 would
compute the SPF across area 0. R2 would expect the
path to be R2->ABR_1->ABR_2->R3.
However, assume ABR_1 considers the Summary LSAs it
receives from ABR_2 and installs these into its
routing table. ABR_1's cost to R3 would be less
via area 1 than the 100 cost through area 0. Presumably,
ABR_1 would instead install the path to R3 to go through
area 1.
So, traffic from R2, being sent to R3, would go:
R2->ABR_1->R5->ABR_2->R3. So, if the ABR was to consider
non-0 summaries, better paths to a destination might be
possible.
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 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=58338&t=57990
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
