Step 8. Hold-down timer¶
Goals¶
Demonstrate that routing loops can be prevented by using holddown (and the holddown timer) in cases when other methods, such as split horizon / splithorizon with poisoned reverse are not effective.
The model¶
This step uses the same network as the previous one.
The configuration in omnetpp.ini
is the following:
[Config Step8]
description = "Garbage-collection (hold-down) timer"
extends = Step7
# Enabling split horizon with/without poison reverse alone does not solve the problem
# -> because there are loops -> a router does not send the update to where it received
# it from, but another router in the loop can.
# But we have seen this in step7 so split horizon is not needed here (actually,
# does not make a difference, but it is easier to demonstrate hold-down without it)
#*.router*.rip.ripConfig = xml("<config> <interface hosts='router*' mode='SplitHorizon' /> </config>")
# without split horizon, router2 sends the no longer working route to router3, with a
# metric of 3.
# since the route in router3 is in hold-down, it does not update it -> it might be more
# visible this way.
*.router*.rip.holdDownTime = 30s
Results¶
The 10.0.0.24/29 network becomes unreachable, the route in router1 is set to metric 16. This is propagated to router3 (it also sets the route to 10.0.0.24/29 to metric 16). The update from router2 contains the route with metric 3, but its not updated in router1 because the route is in holddown. (TODO: this is essentially the same as the paragraph below)
Thus routing loops are prevented.
On the following image, router2
sends a RIP Response message to
router3
. The message contains the route to the (currently
unreachable) 10.0.0.24/29 network, with a metric of 3. Also, router3
has a route to the network with a metric of 16. The route will not be
updated in router3
, as the route is in holddown. The details of the
RIP Response message and router3
’s RIP table are highlighted (click
on the image to enlarge):
Sources:
omnetpp.ini
,
RipNetworkC.ned