NOTE: These lines are an integration of this article read it before moving on.
Let’s look at some routing tricky loop caused by auto-summary, redistribution and filtering:
1) Route-Server knows about
104.219.202.48/29 is directly connected, Loopback10053
104.54.143.0/24 is directly connected, Loopback10100
2) Then it redistributes connected routes into RIP so it put networks in database:
Routes-Server#show ip rip database 104.219.202.48 255.255.255.248
104.219.202.48/29 redistributed
[1] via 0.0.0.0
Routes-Server#show ip rip database 104.54.143.0 255.255.255.0
104.54.143.0/24 redistributed
[1] via 0.0.0.0
NOTE: Routes are marked as they were already one rip hop away [1] (because they are learned by redistribution into RIP)
3) RIP has auto-summary enabled, so Route-Server – crossing different classful networks – creates a summary for the classful 104.0.0.0/8
Routes-Server#show ip rip database 104.0.0.0 255.0.0.0
104.0.0.0/8 auto-summary –> I don’t see any info about hop count – but from a debug I see:
Routes-Server#
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.0.254)
RIP: build update entries104.0.0.0/8 via 0.0.0.0, metric 1, tag 0
4) On R3 I receive update from Route-Server about the summary, update comes in with one hop count, so R2 puts the update in its database and adds 1 when sending out the information
R3#
RIP: received v2 update from 10.0.0.254 on FastEthernet0/0 104.0.0.0/8 via 0.0.0.0 in 1 hops
R3#show ip rip database 104.0.0.0 255.0.0.0
104.0.0.0/8
[1] via 10.0.0.254, 00:00:07, FastEthernet0/0
R3#show ip route 104.0.0.0
Routing entry for 104.0.0.0/8
Known via “rip”, distance 120, metric 1
Redistributing via rip
Last update from 10.0.0.254 on FastEthernet0/0, 00:00:19 ago
Routing Descriptor Blocks:
* 10.0.0.254, from 10.0.0.254, 00:00:19 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
Then R3 advertises it to R2 (not back to Route-Server due to split-horizon rule)
R3#
RIP: sending v2 update to 224.0.0.9 via FastEthernet1/1 (10.0.2.3) 104.0.0.0/8 via 0.0.0.0, metric 2, tag 0
5) R2 is discarding update about 104.0.0.0/8 from Route-Server (due to the distribute-list) but it learns about it from R3:
R2#show ip rip database 104.0.0.0 255.0.0.0
104.0.0.0/8
[2] via 10.0.2.3, 00:00:03, FastEthernet1/1 –> 2 Hops Away
R2#show ip route 104.0.0.0
Routing entry for 104.0.0.0/8
Known via “rip”, distance 120, metric 2
Redistributing via rip
Last update from 10.0.2.3 on FastEthernet1/1, 00:00:10 ago
Routing Descriptor Blocks:
* 10.0.2.3, from 10.0.2.3, 00:00:10 ago, via FastEthernet1/1
Route metric is 2, traffic share count is 1
R2 updates Route-Server about the network, telling it that net 104.0.0.0/8 can be reached through itself in 3 hops.
R2#
*Mar 1 00:07:03.359: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.0.6.2)
*Mar 1 00:07:03.359: RIP: build update entries *Mar 1 00:07:03.367: 104.0.0.0/8 via 0.0.0.0, metric 3, tag 0
6) Route-Server receives this update from R2, so now it has 2 info about 104.0.0.0/8
104.0.0.0/8 auto-summary and
Routes-Server#
*Mar 1 00:32:32.227: RIP: received packet with text authentication due#
*Mar 1 00:32:32.227: RIP: received v2 update from 10.0.6.2 on FastEthernet0/1
*Mar 1 00:32:32.231: 104.0.0.0/8 via 0.0.0.0 in 3 hops
Routes-Server#show ip rip database 104.0.0.0 255.0.0.0
104.0.0.0/8
[3] via 10.0.6.2, 00:00:03, FastEthernet0/1
Which information does it trust? The autosummary is here only because it is summarizing, so it trusts info from R2?
Let’s check with debug messages:
Routes-Server#
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (10.0.0.254)
RIP: build update entries 104.0.0.0/8 via 0.0.0.0, metric 2, tag 0
R3#
RIP: received v2 update from 10.0.0.254 on FastEthernet0/0 104.0.0.0/8 via 0.0.0.0 in 2 hops
From the debug message above I see that what happens is an hybrid thing, Route-Server doesn’t send an update with metric 4 (received 3 + 1) but it adds 1 to the metric it was sending before knowing the route from another external source (R2), in other words it sends metric 2 as I can see from debug messages
Then R3 sends a new update to R2:
RIP: sending v2 update to 224.0.0.9 via FastEthernet1/1 (10.0.2.3)
RIP: build update entries 104.0.0.0/8 via 0.0.0.0, metric 3, tag 0
Then R2 sends a new update to Route-Server saying that it can reach 104.0.0.0/8 in 4 hops
R2#
RIP: sending v2 update to 224.0.0.9 via FastEthernet0/1 (10.0.6.2)
RIP: build update entries 104.0.0.0/8 via 0.0.0.0, metric 4, tag 0
At last, Route-Server will say:
Routes-Server#
RIP: received packet with text authentication due#
RIP: received v2 update from 10.0.6.2 on FastEthernet0/1 104.0.0.0/8 via 0.0.0.0 in 4 hops
Routes-Server#show ip rip database 104.0.0.0 255.0.0.0
104.0.0.0/8
[4] via 10.0.6.2, 00:00:00, FastEthernet0/1
Here it’s easy to think about a growing routing-loop, because now this 4 hops will become 5 hops at R3, 6 hops at R2, 7 hops at Route-Server and so on. Instead IOS breaks the loop protecting Route-Server in this way –
– If you are originating summary route
Routes-Server#show ip rip database 104.0.0.0 255.0.0.0
104.0.0.0/8 auto-summary
– Trust an update about the same prefix from an external source only one time, then ignore the successive updates from the same source if metric is worse.
Here the loop breaks when Route-Server receives, at second iteration of update, a metric of 4 hops from R2 worse than the previous one (3) from the same R2. Route-Server will not add another 1 to the outgoing update to R3, it still advertise metric 2 to R3, this what I see in routing table of Routers when network is converged:
Routes-Server#show ip route 104.0.0.0 255.0.0.0
Routing entry for 104.0.0.0/8
Known via “rip”, distance 120, metric 4
Redistributing via rip
Last update from 10.0.6.2 on FastEthernet0/1, 00:00:03 ago
Routing Descriptor Blocks:
* 10.0.6.2, from 10.0.6.2, 00:00:03 ago, via FastEthernet0/1
Route metric is 4, traffic share count is 1
R2#show ip route 104.0.0.0 255.0.0.0
Routing entry for 104.0.0.0/8
Known via “rip”, distance 120, metric 3
Redistributing via rip
Last update from 10.0.2.3 on FastEthernet1/1, 00:00:03 ago
Routing Descriptor Blocks:
* 10.0.2.3, from 10.0.2.3, 00:00:03 ago, via FastEthernet1/1
Route metric is 3, traffic share count is 1
R3#show ip route 104.0.0.0 255.0.0.0
Routing entry for 104.0.0.0/8
Known via “rip”, distance 120, metric 2
Redistributing via rip
Last update from 10.0.0.254 on FastEthernet0/0, 00:00:26 ago
Routing Descriptor Blocks:
* 10.0.0.254, from 10.0.0.254, 00:00:26 ago, via FastEthernet0/0
Route metric is 2, traffic share count is 1
From the routing table I can see a very trick and corner case where the original sourcing router (Route-Server) has the worse metric between the three. Network is converged but things are not safe at all, see here:
I have generated a Routing Loop.
Even if software counted to infinity (accepting increasing metric at each iteration), loop would not be stopped, it would take more times to converge to 16 hops, then entry will be flushed and loop would restart from the beginning. The problem here is that I used auto-summary, redistribution and filtering in a not controlled way.
To avoid problem when feeding back routes, it’s wise to block redistribution back to Route-Server from R2 and R3. In the example above I triggered a loop making R2 discarding update from Route-Server with a distribute-list, in a more real scenario this could happen if the link between Route-Server and R2 becomes unidirectional with R2 transmitting to, but not receiving from Route-Server.