Will any issues occur if I have a topology involving 3 subnets and two OSPF areas where one subnet is in AREA 0 and the other two subnets are both in AREA 1?

For example:

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]
  • three different routers? If so, please include details for which area the links between the routers are in. OSPF puts links in a single area, and the areas must match on both sides of the link Aug 20, 2013 at 17:12
  • @Mike Pennington - are you looking for the OSPF network statements in the ABRs as well? I'm talking about a configuration without any virtual links btw.
    Aug 20, 2013 at 20:49
  • Yes, there are 3 different routers as follows: [area 1 network, subnet 1]---[Router #1]---[area 0 network, subnet 2, end device #1]---[Router #2]---[area 0 network, subnet 2, end device #2]---[Router #3]---[area 1 network, subnet 3]
    Aug 21, 2013 at 3:27

3 Answers 3


Regarding the question of splitting area 1 across the backbone (area 0):

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

[area 1, subnet 1]---[Router #1]---[area 0, subnet 2, end device #1]---[Router #2]---[area 0, subnet 2, end device #2]---[Router #3]---[area 1, subnet 3]

Short answer: There is no problem with your proposal...

Long answer:

Even Peter's answer, which argues that reusing area numbers is bad design, offers no proof that this is a bad design; if you examine the hyperlinks he used, there is no explanation of undesirable consequences for this design. Furthermore, the argument that you might have problems connecting R1 and R3 falls short, since the R1 to R3 link could legitimately be configured in either Area 0 or Area 1, depending on what traffic you want to transit it. The difficulties he mentions are a false dilemma.

In RFC 2328, Section 3.7 OSPF explicitly allows you to use discontiguous non-backbone areas (which are called "area partitions", below):

    OSPF does not actively attempt to repair area partitions.  When
    an area becomes partitioned, each component simply becomes a
    separate area.  The backbone then performs routing between the
    new areas.  Some destinations reachable via intra-area routing
    before the partition will now require inter-area routing.
    ...  Also, the backbone itself must not partition.

Thus whether you use the proposed discontiguous Area 1 is just a matter of taste... some people find it illogical to use the configuration in your diagram; these people might suggest that you keep OSPF area numbers together... so you'd have to change [area 1, subnet 3] on Router #3 to [area 3, subnet 3]. Other people see no problem with reusing Area 1, since OSPF area numbers are only locally significant to the router originating OSPF hellos.

Either way, we should admit that OSPF is a remarkably flexible protocol; regardless of choosing one side or another in this debate.

  • 1
    FYI this design (discontiguous area 1) is in production use in certain military networks. A unit deploying to a remote site which will connect back to the hub site ABR via DMVPN is given a router with a standard config. At most they will change one or two IP addresses on the router. It is questionable whether this is "best practice" but it works and it's easy for non-specialists to deploy.
    – user2668
    Sep 16, 2013 at 15:11
  • @user2668 High level military policy does not promote this in production networks. Although "special" organizations (note the rabbit ears) tend to do what they want, when they want, this certainly isn't the norm. I can say, for certain, that there are branches that promote single area 0 OSPF designs exclusively, to limit design complexity.
    – Ryan Foley
    Mar 28, 2014 at 12:46

This will work but it would be a poor design choice (IMHO) unless you have a specific reason for doing so.

See this discussion: Duplicate OSPF area IDs

OSPF Best Practicies

Recommended OSPF configuration best-practices (using the SSM example)

OSPF area configuration best practices

Update #1:

For the sake of completeness, I mocked up this situation using dyanmips. The platform was Cisco 3725s running IOS ver 12.4(15)T13.

R1 (lo0, f0/0 <-> R2 (lo0, f0/0, f0/1 <-> R3 (lo0, f0/0

Loopback interfaces of R1 & R3 were placed in area 1, all other interfaces are in area 0.

Pings were then done (e.g. R3#ping ip source between the R1 & R3 boxes confirming connectivity.

In my opinion I would still shy away from this architecture. Mike makes perfectly valid points (and testing confirms) that this works. OSPF areas are useful tools to control route propagation and reduce the size of the router's link state database - but they also function (to me at least) to document that I intend "this" part of the network to be separate architecturally from "that" part of the network for some reason.

If in the future you decide to connect R1 to R3 and are using the same area # then you have lucked out and backed into saving yourself a lot issues with changing area numbers or having to use virtual links. So maybe this is an argument in favor of using two area IDs (0 & 1) everywhere - but then again you did not originally intend R1 and R3 to be able to communicate directly. shrug

This is a matter of style and personal preference - there appears to be no technical reason why this shouldn't work and I never intended to represent otherwise.

Update #2

Adding non-ascii art diagram of connections - drawn linearly and as a triangle. What is intended between R1 & R3? Is area1 supposed to be contiguous or separate?

enter image description here

  • The reasoning is to reduce the amount of OSPF traffic occurring between different parts of the AS. I took a look at all your links and don't know if I missed something, but why is it a poor design choice for the purpose I mentioned?
    Aug 21, 2013 at 3:32
  • 1
    @Peter, other than Richard Burt's answer, I can't find anything in your links that suggest that discontiguous non-backbone areas are a problem... and Richard's answer was refuted by Russ White's answer to the same question. The link you mention pointing to OSPF area configuration best practices says nothing about a discontiguous area that I could find. Could you elaborate some more on the answer? Aug 21, 2013 at 7:44
  • @Mike Pennnington - There is no technical reason why you can't use discontinuous OSPF areas, but there are a lot of practical ones. Maintaining your environment and troubleshooting among others. Like comments in your code, not necessary but it makes your life much easier later.
    – Peter
    Aug 21, 2013 at 12:17
  • 1
    @Peter, that is exactly the point, you havent proven it is less clear... just because you don't like it doesnt make it a problem for the rest of the world... at this point, I am starting to hear that you have no evidence to support your argument Aug 21, 2013 at 15:39
  • 1
    You do areas to limit broadcast domains, if you do area 1 and area 1 prime you are depending on a physcial separation, as both area 1s cannot live in the same router or the flooding domain doubles. If you have area 1 and area 2 you can have a router that has both areas and area 0 and double your SPF domain. You just have more flexability buy not using the same number. Maybe not megatons more but still depening on your specfic topology you can create some problems
    – fredpbaker
    Aug 21, 2013 at 19:38

Well you normally need to use virtual links to talk to area 0 via a different non area 0 area or you connect 2 parts of area 0 through a non zero area. So virtual links do not apply. You can have a non contigious area if its not area 0, but as hinted above, not really a good idea. That being said you proposed topology will work without virtual links.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.