Lessons Learned:
Why Routing loops Occur:
Redistribution causes loss of end-to-end route calculation
and loop prevention
--EX: DUAL not compatible with SPF
Looping cannot occur with single redistribution point
--Internal routing process prevents this
Loops can occur if multiple redistribution points and wrong
path is selected due to –
---Wrong path has lower metric that correct path
---Wrong path has lower AD than correct path
-------------------------------------------------------------
Identifying Routing
Loops
Visually trace the route advertisement path
--Ideally we should be able to predict 100% of the loops
before they occur
CLI tools
-Connectivity testing with ICMP via TCL
-debug ip routing – Will show what protocol the routes are being
learned from, what is the metric value, AD value and whether the route is being
added or deleted over and over. IF the topology is not changing – this is less
likely to be a redist issue.
-ip route profile –Used to collect statistics on the routing
over a period of time.
-traceroute –if packets are bouncing back and forth –
will be an issue.
Normally the issue with redistribution – is that if there is
a loop in the topology, it’s time consuming to find the problem and then
resolution.
Preventing Route
Feedback.
How to prevent looping depends on why loop occurred
Metric based loops
-Fixed with ACL, Prefix-List, or tad filtering and AD
Administrative Distance based loops
-Generally fixed only with AD
------------------------------------------
There are two main categories of Loops. Loops that are based
on the Metric and loops that are based on the distance. The reason we need to
separate the two of them is there are fixed that we can apply to Metric based
loops that will not work on AD based loops.
Metric based loops are the easiest to prevent by filtering
the routes at the redistribution points. We can apply a Tag to the route or manually
specific ACL and prefix list on what routes we don’t want to redist.
With AD based loops – filtering at the redistribution point
will generally not accomplish anything.
There’s a difference when a routing is choosing two routes
inside the same protocol and looking at the metric value vs looking at two
routes form different protocols and looking at the one with the lower AD.
Whether the loops are Metric or AD based – the key is to
look at the network diagram and follow the route advertisement path on a
hop-by-hop basis, to predict for a particular router. What interface is the
route going to come in on, and if it is learning from multiple interfaces and
the same protocol which are we going to choose based on the metric. Also if
it’s coming in through multiple interfaces through multiple protocols which is
it going to choose based on the lower administrative distance.
TOPOLOGY:
--------------------
If you do redistribution across a single router – there’s
really little change if any you can cause a routing loop. When there are multiple
routers preforming redistribution between protocols that’s when you run the
risk of routing loops.
If we have two routes redistributed from two routing
protocols with the same longest match – we’re going to choose the one with the
lower AD.
In the topology I have a currently have a single router
preforming redistributing between RIP and OSPF.
---------------------------------
router eigrp 1
network 172.16.41.4
0.0.0.0
network 172.16.42.4
0.0.0.0
no auto-summary
!
router ospf 1
log-adjacency-changes
redistribute rip subnets
network 10.1.43.4
0.0.0.0 area 0
network 42.42.42.4
0.0.0.0 area 0
!
router rip
version 2
redistribute ospf 1 metric 1
network 192.168.47.0
no auto-summary----------------------------------
Now lets redistribute EIGRP into RIP and EIGRP into OSPF. And
RIP and OSPF into EIGRP.
R4(config)#router rip
R4(config-router)#redistribute eigrp 1 metric 1
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 1 subnets
R4(config)#router eigrp 1
R4(config-router)#default-metric 100000 100 255 1 1500
R4(config-router)#redistribute ospf 1
R4(config-router)#redistribute rip
Note: here I specified the default metric of 100000 100 255 1 1500
100000 – This is the bandwidth = to 100Mbp
100 – delay in tens
of microseconds, if we say 100 that’s equal to 1000 microseconds
255 – this is the reliability = 100% reliable
1 – load – a load of
1 means the minimum load.
1500 – this the MTU – really the only time the MTU will come
into play as a tiebreaker if you have multiple equal routes. Most of the time
the effective MTU will be 1500 or less.
Now once we redistribute the RIP and OSPF we should see them
both getting the same metric.
We can verify local EIGRP topology and see if the RIP and
OSPF Routes are getting redistributed. And they are….
R4#sh ip eigrp
topology
P 10.1.16.0/24, 1 successors, FD is 51200 --OSPF Route
via
Redistributed (51200/0)
P 10.1.43.0/24, 1 successors, FD is 51200 --OSPF
Route
via
Redistributed (51200/0)
P 42.42.42.0/24, 1 successors, FD is 51200
via
Redistributed (51200/0)
P 10.1.36.0/24, 1 successors, FD is 51200 --OSPF
Route
via
Redistributed (51200/0)
P 192.168.47.0/24, 1 successors, FD is 51200 –RIP Route
via
Redistributed (51200/0)
P 172.16.41.0/24, 1 successors, FD is 28160 –EIGRP
LOCAL ROUTE
via Connected,
FastEthernet0/1
P 172.16.42.0/24, 1 successors, FD is 2169856
via Connected,
Serial0/0
P 172.16.25.0/24, 1 successors, FD is 33280
via
172.16.41.1 (33280/30720), FastEthernet0/1
via
172.16.42.2 (2172416/28160), Serial0/0
P 172.16.15.0/24, 1 successors, FD is 30720
via
172.16.41.1 (30720/28160), FastEthernet0/1
R4#
As long as the Metric value is specifics, doesn’t matter what
as long as it’s there and we have the correct process numbers then the redistribution
should be processed locally.
There’s some cases where the routing process gets hung. This
can normally be corrected by clearing the routing table .
EX: R4#clear ip route *
This will repopulate the routing and CEF tables.
So now what is the end result of the redistribution?
If we go to R6 for example – we should see the RIP networks,
EIGRP and local OSPF Networks.
R6#sh ip route
O E2 192.168.47.0/24 [110/20] via 10.1.36.3, 00:37:29,
FastEthernet0/0 –RIP Network
172.16.0.0/24 is
subnetted, 4 subnets
O E2 172.16.41.0
[110/20] via 10.1.36.3, 00:21:04, FastEthernet0/0 –EIGRP Networks
O E2 172.16.42.0
[110/20] via 10.1.36.3, 00:21:04, FastEthernet0/0
O E2 172.16.25.0
[110/20] via 10.1.36.3, 00:21:04, FastEthernet0/0
O E2 172.16.15.0
[110/20] via 10.1.36.3, 00:21:04, FastEthernet0/0 –EIGRP Networks
42.0.0.0/24 is
subnetted, 1 subnets
O 42.42.42.0 [110/66] via 10.1.36.3, 00:37:29,
FastEthernet0/0
10.0.0.0/24 is
subnetted, 3 subnets
C 10.1.16.0 is
directly connected, FastEthernet0/1
O 10.1.43.0
[110/2] via 10.1.36.3, 00:37:31, FastEthernet0/0
C 10.1.36.0 is
directly connected, FastEthernet0/0
R6#
---------------------------------
If we want more visibility as to where the routes are coming
form we can go to redistribution router (R4) and change the Metric type.
Example we can set the Metric type for the redistributed routes to type 1 – so they
show as E1 Routes on R6 now.
EX:
R4(config)#router ospf 1
R4(config-router)#redistribute eigrp 1 metric-type ?
1 Set OSPF External Type 1 metrics
2 Set OSPF External Type 2 metrics
R4(config-router)#redistribute eigrp 1 metric-type 1
% Only classful networks will be redistributed
R4(config-router)#
Note the error
message is because I did not include the subnets keyword.
R4(config-router)#redistribute eigrp 1 metric-type 1 subnets
R4(config-router)#
------------------------------------------------
R6#sh ip route
O E2 192.168.47.0/24 [110/20] via 10.1.36.3, 00:44:05,
FastEthernet0/0
172.16.0.0/24 is
subnetted, 4 subnets
O E1 172.16.41.0
[110/22] via 10.1.36.3, 00:02:09, FastEthernet0/0
O E1 172.16.42.0
[110/22] via 10.1.36.3, 00:02:09, FastEthernet0/0
O E1 172.16.25.0
[110/22] via 10.1.36.3, 00:02:09, FastEthernet0/0
O E1 172.16.15.0
[110/22] via 10.1.36.3, 00:02:09, FastEthernet0/0
42.0.0.0/24 is
subnetted, 1 subnets
O 42.42.42.0
[110/66] via 10.1.36.3, 00:44:05, FastEthernet0/0
10.0.0.0/24 is
subnetted, 3 subnets
C 10.1.16.0 is
directly connected, FastEthernet0/1
O 10.1.43.0
[110/2] via 10.1.36.3, 00:44:06, FastEthernet0/0
C 10.1.36.0 is
directly connected, FastEthernet0/0
R6#
Now we have a clearer picture of where the routes came from.
The route type so far is not going to matter, we’re currently only using one
router as the redistribution point- R4.
The one issue I do have is that R2 is learning routes form
BOTH EIGRP and OSPF. Also all the routes in the routing table are local and not
redistributed or external routes.
Routers in the OSPF Domain can get to local routes on R2 but
not routes behind R2.
The only external route I have is to the RIP Domain, that is
learned from OSPF.
R2#sh ip route
O E2 192.168.47.0/24 [110/20] via 42.42.42.4, 01:03:58,
Serial0/1
172.16.0.0/24 is subnetted,
4 subnets
D 172.16.41.0
[90/33280] via 172.16.25.5, 01:04:52, FastEthernet0/0
C 172.16.42.0 is
directly connected, Serial0/0
C 172.16.25.0 is
directly connected, FastEthernet0/0
D 172.16.15.0
[90/30720] via 172.16.25.5, 01:04:51, FastEthernet0/0
42.0.0.0/24 is
subnetted, 1 subnets
C 42.42.42.0 is
directly connected, Serial0/1
10.0.0.0/24 is
subnetted, 3 subnets
O 10.1.16.0
[110/67] via 42.42.42.4, 01:04:00, Serial0/1
O 10.1.43.0
[110/65] via 42.42.42.4, 01:04:00, Serial0/1
O 10.1.36.0
[110/66] via 42.42.42.4, 01:04:00, Serial0/1
Also if we look at the EIGRP topology table we can see that there
are routes in the topology table but they do not get installed into the routing
table because they do not meet the feasibility condition. I this case – the problem
is because OSPF has a lower administrative distance.
R2#sh ip eigrp
topology
P 10.1.16.0/24, 0
successors, FD is Inaccessible
via 172.16.42.4 (2195456/51200),
Serial0/0
P 10.1.43.0/24, 0
successors, FD is Inaccessible
via
172.16.42.4 (2195456/51200), Serial0/0
P 42.42.42.0/24, 0 successors, FD is Inaccessible
via
172.16.42.4 (2195456/51200), Serial0/0
P 10.1.36.0/24, 0 successors, FD is Inaccessible
via
172.16.42.4 (2195456/51200), Serial0/0
P 192.168.47.0/24, 0 successors, FD is Inaccessible
via
172.16.42.4 (2195456/51200), Serial0/0
P 172.16.41.0/24, 1 successors, FD is 33280
via
172.16.25.5 (33280/30720), FastEthernet0/0
via
172.16.42.4 (2172416/28160), Serial0/0
P 172.16.42.0/24, 1 successors, FD is 2169856
via Connected,
Serial0/0
P 172.16.25.0/24, 1 successors, FD is 28160
via Connected,
FastEthernet0/0
P 172.16.15.0/24, 1 successors, FD is 30720
via
172.16.25.5 (30720/28160), FastEthernet0/0
R2#
If we look at the actual route:
We can see the bandwidth is T1 – the total delay is 21000,
It shows the originating router is R4 (192.168.47.4).
Notice the Metric value should be 2195456 but the FD is 4294967295 which is the infinite value.
So when we see the FD at this value and the actual metric
that has been calculated through the neighbor, this means we’re learning the
route from some other protocol that’s stopping the EIGRP route from being
installed. So because were not learning the route from EIGRP we cannot
advertise the route into EIGRP
R2#sh ip eigrp topology 10.1.16.0/24
IP-EIGRP (AS 1): Topology entry for 10.1.16.0/24
State is Passive,
Query origin flag is 1, 0 Successor(s), FD
is 4294967295
Routing Descriptor
Blocks:
172.16.42.4
(Serial0/0), from 172.16.42.4, Send flag is 0x0
Composite metric
is (2195456/51200), Route is
External
Vector metric:
Minimum
bandwidth is 1544 Kbit
Total delay is
21000 microseconds
Reliability is
255/255
Load is 1/255
Minimum MTU is
1500
Hop count is 1
External data:
Originating
router is 192.168.47.4
AS number of
route is 1
External
protocol is OSPF, external metric is 3
Administrator
tag is 0 (0x00000000)
R2#
Notice – When we s hip route for the prefix. The source
protocol is not EIGRP.
R2#sh ip route 10.1.16.0
Routing entry for 10.1.16.0/24
Known via "ospf 1", distance 110,
metric 67, type intra area
Last update from
42.42.42.4 on Serial0/1, 01:17:08 ago
Routing Descriptor
Blocks:
* 42.42.42.4, from
172.16.41.1, 01:17:08 ago, via Serial0/1
Route metric is
67, traffic share count is 1
R2#
So the issue seems to be that R2 is receiving the OSPF route
and the EIGRP route. The AD of the OSPF route - 110 - is lower than 170 form
EIGRP. So the EIGRP route is not getting installed in the routing table.
To Fix this we can use would need to change the AD on R2 to
prefer the EIGRP Routes.
Note: The AD value is only locally significant. So any
changes will only affect R2.
Also note the with EIGRP we CANNOT change the external AD on
a per prefix basis. OSPF, RIP, or BGP can be change on both internal and
external routes. This only works on EIGRP for internal routes.
So let’s lower the AD on R2 from 170 to anything lower than
110.
From the routing process –
R2(config)#router eigrp 1
R2(config-router)#distance eigrp 90 109 -This basically says, keep the internal
distance at 90 and change the external EIGRP to 109 (one lower than ospf)
Log output:
*Mar 1 01:49:54.391:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.25.5 (FastEthernet0/0) is
down: route configuration changed
*Mar 1 01:49:54.403:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.42.4 (Serial0/0) is down:
route configuration changed
R2(config-router)#
*Mar 1 01:49:58.355:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.25.5 (FastEthernet0/0) is up:
new adjacency
*Mar 1 01:49:58.487:
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.42.4 (Serial0/0) is up: new
adjacency
R2(config-router)#
I will now once again clear the routing table:
We can now see that the external EIGP routes are getting installed
with a distance of 109.
R2#sh ip route
D EX 192.168.47.0/24 [109/2195456] via 172.16.42.4,
00:00:07, Serial0/0
172.16.0.0/24 is
subnetted, 4 subnets
D 172.16.41.0
[90/33280] via 172.16.25.5, 00:00:07, FastEthernet0/0
C 172.16.42.0 is
directly connected, Serial0/0
C 172.16.25.0 is
directly connected, FastEthernet0/0
D 172.16.15.0
[90/30720] via 172.16.25.5, 00:00:07, FastEthernet0/0
42.0.0.0/24 is
subnetted, 1 subnets
C 42.42.42.0 is
directly connected, Serial0/1
10.0.0.0/24 is
subnetted, 3 subnets
D EX 10.1.16.0 [109/2195456] via 172.16.42.4,
00:00:08, Serial0/0
D EX 10.1.43.0 [109/2195456] via 172.16.42.4,
00:00:08, Serial0/0
D EX 10.1.36.0 [109/2195456] via 172.16.42.4,
00:00:08, Serial0/0
R2#
We should now be able to advertise the routes in EIGRP
because they’re now in the routing table.
very complicated
ReplyDelete