Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

ospf design issue

I really need an expert opinion on this. What is the difference between these two topologies?

Area1-------Area0-------Area1

And

Area1-------Area0-------Area2

I understand LSA type 1,2,3 are area specific. Why should I change the Area numbers because the areas 1 are not directly connected.

Can someone describe this.

1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

Re: ospf design issue

Rick, what I had in mind was something like two area 1 ABRs using a summary for the complete address range that covered all area 1 addresses. However, I also agree with you if each partitioned part of area 1 only generated a summary for its part of area 1, then area 0 should be able to direct traffic to the correct ABR.

I would caution the original poster, that avoiding this type of design might be more than just "best practice". Intentionally designing partitioned OSPF areas is the type of thing that often comes back later that makes for new problems. This often is especially true when you need to mix different vendor equipement.

If you read RFC2328's "Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information." could be implemented such that area 1 traffic in one partition could not transit area 0 to reach the other partition.

[edit]

I was going to suggest, you might also want to post "WAN, Routing and Switching: ASK THE EXPERT INTERIOR DYNAMIC ROUTING PROTOCOLS", but I see you've already posted there too.

12 REPLIES
Super Bronze

Re: ospf design issue

The first represents a partitioned area, and soemthing you want to avoid. The second, is correct.

Why would you not want partitoned areas? Consider if in the partitioned case area 1 advertised a summary address. Which area 1 then should area 0 direct traffic?

PS:

Same question posted in the "WAN, Routing and Switching:" forum.

Hall of Fame Super Gold

Re: ospf design issue

Masood

Joseph is correct in identifying that alternative 1 is a partitioned area. Partition of an area (having two parts of an area that are completely separated by other areas) is a serious issue in area 0 (the backbone area) and is not a serious issue in non zero areas. So in your case both alternatives should work equally well.

I would agree that as a best practice you want to avoid partitioned areas. But partition of a non zero area is not nearly as serious as partition of area zero. Joseph raises the question of a summary route generated by an ABR in the partitioned area and suggests that it introduces ambiguity about how area 0 would route it. But the summary route is specific to the ABR that generated it and the area 0 would route to that summary through the ABR that generated it. So area 0 would route to the correct part of area 1.

HTH

Rick

Super Bronze

Re: ospf design issue

Rick, what I had in mind was something like two area 1 ABRs using a summary for the complete address range that covered all area 1 addresses. However, I also agree with you if each partitioned part of area 1 only generated a summary for its part of area 1, then area 0 should be able to direct traffic to the correct ABR.

I would caution the original poster, that avoiding this type of design might be more than just "best practice". Intentionally designing partitioned OSPF areas is the type of thing that often comes back later that makes for new problems. This often is especially true when you need to mix different vendor equipement.

If you read RFC2328's "Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information." could be implemented such that area 1 traffic in one partition could not transit area 0 to reach the other partition.

[edit]

I was going to suggest, you might also want to post "WAN, Routing and Switching: ASK THE EXPERT INTERIOR DYNAMIC ROUTING PROTOCOLS", but I see you've already posted there too.

Hall of Fame Super Gold

Re: ospf design issue

Joseph

I do not want to advocate for partitioned areas, but I think that we need to be clear about what causes certain types of problems. The issue that you suggest where both ABRs generate a summary route for overlapping address space is a genuine problem but it is not a problem of partitioned areas. You would have exactly the same problem if you have separate areas (perhaps area 1 using addresses within 10.10.1.0 and area 2 using addresses within 10.10.2.0) and if the ABRs both generated a summary for 10.10.0.0/16. The backbone would not be able to correctly identify into which area to forward some traffic.

HTH

Rick

Super Bronze

Re: ospf design issue

Rick,

No, I didn't think you were advocating intentionally partitioning OSPF areas, but I did want to emphasis that it seems contrary to the RFC. To me, an OSPF "best practice" might be how many areas to have on an ABR. Again, intentionally partitioning areas, merits extreme caution, I believe.

I agree you're correct, partitioned areas, themselves, do not cause the ABR summary address issue with overlapping address space that I used as an example. However, since OSPF areas can summarize, the ideal, I think, is to have one summary address for the whole area, which would not be possible if you intentionally split the area. Further, if you did try to summarize all of area 1 addresses, as you might if the area was not partitioned, then you would have the problem I described. Again, though, you're correct that the partitioned area does not make the problem, but hopefully you might agree it can lend itself to the problem.

Hall of Fame Super Gold

Re: ospf design issue

Joseph

I can agree with that.

HTH

Rick

Hall of Fame Super Gold

Re: ospf design issue

Joseph

In his response to this question in the Ask the Expert Edison makes an interesting point that indirectly relates to the RFC that you quoted. Functionally the two area 1s are separate areas. Each area 1 (the left area 1 and the right area 1) see the routes from the other area 1 as inter-area routes (O IA) and not as intra-area routes (O). And a router in the left area 1 is not in the same area as a router in the right area 1.

HTH

Rick

Super Bronze

Re: ospf design issue

Rick,

I saw the response. Wasn't surprised at the results. That's why I never said it wouldn't function, but instead stressed extreme caution in intentionally designing an OSPF with partitioned areas.

Another variation I haven't mentioned was when using an area summary address, I have seen traffic stuck within an area when the area had been accidentally partitioned. This because individual routes not forwarded to the backbone as each partitioned part of the area only sees its own internal area routes.

Perhaps one could also consider is there any good reason to intentionally partition OSPF areas. None comes to my mind. Otherwise I believe it's bad juju.

Hall of Fame Super Gold

Re: ospf design issue

Joseph

I would like to approach this from a slightly different perspective. I would suggest that in considering partition of an OSPF area that there are 2 cases to consider:

- partition of the backbone area 0

- partition of a non-backbone area (non area 0).

Partition of the area 0 backbone is bad and it does break things in the OSPF network.

Partition of a non area 0 area is not necessarily bad and does not break anything. Problems may arise when you add things like area-range (or summary-address). But the same risks would exist if it were area 1 and area 2 as do exist when it is area 1 and area 1.

I can not think of any reason why it would be desirable to design an OSPF network with the area ID being the same in several different areas (partitioned non backbone areas). I think that there is a case to be made for the advantage of having unique area ID in terms of management of the network and perhaps in terms of troubleshooting in the network. Therefore I would say that partitioned areas are not desirable and are not best practice in the design of OSPF networks.

HTH

Rick

Super Bronze

Re: ospf design issue

Rick,

Your slightly different perspective seems to be proposing a partitioned area 0 is bad because it breaks things, but intentionally designing partitioned non-backbones areas, if done without configuration errors, "is not necessarily bad because it does not break anything" (although you don't endorse doing so). Or in other words, it's just "not desirable" and "not best practice".

My perspective is, since intentionally designing partitioned areas appears to violate the RFC, it rises to a level beyond not just being a best practice.

If we come back to one of the orginal poster's questions, "Why should I change the Area numbers because the areas 1 are not directly connected". Perhaps the "correct" answer is: areas are a design feature of OSPF and they were not intented to be intentionally partitioned.

As a rough analogy, I could drive a vehicle at half the speed limit, the speed limit, or twice the speed limit. "Best practice" we might consider driving at the speed limit. Whether I have an accident or not, might not be related to my speed, but it also could be related to my speed, and if there's an accident, faster is likely to make it worst.

If you're going to speed, or intentionally design partitioned areas, again, the criteria for doing so should be, I think, beyond whether it can be successfully done.

Hall of Fame Super Gold

Re: ospf design issue

Joseph

We have a difference of opinion here. You believe that the situation proposed in alternative 1 violates the RFC and I believe that it does not violate the RFC.

I believe that underlying this is your assumption that in alternative 1 it is still a single area 1 - but partitioned. And I believe that when area 1 became partitioned (whether partitioned because it was designed that way or partitioned because of some failure in the network) it effectively becomes 2 different areas.

To refresh a concept: intra-area routing is routing based on LSA type 1 and LSA type 2 (and intra area routes are always preferred over inter area routes) while inter area routes are based on LSA type 3.

So in your perspective it would seem that area 1 on the left would be routing to destinations in area 1 on the right based on type 1 and type 2 LSAs (if it were a single area). But clearly the ABR of area 1 on right is injecting type 3 LSAs into the backbone for its subnets and that the ABR of area 1 right is forwarding those type 3 LSAs into its area. So routing in area 1 on the left is based on those type 3 LSAs (inter area routing) and not on type 1 and type 2 LSAs. And I believe that the results of Edison's testing and his comments bear out this difference.

HTH

Rick

Super Bronze

Re: ospf design issue

Rick,

You may indeed be correct that intentionally designing separate areas with the same ID doesn't actually violate RFC2328, since the document doesn't actually expressly prohibit such designs. On the other hand, it doesn't appear to document intentionally doing so either, even as a "may".

Section 3.7, "Partitions of areas", is worth reading. In summary, it documents what has already be noted in our posts, that partitioned backbone areas are a problem, partitioned non-backone areas should continue to function unless the address range has been split.

As to our assumptions that I consider two areas of the same ID partitioned, where you believe they effectively become two different areas, section 3.7 notes that although two areas of the same ID may effectively still function, they have the "same color". I believe this part of the RFC supports my assumption that two areas of the same ID are indeed a partitioned area and are not the same as two different numbered areas, even if they might function as would two different numbered areas.

Whether intentional design of multiple areas of the same area ID violates the RFC (and I'll again affirm it doesn't appear to) or whether such design violates the "spirit" of the RFC, let's turn to the question of "not best practice".

No one has suggested intentional design of multiple areas of the same area ID is "best practice", but I believe it's "bad practice". "Bad practice" is certainly also "not best practice", but "not best practice" alone, at least to me, means something just suboptimal. "Bad practice", on the other hand, means to me, something to be avoided.

Even "bad practice" doesn't mean never do it, but if you do, you should probably have a very good reason for doing it. For instance, we could have two separate areas of the same ID while we're waiting for some new router or link. I.e. it's only temporary.

Your and Edison's posts certainly address the original question "What is the difference between these two topologies?". But, I think, to the (more important) second original question "Why should I change the Area numbers because the areas 1 are not directly connected.", that just "not best practice", perhaps doesn't sufficiently discourage this practice especially in light of the fact it can be done.

Both you and Edison have the experience to fully understand what's good and bad. I believe, many readers of these posts lack that depth of experience, so you have to be careful when noting "it effectively becomes 2 different areas" might imply to many that you can do something not "described in the book", even if "not best practice". I've seen young engineers looking to do things to demonstrate their abilities will sometimes do things "betcha you didn't know you could do that" without full appreciation of other issues that might be caused later on.

257
Views
25
Helpful
12
Replies
CreatePlease to create content