ospf loop avoidance

[amms68958]

Hi,

Just wanted to know what is the loop avoidance mechanism used in ospf ..If u point to any url ,it will be of great help..

Thanks in advance..

[marikakis]

There is no loop avoidance in OSPF,

like those you would see in distance-vector routing protocols.

The loop avoidance is inherent in the SPF algorithm,

which OSPF (as a link-state routing protocol) uses to calculate routes.

This way, a tree is built for each router with itself as the root.

Trees by definition do not have loops.

Extensions to this tree exist only for load-balancing reasons.

M.

[Harold Ritter]

As Maria stated, there is no need for a loop avoidance mechanism inside the scope of a single area. If you have more than one area though, ospf behaves as a distance vector protocol, so some sort of mechanism is required not to loop routing information. One rule that governs that inside ospf is that summary routes advertised in a non-backbone from the backbone area can never be passed back up to the backbone area. On the other hand, summary routes advertised from the non-backbone to the backbone area can be passed back down to the same non-backbone area via another ABR.

Hope this helps,

[marikakis]

Harold, this was a nice detail that you mentioned.

(If my writing style was not a bit formal, I could say it was pretty cool!:-)

You are right and to the point, as usual.

You got me to finally have a look in that huge OSPF RFC.

There is a point I am not sure I understand right.

On the Summary links section

http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1583.html#sec-12.4.3

there exists the following (2nd paragraph) :

"Note that only intra-area routes are advertised into the backbone,

while both intra-area and inter-area routes are advertised into the other areas."

From this, I understand that summary routes are not advertised

from the non-backbone to the backbone.

But you said :

"On the other hand, summary routes advertised from the non-backbone to the

backbone area can be passed back down to the same non-backbone area via another ABR. "

Did you mean to say that :

"Summary routes originated from an ABR for a non-backbone area

are also distributed to the backbone and

can be passed back down to the same non-backbone area via another ABR. " ?

I think the tricky part is the border between a non-backbone area and the backbone area,

which resides inside the ABR itself.

Best Regards,

Maria

[Harold Ritter]

That is exactly what I meant. By "summary routes advertised from the non-backbone to the

backbone" I meant summary generated in area 0 by the ABR from the inter-area routes in the non-backbone area. Sorry for the misleading wording.

I think this line you quoted from the RFC summarizes it pretty well:

"Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas."

Thanks for quoting the RFC, it is usually the best way to clarifies things.

[Harold Ritter]

BTW: the direct effect of this loop avoidance mechanism is that a discontiguous non-backbone area is repaired by the backbone area and a discontiguous backbone area has to be repaired using a virtual link.

Hope this helps,

[amms68958]

hi harold and maria,

Thanks for ur responses..It was very informative....But I have a doubt in discontingous non backbone area...Imagine a scenario where the set up is like this...Area 1- area0- area4- area0-area1..

I have assigned address discontigously in the 2 area 1s.So the summary address of the 2 area 1s are the same...So as per the above responses, the same summary address will be known to area4 from 2 area1s.

And my question is how the ABR in area4 will forward a packet destined to area 1..?

Thanks

[marikakis]

This is a scary mix of two different types of discontinuity.

The one is in area 0, and the other is in the assignment of IP addresses.

Even if we suppose that your area 0 is properly patched with virtual-links,

I think this will not work in general.

Each ABR will choose the path it thinks is closest to area 1.

But, end-to-end delivery will depend on the decisions of other devices as well.

Imagine a host outside area 1, that tries to communicate with another host in area 1.

Depending on the outside host's position in the network,

its packets will either be delivered only towards the one partition of area 1,

or load-balancing will occur.

In the case of load-balancing connectivity will be completely broken.

In the case of choosing one partition over another,

if the hosts manage to communicate, this will be sheer luck.

I think you need to somehow interconnect your area 1 partitions together

for this to work.

Or renumber, or re-design.

I hope this scenario is really an imaginary one ;-)

M.

[Harold Ritter]

Another thing you have to bear in mind is that a discontiguous non-backbone area in conjunction with aggregation at the ABR using the area-range command might lead to traffic black-holing. The reason is that the ABR will advertised a summary route for toutes it doesn't necessarily have access to.

Hope this helps,

[Kevin Dorrell]

Are you allowed a discontiguous backbone like this? The diagram looks like the backbone is discontiguous through area 4; is that valid? Maybe it is only area 1 that is discontiguous through the backbone, and area 4 is connected to the backbone (a T-shaped topology).

Sorry for snooping the conversation, but I would like to understand the question to get my ideas on OSPF straight.

Thanks in advance

Kevin Dorrell

Luxembourg

[Harold Ritter]

This is valid only if you have a virtual link configured between the two ABRs in area 4.

Hope this helps,

[Kevin Dorrell]

So, if I understand right, you are allowed to join up a discontiguous backbone with a virtual link, just in the same way that you would join up a discontiguous non-backbone area. Cool!

And what the questioner has is a virtual link (across area 0 on behalf of area 1) running over a virtual link (across area 4 on behalf of the backbone). I agree with Maria, that's scary!

I hope I understood right.

Kevin Dorrell

Luxembourg

[marikakis]

Kevin, perhaps you thought there are 2 virtual links

because I used plural in my answer.

That was to cover the case of a backup patch for area 0.

I do not think the 2 partitions of area 1 actually need

a virtual link to communicate.

Harold already mentioned that the behavior of ABRs

with summaries is such,

so that no problem will arise with the partitioning of area 1.

M.

[Kevin Dorrell]

OK, thanks. I think I need to try it next time I book a lab session.

Kevin Dorrell

Luxembourg

[Harold Ritter]

The virtual-link is used only to repair a discontiguous backbone area or to link an ABR that doesn't have a direct connection to the backbone area.

A discontiguous non-backbone area is repaired via the backbone area. No virtual link is needed in this case.

Hope this helps,