Just as it
may be necessary to run multiple OSPF processes, It may also be necessary to
redistribute routes between them. What happens when two OSPF processes redistribute
routes to each other? The results can be quite surprising.
As shown in
illustration, R1 runs two OSPF processes. R1 learns a network 10.0.0.0/24 from
both routing processes. From OSPF 1 (left) R1 learns it as an inter-area route.
From OSPF 2 (right) R1 learns it as an External route. Which direction would R1
prefer?
A simple
test demonstrates show results can be unpredictable. By shutting down the
interface towards OSPF 1 and turn it back on, R1 prefers E1 route to reach
10.0.0.0/24 via OSPF 2. Subsequently, by resetting the interface towards OSPF
2, R1 prefers inter-area route to reach 10.0.0.0/24 via OSPF 1.
OSPF’s preference of intra-area over
inter-area over external applies to routes learned via
the same process only; it does not apply to routes learned from multiple OSPF
processes.
So what determines preference
between routing processes? It’s Admin Distance. Since the default AD for OSPF
processes are the same, thus the unpredictable results. Therefore the results
can be “swung” by resetting interfaces.
When Administrative Distances are equal, the process that first
installs the route in the routing table wins, regardless of metric and type.
How to make it deterministic?
The key is obviously around AD. But to apply AD properly as a solution, the
desired behavior must be clearly defined. First, identify potentially
overlapping networks, that is, networks that can be advertised by both
processes. Next, how should the network behave for those networks?
If all overlapping networks
should prefer one process, for example, OSPF 1 inter-area should be preferred
over OSPF 2 E1, then AD of OSPF 2 can be increased:
router ospf 2
distance ospf external 120
The diagram illustrates the
result of the fix, routes from OSPF 1 will now be preferred due to
deterministic AD.
If the desired behavior is specific to networks, then AD must be selectively adjusted using filter list. And AD may need to be adjusted on both OSPF processes to arrive at the specific preference for specific networks.
The end results should always be
deterministic and predictable, verified using tests in normal and failure
scenarios.
As a side note, Before Cisco bug ID CSCdw10987 (integrated in Cisco IOS Software Releases 12.2(07.04)S,
12.2(07.04)T, and later), the last process to make an shortest path first
algorithm (SPF) would have won, and the two processes overwrite other routes in
the routing table. Now, if a route is installed via one process, it is not
overwritten by another OSPF process with the same administrative domain (AD),
unless the route is first deleted from the routing table by the process that
initially installed the route in the routing table.
No comments:
Post a Comment