I will start this article with one of the most important rule in OSPF regarding the best path selection: for the same prefix, OSPF uses the following order:
But in the above scenario, in regards to
net A (220.127.116.11/24 = Lo1 on R3), this rule is not very useful on R1 (or R2). Why?
- net A (18.104.22.168/32) from R3 as
intra-area (O) in OSPF process-id 1
- net A (22.214.171.124/32) from R2 as
external (O E2) in OSPF process-id 2
Since the process-id is different, R1 cannot apply the above mentioned rule, so in this case it treats them as coming from 2 different routing protocols. What happens when the router receives same prefix from 2 different routing protocols? It compares the Administrative Distance.
But in our case, the AD is same (110) for both internal OSPF Pid 1 and external OSPF Pid 2... so, it comes down to a race condition: whatever route is learned first it will be inserted into the routing table.
Now, the above process occurs also on R2, not only on R1... So, what happens if the OSPF database exchange with R3 takes longer on R1 (comparing to R2). All this results in suboptimal routing on R1 (or R2) seen here:
R1#trace 126.96.36.199 Type escape sequence to abort. Tracing the route to 188.8.131.52 1 172.16.1.2 20 msec 44 msec 16 msec 2 192.168.1.3 40 msec 56 msec 20 msec
The problem becomes worse if the source of Net A (184.108.40.206/32), R3, looses OSPF peering with R1/R2 as this will cause a routing loop for Net A (shutdown fa0/0 on R3, as shown in the quiz):
R4#traceroute 220.127.116.11 Type escape sequence to abort. Tracing the route to 18.104.22.168 1 172.16.1.2 68 msec 20 msec 20 msec 2 192.168.1.1 36 msec 48 msec 32 msec 3 172.16.1.2 52 msec 32 msec 20 msec 4 192.168.1.1 20 msec 56 msec 52 msec 5 172.16.1.2 40 msec 60 msec 52 msec 6 192.168.1.1 108 msec 44 msec 68 msec 7 172.16.1.2 68 msec 96 msec 68 msec
...and so on...
How could we solve this? Well, remember where the problem started in the first place: comparing the AD of internal OSPF Pid-1 with the AD of external OSPF Pid-2. To solve this problem there are more options, but let's start by configuring both OSPF processes to have a higher AD for external routes:
router ospf 1 redistribute ospf 2 subnets
distance ospf external 222! router ospf 2 redistribute ospf 1 subnets distance ospf external 222
This solves the initial problem, but introduces the same situation for any external prefixes learned via either OSPF Pid 1 or OSPF Pid 2 => those prefixes may be reached via suboptimal path or may loop indefinetely (see in the above picture the External Net X learned via OSPF Pid 1)
The solution to the new problem could be to configure different AD for the OSPF processes:
router ospf 1 redistribute ospf 2 subnets
distance ospf external 199! router ospf 2 redistribute ospf 1 subnets distance ospf external 222
This will solve the problems for any external prefix (see Net X) learned via OSPF Pid-1, but will not solve the problem for any external prefix (see
In the end, the solution will be to combine setting the administrative distance with a filtering method. You have you match the prefixes from one domain (with an ACL or a tag) and keep them from being re-advertised into the domain they originated from.
Let's see the solutions in detail:
Solution 1: different AD + filtering based on ACLs
Using the above configuration, you configure ACLs matching all prefixes originated or learned in each OSPF process:
router ospf 1 redistribute ospf 2 subnets route-map OSPF_DOMAIN_2 distance ospf external 222 ! router ospf 2 redistribute ospf 1 subnets route-map OSPF_DOMAIN_1 distance ospf external 222 ! route-map OSPF_DOMAIN_2 permit 10 match ip address 2 ! route-map OSPF_DOMAIN_1 permit 10 match ip address 1 ! access-list 1 permit 22.214.171.124 access-list 1 <net X>
# all routes from OSPF Pid-1 (including external ones)! access-list 2 <net Y> # all routes from OSPF Pid-2 (including external ones)
Variant solution 1.1: instead of setting the AD for all external prefixes, you may opt to set the AD to prefixes identified by ACLs with command
distance 222 0.0.0.0 255.255.255.255 <acl>
Solution 2: filtering based on route tags
During the redistribution, you can set tags so all
Depending on whether the redistributed routing domains have the same AD (as in our case) or different (let's say: OSPF and EIGRP), you may need to perform filtering while installing/accepting the tagged prefixes in the routing table OR you may perform the filtering of the tagged prefixes while performing a new redistribution (back into the original domain).
Filtering the tagged routes while installing into the routing table works in all situations because if a route is not installed in the routing table, it will also not be redistributed back into the original domain=> hence you'll not create a routing loop.
router ospf 1 redistribute ospf 2 subnets tag 2 distribute-list route-map DENY_TAG_2 in ! route-map DENY_TAG_2 deny 10 match tag 2 route-map DENY_TAG_2 permit 20 ! ! router ospf 2 redistribute ospf 1 subnets tag 1 distribute-list route-map DENY_TAG_1 in ! route-map DENY_TAG_1 deny 10 match tag 1 route-map DENY_TAG_1 permit 20
Variant solution 2.1
A variant solution is to perform the filtering during the redistribution (
redistribute ospf <pid> subnets route-map DENY_TAG_X
- Pro: R1 / R2 will accept each other's prefixes (see above Cons)
- Con: suboptimal routing for R1/R2 due to the fact that they accepts each other's routing
Solution 3: Filter redistributed prefixes with a AD of 255
In previous solution, redistribution routers were filtering the redistributed prefixes based on tags. This time, we can do the same filtering by setting the administrative distance to 255 - so, we'll setup the following rule: on all redistribution points/routers (in our case, R1 & R2), do not accept any prefix that is learned from the other/redundant redistribution routers:
R1 router ospf 1 redistribute ospf 2 subnet distance 255 126.96.36.199 0.0.0.0 ACL_DOMAIN_2 ! ip access-list stand ACL_DOMAIN_2
... # prefixes learned via Pid-2! router ospf 2 redistribute ospf 1 subnet distance 255 188.8.131.52 0.0.0.0 ACL_DOMAIN_1 ! ip access-list stand ACL_DOMAIN_1 ... # prefixes learned via Pid-1
R2 router ospf 1 redistribute ospf 2 subnet distance 255 184.108.40.206 0.0.0.0 ACL_DOMAIN_2 ! ip access-list stand ACL_DOMAIN_2
... # prefixes learned via Pid-2! router ospf 2 redistribute ospf 1 subnet distance 255 220.127.116.11 0.0.0.0 ACL_DOMAIN_1 ! ip access-list stand ACL_DOMAIN_1 ... # prefixes learned via Pid-1
Again, same as the previous solution, this one also has the drawbacks of maintaining ACLs for each routing domain plus the fact that
As always, posts about OSPF are veeery long, but hopefully useful.
Thanks for your comments on the initial quiz.