troubleshoot than metric based
The best way is to show through a lab again
LAB
---
Ok for the LAB
3 AS one eigrp one ospf and one rip.
R5 is in eigrp,ospf and rip.
R3 is in ospf and eigrp
The process of redistribution is r5 redistributes into eigrp
R3 redistributes into ospf
r5
---
r5#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/20645120] via 10.227.254.3, 00:04:52, FastEthernet0/1
33.0.0.0/24 is subnetted, 1 subnets
D 33.33.33.0 [90/156160] via 10.227.254.3, 00:04:52, FastEthernet0/1
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/158720] via 10.227.254.3, 00:04:52, FastEthernet0/1
4.0.0.0/32 is subnetted, 1 subnets
R 4.4.4.4 [120/1] via 172.25.16.4, 00:00:10, Serial0/1/0
5.0.0.0/24 is subnetted, 1 subnets
C 5.5.5.0 is directly connected, Loopback0
172.25.0.0/24 is subnetted, 2 subnets
C 172.25.16.0 is directly connected, Serial0/1/0
R 172.25.15.0 [120/1] via 172.25.16.4, 00:00:10, Serial0/1/0
22.0.0.0/32 is subnetted, 1 subnets
O 22.22.22.22 [110/3] via 192.168.6.1, 00:00:25, FastEthernet0/0
O 192.168.5.0/24 [110/2] via 192.168.6.1, 00:00:25, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
D 10.229.254.0 [90/20517120] via 10.227.254.3, 00:04:54, FastEthernet0/1
C 10.227.254.0 is directly connected, FastEthernet0/1
C 192.168.6.0/24 is directly connected, FastEthernet0/0
11.0.0.0/32 is subnetted, 1 subnets
O 11.11.11.11 [110/2] via 192.168.6.1, 00:00:25, FastEthernet0/0
O 192.168.1.0/24 [110/2] via 192.168.6.1, 00:00:25, FastEthernet0/0
O 192.168.2.0/24 [110/2] via 192.168.6.1, 00:00:25, FastEthernet0/0
44.0.0.0/32 is subnetted, 1 subnets
O 44.44.44.44 [110/3] via 192.168.6.1, 00:00:25, FastEthernet0/0
r5 has a mix of eigrp,ospf and rip routes we will particular focus on the rip route
4.4.4.4
r5#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "rip", distance 120, metric 1
Redistributing via rip, eigrp 1
Advertised by eigrp 1 metric 100 100 100 100 100
Last update from 172.25.16.4 on Serial0/1/0, 00:00:25 ago
Routing Descriptor Blocks:
* 172.25.16.4, from 172.25.16.4, 00:00:25 ago, via Serial0/1/0
Route metric is 1, traffic share count is 1
it is currently learning this directly from r4 via rip
OK so we will redistribute rip into eigrp
r5(config)#router eigrp 1
r5(config-router)#redistribute rip metric 100 100 100 100 100
r5(config-router)#
we will also redistribute eigrp into rip
s3 should now be able to ping 4.4.4. r4 loopback in the rip domain
switch3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
switch3#
which we can
Ok so now lets redistribute eigrp into ospf
r3
--
r3(config)#router eigrp 1
r3(config-router)#router ospf 1
r3(config-router)#redistribute eigrp 1 subnets
r3(config-router)#
s3
---
switch3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
switch3#
switch 3 has now lost connectivity to 4.4.4.4 r4 loopback lets take a look
it is not even getting a trace route
switch3#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
1 * * *
2 *
switch3#sh ip route 4.4.4.4
% Network not in table
the route has gone from s3 routing table
r5
---
r5#sh ip route 4.4.4.4
% Network not in table
r5#
r5#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
Last update from 192.168.6.1 on FastEthernet0/0, 00:00:03 ago
Routing Descriptor Blocks:
* 192.168.6.1, from 3.3.3.3, 00:00:03 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
r5#sh ip route 4.4.4.4
% Network not in table
r5#
the 4.4.4.4 network is flapping not in table to been learnt via ospf ???
it looks like we have a stabability issue with the routing table lets check with the
ip route profile tool
r5(config)#ip route profile
r5(config)#
r5#sh ip route profile
IP routing table change statistics:
Frequency of changes in a 5 second sampling interval
-------------------------------------------------------------
Change/ Fwd-path Prefix Nexthop Pathcount Prefix
interval change add change change refresh
-------------------------------------------------------------
0 109 109 132 109 132
1 0 0 0 0 0
2 0 23 0 23 0
3 0 0 0 0 0
4 23 0 0 0 0
5 0 0 0 0 0
10 0 0 0 0 0
15 0 0 0 0 0
20 0 0 0 0 0
25 0 0 0 0 0
30 0 0 0 0 0
55 0 0 0 0 0
80 0 0 0 0 0
105 0 0 0 0 0
130 0 0 0 0 0
155 0 0 0 0 0
280 0 0 0 0 0
405 0 0 0 0 0
-------------------------------------------------------------
Change/ Fwd-path Prefix Nexthop Pathcount Prefix
interval change add change change refresh
-------------------------------------------------------------
530 0 0 0 0 0
655 0 0 0 0 0
780 0 0 0 0 0
1405 0 0 0 0 0
2030 0 0 0 0 0
2655 0 0 0 0 0
3280 0 0 0 0 0
3905 0 0 0 0 0
7030 0 0 0 0 0
10155 0 0 0 0 0
13280 0 0 0 0 0
Overflow 0 0 0 0 0
r5#
ok to read this
•Forward-Path Change - This statistic is the number of changes in the forwarding
path, which is the accumulation of prefix-add, next-hop change, and pathcount change
statistics.
•Prefix-Add - A new prefix was added to the routing table.
•Next-Hop Change - A prefix is not added or removed, but the next hop changes. This
statistic is only seen with recursive routes that are installed in the routing table.
•Pathcount Change - The number of paths in the routing table has changed. This
statistic is the result of an increase in the number of paths for an Interior Gateway
Protocol (IGP) prefix in the routing table.
•Prefix Refresh - Standard routing table maintenance; the forwarding behavior is not
changed
r5#sh ip route profile
IP routing table change statistics:
Frequency of changes in a 5 second sampling interval
-------------------------------------------------------------
Change/ Fwd-path Prefix Nexthop Pathcount Prefix
interval change add change change refresh
-------------------------------------------------------------
0 109 109 132 109 132
1 0 0 0 0 0
2 0 23 0 23 0
3 0 0 0 0 0
4 23 0 0 0 0
5 0 0 0 0 0
there has been 109 intervals were nothing changed so 109 x 5 seconds
there
was
2 intervals were 23 changes occured in the interval
4 intervals were 23 changes occured in the interval
The output from this indicates there is stability issue in converged topology there
should be little or not changes
if i check now
r5#sh ip route profile
IP routing table change statistics:
Frequency of changes in a 5 second sampling interval
-------------------------------------------------------------
Change/ Fwd-path Prefix Nexthop Pathcount Prefix
interval change add change change refresh
-------------------------------------------------------------
0 347 349 425 348 425
1 1 0 0 2 0
2 2 76 0 75 0
3 1 0 0 0 0
4 74 0 0 0 0
this value is continioulsy rising
This feature is good for indicating there is an issue but not good for telling
exactly what the iss is
this is where we could use debug ip routing
to see what changes are being made
*Jan 14 16:11:28.651: RT: SET_LAST_RDB for 4.4.4.4/32
NEW rdb: via 172.25.16.4
*Jan 14 16:11:28.651: RT: add 4.4.4.4/32 via 172.25.16.4, rip metric [120/1]
*Jan 14 16:11:28.651: RT: NET-RED 4.4.4.4/32
*Jan 14 16:11:28.651: RT: SET_LAST_RDB for 172.25.15.0/24
NEW rdb: via 172.25.16.4
*Jan 14 16:11:28.651: RT: add 172.25.15.0/24 via 172.25.16.4, rip metric [120/1]
OK so it starts above with a new route been discovered for 4.4.4.4 via 172.25.16.4
(r4) the routing protocol is rip
THis addded to the routing table
*Jan 14 16:11:28.651: RT: NET-RED 172.25.15.0/24
*Jan 14 16:11:28.699: RT: closer admin distance for 4.4.4.4, flushing 1 routes
*Jan 14 16:11:28.699: RT: NET-RED 4.4.4.4/32
*Jan 14 16:11:28.699: RT: SET_LAST_RDB for 4.4.4.4/32
NEW rdb: via 192.168.6.1
*Jan 14 16:11:28.699: RT: add 4.4.4.4/32 via 192.168.6.1, ospf metric [110/20]
*Jan 14 16:11:28.699: RT: NET-RED 4.4.4.4/32
*Jan 14 16:11:28.731: RT: closer admin distance for 172.25.15.0, flushing 1 routes
*Jan 14 16:11:28.731: RT: NET-RED 172.25.15.0/24
*Jan 14 16:11:28.731: RT: SET_LAST_RDB for 172.25.15.0/24
NEW rdb: via 192.168.6.1
*Jan 14 16:11:28.731: RT: add 172.25.15.0/24 via 192.168.6.1, ospf metric [110/20]
Ok we see above that a route 4.4.4.4 has been discovered with smaller admin distance
this is via 192.168.5.1 and it is an opsf route with admin distance of 110 compared
to rip 120
It has flushed the rip route via r4 and added the ospf route via s1 to 4.4.4.4
*Jan 14 16:11:28.731: RT: NET-RED 172.25.15.0/24
*Jan 14 16:11:33.895: RT: del 4.4.4.4/32 via 192.168.6.1, ospf metric [110/20]
*Jan 14 16:11:33.895: RT: delete subnet route to 4.4.4.4/32
*Jan 14 16:11:33.895: RT: NET-RED 4.4.4.4/32
*Jan 14 16:11:33.895: RT: delete network route to 4.0.0.0
*Jan 14 16:11:33.895: RT: NET-RED 4.0.0.0/8
*Jan 14 16:11:33.927: RT: del 172.25.15.0/24 via 192.168.6.1, ospf metric [110/20]
*Jan 14 16:11:33.931: RT: delete subnet route to 172.25.15.0/24
*Jan 14 16:11:33.931: RT: NET-RED 172.25.15.0/24
*Jan 14 16:11:57.131: RT: SET_LAST_RDB for 4.4.4.4/32
ABove we see that r5 has lost the route via s1 to 4.4.4.4 and it is deleteing from
the table
The reason it lost is the route orginates in rip is redistributed to eigrp which
redistributes to ospf r5 is then taking the ospf route since the rip route is not
longer in the routing table since when we redistribute we only redistributes routes
in the routing table the 4.4.4.4 route does not get redistribute into eigrp which in
turn it does not get redistributed into ospf. So the route via ospf is lost
NEW rdb: via 172.25.16.4
*Jan 14 16:11:57.135: RT: add 4.4.4.4/32 via 172.25.16.4, rip metric [120/1]
*Jan 14 16:11:57.135: RT: NET-RED 4.4.4.4/32
*Jan 14 16:11:57.135: RT: SET_LAST_RDB for 172.25.15.0/24
NEW rdb: via 172.25.16.4
the route is then learnt via rip and the process starts over again causing a metric
loop
The way we can repair this is to set
rip admin distance to lower than ospf so it does not prefer
r5
---
r5(config)#router rip
r5(config-router)#distance 109
r5(config-router)#
r5#sh ip route 4.4.4.4
Routing entry for 4.4.4.4/32
Known via "rip", distance 109, metric 1
Redistributing via rip, eigrp 1
Advertised by eigrp 1 metric 100 100 100 100 100
Last update from 172.25.16.4 on Serial0/1/0, 00:00:14 ago
Routing Descriptor Blocks:
* 172.25.16.4, from 172.25.16.4, 00:00:14 ago, via Serial0/1/0
Route metric is 1, traffic share count is 1
we can see it is learning via rip now as the admin distance is 109 compared to 110
s3
---
switch3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
switch3#
No comments:
Post a Comment