Step 4. Timeout Timer and Garbage Collection Timer¶

Goals¶

In this step, we will demonstrate the operation of timeout and garbage-collection timers.

Routers talk to their neighbours regularly to update them about the changes in their routing tables. Every time a router receives one of these messages from one of its neighbours, it resets a timeout timer associated with this route. If these messages stop coming, the timer expires (its default value is 180 seconds), and the router marks this route as unreachable. However, it keeps the route in its routing table, and starts a garbage-collection timer. It deletes the route when the garbage-collection timer expires (its default value is 120 seconds).

Network Configuration¶

Our network configuration is the same as the one we used in the earlier steps.

The omnetpp.ini configuration is listed here:

[Config Step4A]
description = "RIP timers: Link comes back online before the timeout timer expires"
extends = Step2

# Enable split horizon in order for the scenario to work properly
*.router*.rip.ripConfig = xml("<config> \
<interface hosts='router*' mode='SplitHorizon' /> \
</config>")
# disable ping application
*.host0.numApps = 0

# Break the router2 <--> switch1 link at t=50 s. and reconnect at t=150 s.
*.scenarioManager.script = xmldoc("scenario5.xml")


Experiments¶

To observe how RIP behaves, we introduce a breakdown by disconnecting the link between router2 and switch1 at t = 50s, and simulate three possible scenarios in which the link becomes operational again:

1. Before the timeout timer associated with its routing table entry expires,

1. After the timeout timer expires but before the garbage-collection timer expires, and

1. After both timers expire, and the link is purged from the routing table.

We run these cases one by one. Their omnetpp.ini configuration sections are Step4A, Step4B and Step4C, respectively. These configurations are identical apart from the scenario script they refer to.