Step 6. Using a different metric for automatic routing table configuration¶
When setting up routes, the configurator uses the shortest path algorithm. By default, paths are optimized for hop count. However, there are other cost functions available, like data rate, error rate, etc. This step consists of two parts:
Part A demonstrates using data rate as metric.
Part B demonstrates instructing the configurator to ignore a link when setting up routes, by manually specifying a high link cost.
Part A: Using the data rate as metric¶
When setting up routes, the configurator first builds a graph representing the network topology. A vertex in the graph represents a network node along with all of its interfaces. An edge represents a wired or wireless connection between two network interfaces. When building the network topology, wireless nodes are considered to be connected to all other wireless nodes in the same wireless network.
After the graph is built, the configurator assigns weights to vertices and edges according to the configured metric. Vertices that represent network nodes with IP forwarding turned off have infinite weight; all others have 0. Finally, the shortest path algorithm is used to determine the routes based on the assigned weights.
The available metrics are the following:
hopCount: routes are optimized for hop count. All edges have a cost of 1. This is the default metric.
dataRate: routes prefer connections with higher bandwidth. Edge costs are inversely proportional to the data rate of the connection.
delay: routes are optimized for lower delay. Edge costs are proportional to the delay of the connection.
errorRate: routes are optimized for smaller error rate. Edge costs are proportional to the error rate of the connection. This is mostly useful for wireless networks because the error rate of wired connections is usually negligible.
The configuration for this step extends Step 4, thus, it uses the ConfiguratorA network. The configuration in omnetpp.ini is the following:
[Config Step6A] extends = Step4 description = "Setting different metric for automatic routing table configuration - using dataRate metric" *.configurator.config = xmldoc("step6a.xml") *.visualizer.routingTableVisualizer.destinationFilter = "host1"
Below is the XML configuration in step6a.xml:
<config> <interface hosts='**' address='10.x.x.x' netmask='255.x.x.x'/> <autoroute sourceHosts='**' metric='dataRate'/> </config>
The XML configuration contains the default rule for IP address
assignment, and an
<autoroute> element that configures the metric to
be used. The
<autoroute> element specifies parameters for automatic
static routing table configuration. If no
<autoroute> element is
specified, the configurator assumes a default that affects all routing
tables in the network, and computes shortest paths to all interfaces
according to the hop count metric. The
<autoroute> element can
contain the following attributes: -
sourceHosts: Selector attribute
that selects which hosts’ routing tables should be modified. The default
destinationInterfaces: Parameter attribute that
selects destination interfaces for which the shortest paths will be
calculated. The default value is
attribute that sets the metric to be used when calculating shortest
paths. The default value is
There are sub-elements available in
<autoroute>, which will be
discussed in Part B.
<autoroute> element specifies that routes should be added
to the routing table of each host and the metric should be
The configurator assigns weights to the graph’s edges that are inversely
proportional to the data rate of the network links. This way route
generation will favor routes with higher data rates.
router2 are connected with a 10 Mbit/s
ethernet cable, while
router1 connects to the other routers with 100
Mbit/s ethernet cables. Since routes are optimized for data rate,
router2 will go via
this path has higher bandwidth.
The following image shows the backward routes towards
resulting routes are similar to the ones in Step 5B. The difference is
that routes going backward, from hosts 6–8 to hosts 0–2, go through
router1. No traffic is routed between
all (as opposed to Step 4 and 5.)
The routing table of
router0 is as follows:
Node ConfiguratorA.router0 -- Routing table -- Destination Netmask Gateway Iface Metric 10.0.0.18 255.255.255.255 * eth1 (10.0.0.17) 0 10.0.0.0 255.255.255.248 * eth0 (10.0.0.4) 0 10.0.0.0 255.255.255.192 10.0.0.18 eth1 (10.0.0.17) 0
The first two rules describe reaching
router1 and hosts 0–2
directly. The last rule specifies that traffic to any other destination
should be routed towards
The routing table of
router2 is similar:
Node ConfiguratorA.router2 -- Routing table -- Destination Netmask Gateway Iface Metric 10.0.0.26 255.255.255.255 * eth0 (10.0.0.25) 0 10.0.0.32 255.255.255.248 * eth1 (10.0.0.33) 0 10.0.0.0 255.255.255.224 10.0.0.26 eth0 (10.0.0.25) 0
The following video shows
host6. Routes towards
host1 are visualized. The packets
don’t use the link between
One can easily check that no routes go through the link between
router2 by setting the destination filter to
in the visualizer. This indicates all routes in the network: