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