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.

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