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:
Before the timeout timer associated with its routing table entry expires,
After the timeout timer expires but before the garbage-collection timer expires, and
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.
A: Link becomes operational before the timeout timer expires¶
We break the link connecting router2
to switch1
at t = 50s, and
reconnect at t = 150s. This is written in the scenario5.xml
file:
<!-- scenario5.xml -->
<scenario>
<at t="50">
<disconnect src-module="router2" dest-module="switch1" />
</at>
<at t="150">
<connect src-module="router2" src-gate="ethg$o[0]" dest-module="switch1" dest-gate="ethg$i[3]" channel-type="inet.node.ethernet.Eth10M" />
<connect src-module="switch1" src-gate="ethg$o[3]" dest-module="router2" dest-gate="ethg$i[0]" channel-type="inet.node.ethernet.Eth10M" />
</at>
</scenario>
After the switch1
connection is lost, the timeout timer associated with the
routing table entry related to this link is not reset any more, and after 180
seconds (default value) the router marks the associated entry as “unreachable”.
But here we re-activate the link before it expires.
B: Link becomes operational after the timeout timer expires¶
Here, we use scenario6.xml
, in which we make the link reactivation to occur
at t = 300s. This time:
<!-- scenario6.xml -->
<scenario>
<at t="50">
<disconnect src-module="router2" dest-module="switch1" />
</at>
<at t="300">
<connect src-module="router2" src-gate="ethg$o[0]" dest-module="switch1" dest-gate="ethg$i[3]" channel-type="inet.node.ethernet.Eth10M" />
<connect src-module="switch1" src-gate="ethg$o[3]" dest-module="router2" dest-gate="ethg$i[0]" channel-type="inet.node.ethernet.Eth10M" />
</at>
</scenario>
C: Link becomes operational after the garbage-collection timer expires¶
In this scenario, we wait until after the garbage-collection timer expires to
observe the changes to the routing tables. The corresponding scenario7.xml
file:
<!-- scenario7.xml -->
<scenario>
<at t="50">
<disconnect src-module="router2" dest-module="switch1" />
</at>
<at t="602">
<connect src-module="router2" src-gate="ethg$o[0]" dest-module="switch1" dest-gate="ethg$i[3]" channel-type="inet.node.ethernet.Eth10M" />
<connect src-module="switch1" src-gate="ethg$o[3]" dest-module="router2" dest-gate="ethg$i[0]" channel-type="inet.node.ethernet.Eth10M" />
</at>
</scenario>
The link breaks at t = 50s, and router1
stops receiving any updates on the
route to the 10.0.0.24/29 network from router2
. As shown in the highlighted
line of the image below, the last update to the route was approximately at t =
30.5929s, the moment the timeout timer was last reset.
The timeout timer expires at t = 210s. At that time, the route’s metric is set to 16, and the garbage-collection timer is started.
At t = 330s, the garbage-collection timer expires, and the route is removed from the routing table:
TODO image 4C3
Sources:
omnetpp.ini
,
scenario5.xml
,
scenario6.xml
RipNetworkA.ned