Standard OSPF behaviour
According to the OSPF definition, for a router to behave as an OSPF ABR router, it must have at least two configured areas: one would be the backbone area 0, and the other a specific area used for a group of routers which, due to route summarization or administrative clarity, are placed into a non-backbone area, for example area 10.
If we further say that area 10 is configured as a stub area, by default the ABR router will generate a default route 0.0.0.0/0 for stub area 10.
This is typical behaviour in networks where traffic routing is controlled by the OSPF protocol. How does this look like in SD-WAN?
At first glance, the answer would be that there is no and should be no difference. OSPF as such is not one of the SD-WAN protocols like OMP, and in general it is independent of SD-WAN and is not even aware of the protocols that are part of the SD-WAN setup.
However, OSPF behaviour in a Cisco SD-WAN environment is somewhat different from what is expected.
Design description:
The customer is replacing an existing legacy WAN with SD-WAN, where legacy routers are replaced with cEdges connected to one or more WAN links, in order to later implement AAR policy and perform traffic steering.
On the LAN side at the sites, the customer sometimes has pure Layer 2, where the cEdge is the default gateway for local users, and sometimes has Layer 3 towards the LAN, for example a Layer 3 switch or router. With them, a dynamic routing protocol is established, typically OSPF.
In some cases, the OSPF area in the LAN is an extension of backbone area 0, and in other cases it is a non-backbone area, such as area 10, configured as an OSPF stub area because there is no need for LAN Layer 3 devices to have all inter-area routes in their routing table, and also because route summarization is easier.
On the central side, the legacy Layer 3 router in the LAN had one interface in area 0 and the other in area 10, so it was automatically an ABR for area 10. The reason historically was that central site users were treated the same as any other site, and only the WAN and DC parts of the network were in OSPF area 0.
The new cEdge device on the LAN side was connected only to area 10, and did not have any interface in another OSPF area, and therefore not in backbone area 0 either.
The design description does not indicate anything unusual or something that should impose limitations compared to the legacy setup. However, it is not exactly like that.
Result:
After the cEdge router was configured via vManage as a router in OSPF stub area 10, it started behaving as an ABR router by generating a default route for area 10. This assumes that the cEdge is connected with one interface to backbone area 0, but this was not the case.
The cEdge ignored the default route it was receiving from the legacy ABR, which is expected behaviour when a default route is received from another ABR via a non-backbone area.
The first assumption was that probably due to OMP, which redistributes routes that are external in OSPF, it considers itself an ABR. However, in that case it would consider itself an ASBR, not an ABR, and to make things even more interesting, OMP peering was not even established.
The truth is that the cEdge considers itself connected to area 0, some kind of superbackbone. And in the case when we configure another interface into an OSPF non-backbone area, it will consider itself an ABR and start generating a default route. This is generally not a problem for a legacy router acting as an ABR, but it becomes a problem for other routers in area 10, which then receive a default route both from the cEdge and from the legacy ABR.
Workaround:
Therefore, forget about configuring multiple OSPF areas in the classic sense, and instead design everything as extensions of area 0, which will also require adjustments in the legacy network for service VPNs, LANs.
What does Cisco say:
For such OSPF behaviour in SD-WAN environments, I am not aware of any Cisco document that clearly describes this behaviour, except the general statement that OSPF must be configured in area 0, but without explaining why.
This raises the question: why does the vManage GUI even allow configuration of any OSPF area other than area 0?