Step 7. Counting to Infinity (Loop Instability with Higher Number of Nodes)¶

Goals¶

TODO: the same as in the previous step, but with more routers

The model¶

TODO: description of the problem and the difference from the previous step

This step uses the following network:

network RipNetworkC
{
    @display("bgb=2066.82,862.47003");
    @figure[simtime](type="simTimeText"; pos=1550,60; prefix="SimTime: "; font=,14);
    submodules:
        configurator: Ipv4NetworkConfigurator {
            @display("p=683.76,77.700005");
        }
        visualizer: <default("IntegratedCanvasVisualizer")> like IIntegratedVisualizer {
            @display("p=936.72504,78.9375");
        }
        scenarioManager: ScenarioManager {
            @display("p=1210.375,78.9375");
        }
        host0: StandardHost {
            @display("p=116.55,271.95");
        }
        host1: StandardHost {
            @display("p=116.55,489.51");
        }
        host2: StandardHost {
            @display("p=116.55,717.43");
        }
        router0: Router {
            @display("p=986.79004,271.95");
        }
        router1: Router {
            @display("p=1289.8201,489.51");
        }
        host3: StandardHost {
            @display("p=1924.37,271.95");
        }
        host4: StandardHost {
            @display("p=1924.37,489.51");
        }
        host5: StandardHost {
            @display("p=1924.37,717.43");
        }
        switch0: EtherSwitch {
            @display("p=406.63,486.92");
        }
        switch1: EtherSwitch {
            @display("p=1605.8,486.92");
        }
        router2: Router {
            @display("p=704.48,489.51");
        }
        router3: Router {
            @display("p=986.79004,717.43");
        }
    connections:
        host2.ethg++ <--> Eth100M <--> switch0.ethg++;
        host1.ethg++ <--> Eth100M <--> switch0.ethg++;
        host0.ethg++ <--> Eth100M <--> switch0.ethg++;
        switch0.ethg++ <--> Eth100M <--> router2.ethg++;

        switch1.ethg++ <--> Eth100M <--> host3.ethg++;
        switch1.ethg++ <--> Eth100M <--> host4.ethg++;
        switch1.ethg++ <--> Eth100M <--> host5.ethg++;

        router0.ethg++ <--> Eth100M <--> router1.ethg++;
        router1.ethg++ <--> Eth100M <--> switch1.ethg++;
        router2.ethg++ <--> Eth100M <--> router3.ethg++;
        router2.ethg++ <--> Eth100M <--> router0.ethg++;
        router3.ethg++ <--> Eth100M <--> router0.ethg++;
        router3.ethg++ <--> Eth100M <--> router1.ethg++;
}

The configuration in omnetpp.ini is the following:

[Config Step7]
description = "Count to infinity (loop instability with higher number of nodes)"
extends = Step6
network = RipNetworkC

# Even split horizon with/without poison reverse is not able to solve this loop instability
#*.router*.rip.ripConfig = xml("<config> <interface hosts='router*' mode='SplitHorizon' /> </config>")

# triggered update causes the count to infinity to finish faster!

# one solution is to use garbage-collection timer (next step)

*.host0.numApps = 0

Split Horizon:

[Config Step7SplitHorizon]
extends = Step7

# Even split horizon with/without poison reverse is not able to solve this loop instability
*.router*.rip.ripConfig = xml("<config> <interface hosts='router*' mode='SplitHorizon' /> </config>")

# recovery: takes around 250s

Triggered Update:

[Config Step7TriggeredUpdates]
extends = Step7

# triggered update causes the count to infinity to finish faster!
*.router*.rip.triggeredUpdate = true

*.router*.rip.ripConfig = xml("<config> <interface hosts='router*' mode='SplitHorizon' /> </config>")

# Triggered updates seem to solve the count to infinity problem with
# or without split horizon so not sure this config is needed

Results¶

TODO: video

RIP update messages are sent every 30 seconds (not visualized here). The route metrics increase incrementally (count-to-infinity):

TODO: what happens

TODO: screenshots of routing tables / RIP packets

Sources: omnetpp.ini, RipNetworkC.ned