This document is not restricted to specific software and hardware
versions.

The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.

In the above topology, R4's E1/0 is in
Area 1 and E0/0 is in Area 0. Therefore, R4 is an Area Border Router (ABR)
advertising the network 10.0.1.0/24 as the inter-area (IA) route to R1 and R2.
R1 and R2 are redistributing this information into OSPF 2. The
redistribute configuration commands are highlighted
in the above configurations of R1 and
R2. Therefore, both R1 and R2 are going to learn
about 10.0.1.0/24 as IA via OSPF 1 and as external type 2 (E2) via OSPF 2
because the external link-state advertisements (LSAs) are propagated throughout
the OSPF 2 domain.

Since IA routes are always prefered over E1 or E2 routes, the
expectation is to see, in the routing table of R1 and R2, that 10.0.1.0/24 is
an IA route with next-hop R4. However, when viewing their routing tables,
something different is seen - on R1, 10.0.1.0/24 is an IA route with next-hop
R4 but on R2, 10.0.1.0/24 is an E2 route with next-hop R1.

When enabling multiple OSPF processes on a router, from the software
perspective, the processes are independent. OSPF protocol, inside one OSPF
process, always prefers the Internal route over the External route. However,
OSPF does not do any OSPF route selection between processes (for instance, OSPF
metrics and route types are not taken into account, when deciding the route of
which process should be installed into the routing table).

There is no interaction betweeen different OSPF processes, and the
tie-breaker is the administrative distance. Thus, since both OSPF processes
have a default administrative distance of 110, the first process trying to
install that route makes it into the routing table. Therefore, adminstrative
distance for routes from different OSPF processes must be configured, so that
routes of certain OSPF processes are preferred over routes of another process
by human intention, and not as a matter of chance.

Since we know that in the above case, the routers are selecting the
best route based on administrative distance, the logical way to prevent this
behavior is to increase the administrative distance of the external routes in
OSPF 2. This way, routes learned via OSPF 1 will always be preferred over
external routes redistributed from OSPF 1 into OSPF 2. This is done using the
sub-router configuration command distance ospf external
<value> as shown in the
configurations below.

It is important to note that in some cases, when there is also
redistribution from OSPF 2 into OSPF 1 and there are other routing protocols
being redistributed into OSPF 2 (Routing Information Protocol [RIP], Enhanced
Interior Gateway Routing Protocol (EIGRP) statics, and so forth), this can lead
to subobtimal routing in OSPF 2 for those external routes.

If the ultimate reason to implement two different OSPF processes is to
filter certain routes, there is a new feature in Cisco IOS® Software Release
12.2(4)T called OSPF ABR Type 3 LSA Filtering which allows you to do route
filtering in the ABR.

Instead of configuring a second OSPF process, the links that are part
of OSPF 2, in the example above, could be configured as another area inside
OSPF 1. Then, you can implement the required route filtering in R1 and R2 with
this new feature. For more information about this feature, refer to
OSPF
ABR Type 3 LSA Filtering.