I was reading "Optimal Routing Design" by Cisco Press today and a routing loop scenario was described (chapter 2), but they had it all wrong and screwy and it gave me a routing loop in my brain. So I wanted to actually do a similar scenario some justice. This hopefully will be first part in maybe a series of posts that deal with routing loops, since they can be real buggers.
The Topology:
The Scenario:
R2 is hub with R5 and R6 as OSPF neighbors.
R5 and R6 are also EIGRP neighbors with R7.
R7 is redistributing it's serial interface with R8 into the EIGRP domain.
R5 and R6 are mutually redistributing between OSPF and EIGRP.
If R5 and R6 redistribute OSPF into EIGRP with equal metrics, everything stabilizes, even though you have a suboptimal path. This is because External OSPF (AD=110) is preferred over External EIGRP (AD=170). So whichever device (R5 or R6) redistributes R7's serial network into OSPF first, will keep it's route via EIGRP but the other router will learn it via OSPF.
Let's take a look at R5 and R6 OSPF and EIGRP config (there both the same):
R5#show run | sec router ospf|eigrp
router eigrp 1
redistribute ospf 1 metric 1 1 1 1 1
network 150.100.0.0
no auto-summary
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets
network 150.100.100.0 0.0.0.255 area 0
R5#
This results in the following route entries for 150.100.78.0
R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 1 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:10:23 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:10:23 ago, via Serial1/0
Route metric is 20, traffic share count is 1
R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:01:21 ago
Routing Descriptor Blocks:
150.100.56.7, from 150.100.56.7, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
* 150.100.56.5, from 150.100.56.5, 00:01:21 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
R2#trace 150.100.78.7
Type escape sequence to abort.
Tracing the route to 150.100.78.7
1 150.100.100.6 76 msec 72 msec 20 msec
2 150.100.56.7 48 msec * 72 msec
R2#
Notice that R5 has learned the route via OSPF and has advertised it back into EIGRP with the same metric that R7 is originally advertising it with. R6 has installed them both. So far it's not impacting anything.
Now let's suppose we had a task that said R7 should prefer R5 to reach the OSPF domain and you must configure the solution on R5. How could we do that? We could adjust the metric when redistributing. Let's do this by increasing the bandwidth metric on R5:
R5(config)#router eigrp 1
R5(config-router)#redistribute ospf 1 metric 2 1 1 1 1
Now let's look at R6's entry:
R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 1280002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.5 on FastEthernet0/0, 00:01:37 ago
Routing Descriptor Blocks:
* 150.100.56.5, from 150.100.56.5, 00:01:37 ago, via FastEthernet0/0
Route metric is 1280002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 2 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
Its' pointing back to R5!! Let's look at R5:
R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 128
Redistributing via eigrp 1
Advertised by eigrp 1 metric 2 1 1 1 1
Last update from 150.100.100.2 on Serial1/0, 00:15:35 ago
Routing Descriptor Blocks:
* 150.100.100.2, from 6.6.6.6, 00:15:35 ago, via Serial1/0
Route metric is 20, traffic share count is 1
It's still pointing to R2!! Trace from R2:
R2#trace 150.100.78.7
Type escape sequence to abort.
Tracing the route to 150.100.78.7
1 150.100.100.6 40 msec 76 msec 16 msec
2 150.100.56.5 96 msec 28 msec 44 msec
3 150.100.100.2 44 msec 36 msec 44 msec
4 * * *
5 * * *
6 * * *
So...how would you fix it?
R5 and R6 should learn this route via EIGRP...but last time I tried you could not alter AD for specific external routes...but you can do it for OSPF.
access-list 78 permit 150.100.78.0 0.0.0.255
router ospf 1
distance 180 0.0.0.0 255.255.255.255 78
Now the OSPF route will never be preffered but we do have failover should R5 or R6 lose its LAN connection. Doing this on one side actually fixes it, but leaves R6 with a suboptimal route. I prefer to do it on both.
Final verification of the solution:
R5#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:16 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:16 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
R6#show ip route 150.100.78.0
Routing entry for 150.100.78.0/24
Known via "eigrp 1", distance 170, metric 2560002816, type external
Redistributing via eigrp 1, ospf 1
Advertised by ospf 1 subnets
Last update from 150.100.56.7 on FastEthernet0/0, 00:00:12 ago
Routing Descriptor Blocks:
* 150.100.56.7, from 150.100.56.7, 00:00:12 ago, via FastEthernet0/0
Route metric is 2560002816, traffic share count is 1
Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
Reliability 1/255, minimum MTU 1 bytes
Loading 1/255, Hops 1
2#trace 150.100.78.7
Type escape sequence to abort.
Tracing the route to 150.100.78.7
1 150.100.100.6 44 msec
150.100.100.5 104 msec
150.100.100.6 20 msec
2 150.100.56.7 56 msec * 72 msec
R2#
If you know any other scenarios, please let me know.
Monday, November 24, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.