OSPF route discrimination based on distance
Devices are connected using 100.device1device2.0.0/24
Loops: R1 - 1.1.1.1, R2 - 2.2.2.2, R3 - 3.3.3.3, 33.33.33.33
OSPF network P2M for interconnects, LOOP for loops
Goal: Make R1 choose R2 to reach 3.3.3.3. Do not affect other routes. Incase R2 goes down, R1 should use R3.
Given that ospf cost affects all routes, distribute-list disables backup path, there's seemingly no other option but to use distance with ACL as so -
R1:
distance 111 3.3.3.3 0.0.0.0 LOOP
!
ip access-list standard LOOP
permit 3.3.3.3
Looking at the output, results are as unexpected:
R1#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 111, metric 2, type intra area
Last update from 100.13.0.3 on GigabitEthernet1.13, 00:17:52 ago
Routing Descriptor Blocks:
* 100.13.0.3, from 3.3.3.3, 00:17:52 ago, via GigabitEthernet1.13
Route metric is 2, traffic share count is 1
shutting the link down produces alternative:
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 100.12.0.2 on GigabitEthernet1.12, 00:00:03 ago
Routing Descriptor Blocks:
* 100.12.0.2, from 3.3.3.3, 00:00:03 ago, via GigabitEthernet1.12
Route metric is 3, traffic share count is 1
OSPF DB:
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 3.3.3.3
(Link Data) Router Interface address: 100.23.0.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
Advertising Router: 3.3.3.3
LS Seq Number: 8000000B
Checksum: 0x8364
Length: 108
Number of Links: 7
Link connected to: a Stub Network
(Link ID) Network/subnet number: 3.3.3.3
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
So, when both paths are available, R1-R3 is still preffered, even though R1-R2-R3 is available via AD 110. How could this be explained?
Comments
Hi Daqua,
Nice verification testing.
The problem is that the cost is lower for the direct path. OSPF will choose 2 over 3.
The AD will come into play after the OSPF route is offered to the RIB.
The route would then be compared to any other routing-protocols.
OSPF always bothered me in these scenarios. I always want to think that there is a way to do this in a sincle area, and I always go looking for an offset-list (thinking EIGRP). But OSPF doesn't have offset-lists.
Maybe I am forgetting the trick, but I don't think it is possible. You already outlined the caveats for each approach.
Anyone else with an idea for how to do this?
What are the restrictions? Do all routers have to be in the same area? Are you allowed to use multiple OSPF processes?
Regarding AD, is this OSPF specific?
Swapping protocol with EIGRP, it works as one would expect -
1) all paths available:
R1(config-router)#do show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "eigrp 1", distance 90, metric 131072, type internal
Redistributing via eigrp 1
Last update from 100.12.0.2 on GigabitEthernet1.12, 00:00:13 ago
Routing Descriptor Blocks:
* 100.12.0.2, from 100.12.0.2, 00:00:13 ago, via GigabitEthernet1.12
Route metric is 131072, traffic share count is 1
Total delay is 5020 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
2) link to R2 shut down:
Routing entry for 3.3.3.3/32
Known via "eigrp 1", distance 100, metric 130816, type internal
Redistributing via eigrp 1
Last update from 100.13.0.3 on GigabitEthernet1.13, 00:00:04 ago
Routing Descriptor Blocks:
* 100.13.0.3, from 100.13.0.3, 00:00:04 ago, via GigabitEthernet1.13
Route metric is 130816, traffic share count is 1
Total delay is 5010 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
cristian.matei, as you noted, both using different areas and process IDs can solve this problem. I'd say that issue is closed, I'm much more intrigued why distance command behaves differently, if as JoeM noted, AD discimination is applied only to routes in RIB
Sent from my iPhone
On Jul 1, 2015, at 19:13, daqua <[email protected]> wrote: