Purpose And Structure Of Iprout2 Commands Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This report is being completed as part of the Unix Network Administration Trimester 1 coursework. It Focusses on the network management utilities used in a Linux OS, both past and present, and compares them in detail. Various key areas will be covered, including the purpose and structure of the new software, the limitations of the old software, new functions of the new software and an overall comparison of the two to establish whether the new software provides a significant improvement over what was available before and therefor if ip and related commands are worth learning how to use.

Main Section

Purpose and Structure of iprout2 commands

The ip command is part of the iproute2 suite which has been created with purpose of replacing the outdate net-tools that were standard with older installations of Linux operating systems. The ip command is used to show and manipulate routing, devices, policy routing and tunnels on a Linux operating system, and if used with the correct corresponding syntax it can be used to perform all the tasks that were performed by the old net-tools.

An ip command uses the following structure - ip [ OPTIONS ] OBJECT { COMMAND | help }

One of the most significant features of the ip command and its different uses regarding its structure is that all the commands start with 'ip'. Instead of a mix of completely different commands like in net-tools. This means that all the tasks that were previously performed by different commands are now governed by the same family of commands.

The following table helps to demonstrate the simplicity of the structure of the ip command over the net-tools commands and shows how the key features of the net-tools are all supported using ip.




Address and link configuration


ip addr, ip link

Routing tables


ip route



ip neigh



ip link



ip tunnel



ip maddr

Limitations of net-tools

The net-tools commands and their functions listed in the table above are the full extent of what net-tools has to offer, unlike ip and its related commands which offer a great deal more. Net-tools were fist implemented in 4.2BSD as part of the BSD TCP/IP suite in August 1983. They have become obsolete and as a result have not received any major updates since v 1.60 on April 15th 2001.

Net-tools now suffers in comparison to iproute2 due to this lack of maintenance and updates. Of all of the limitations that the net-tools toolkit suffers in comparison to the iproute2 toolkit, the most significant are the lack of support for network traffic control and the fact that the old net-tools do not support multiple routing tables.

Added Functionality of iproute2 over net-tools

Network Traffic control

Ip is only one part of a number of tools present in iprout2. Another tool in iproute2 is the tc (traffic control) command. As stated previously in this report. This is a feature not supported in net-tools.

Traffic control consists of several key areas. Traffic can be shaped, which involves controlling the rate of transmission e.g. Lowering bandwidth. Traffic can be scheduled thus allowing packets to be queued and thus routed when they are ready to be received by the destination address. Traffic can be policed which involves packets being assessed when they arrive. Finally traffic can be dropped, which involves packets that exceed the network bandwidth being discarded.

The shaping of traffic on a network using tc and its related commands offers several advantages to a network. Particularly concerning ISP's and large scale businesses An Internet Service Provider can throttle bandwidth of users on their network that are exceeding their specified fair use policy. Also, instead of having to pay more for additional bandwidth. An enterprise can use Traffic control methods to make more efficient use of the bandwidth they already have. As mentioned before. On a command line only or server core installation of a Linux operating system. The tc command provides the interaction and support for this invaluable tool.

Below is a set of examples of possible variants of the tc command to help put the command and its parts into context and demonstrate the three main tc command syntaxes

tc qdisc add dev eth1 root handle 1:0 htb

The above command shows the tc command used in conjunction with the queuing command qdisc. The device that the queuing discipline is being attached to is then specified as eth0, the 'handle 1: 0' part of the command refers to the user specified major/minor number and HTB is the queuing discipline that will be attached

The next command will show how tc can be used to add a class to an existing parent class (essentially a queuing command within a queuing command)

tc class add dev eth1 parent 1:1 classid 1:6

When creating a class most of the information contained within the command is the same as that of the qdisk command except that the parent id and class id are now specified as well.

The third and final example of the tc command I will demonstrate is the tc filter command

tc filter add dev eth1 parent 1:0 protocol ip prio 5 u32 match ip port 32 0xffff match ip tos 0x10 0xff flow id 1:6 police rate 31000bps burst 10240 mpu 0 action drop/continue

The tc filter command looks complex, but it is actually fairly straightforward. A filter is being applied using the ip protocol to the interface eth1. The filter is then given a priority so that it can be placed above or below others. In this case the priority is 5 'prio 5' The flow id is given to tell the packets which qdisk they should be sent to for handling. The police rate as mentioned earlier is the data rate specified for received packets at which action will be taken if it is exceeded or not. In this case the police rate being 31000bps and the action to be taken drop (if exceeded) and continue (if not exceeded)

Support for Multiple Routing Tables

Instead of just selecting a route based on the destination ip address range like in older versions of Linux (pre v2.2). Linux kernels v2.2 and later now support policy based routing using multiple routing tables and the routing policy database (RPDB). This allows an administrator to configure the selection of different routing tables and routes based on multiple packet attributes such as the source address of the packet, the ToS flags, the presence or absence of an fwmark and the interface name on which the packet were received.

This policy based IP routing that iproute2 and its associated tools ip route and ip rule make use of offers many advantages over the conventional IP routing governed by the net-tools route command. Such as the possibility of routing based on the source address instead of the destination address, thus allowing packets from different sources to be routed to different networks with the same destination address.

Using iproute2 commands ip route and ip rule it is possible to create and make use of up to 252 additional routing tables as well as the original local and main routing tables. It was only possible to manipulate the local (unadvisable) and main routing tables using the net-tools route command. Each additional table is given a number and is stored in /etc/iproute2/rt_tables.

Initially the main routing table would be populated using the ip route command similar to the example I have given below.

ip route add dev eth0

(this would add the default gateway of and the subnet mask of to the network interface called eth0)

Then the policy routing rules would be created using a set of commands similar to the following.

ip rule add unicast from table 5

ip rule add unicast iif eth7 table 5

(this would cause a broadcast from to search for a route in table 5, and if the broadcast was from the interface eth7 to search for a route in table 5).

Iproute2 Drawbacks

There are a few drawbacks to using the tools from the iproute2 suit. The most significant drawback has less to do with the actual tools themselves and more to do with the people that are using them, (or not using them as is this case). Learning to use a new set of networking tools can be difficult when an individual has been using the same tool for a long period of time. It is human nature to become comfortable with the familiar and to be reluctant to change. Such is the case with iproute2. People have been using net-tools for such a long time that they have become comfortable with them. The problem also extends to the issue of a business or enterprise following an unchanged policy of implementing and maintaining a network using the old software and therefore advising their administrators to follow suit. This, combined with the fact that iproute2 has a slightly more complicated command line structure, is off-putting to many.

Software Assessment/Conclusions

Throughout this report the 2 sets of software iptoute2 and net-tools and their associated commands have been compared and contrasted in great detail. Also all the key aspects of what makes the new software iproute2 superior to the old software net-tools have been described. It is clear from these facts that iproute2 is indeed better suited for today's networking needs.

Below is a table summarising the benefits of iproute2 over net-tools.



New Command syntax

Each command governs a wider range of features and functions e.g. Ip and its subsequent commands

Regular updates and patches

Software will be up to date and compatible with the latest features of Linux.

Wide range of Support

Issues with the software can be resolved quickly and efficiently

Supports network traffic control

Administrators can effectively manage the flow of packets to and from their network and thus optimise bandwidth efficiency.

Supports multiple routing tables

Provides policy based routing, useful for internetworking

It is therefore conclude that an organisation or enterprise would benefit greatly from incorporating the use of iproute2 into their network Administration practice and policy.

This opinion is also shared by the majority of Linux users and network administrators.

The following quote is from Tim Heckman, a respected Cisco certified Linux network Administrators blog.

"If you are reading an article online, an excerpt from a book, or some tutorial you will see the net-tools package used in most cases.  But why is a package considered deprecated still being used?  This is most likely due to the majority of users being familiar, or at least having been exposed to, the net-tools suite. Additionally, for some system administrators the familiarity of the command is comforting.

The comfort, however, is no replacement for the power of the iproute2 toolset"

Another quote that I feel helps to summarise the general opinion of IT professionals is from Steve Miller (another respected Cisco qualified Network Technician)

"Iproute2 includes several utilities, and one in particular that seeks to combine the functionality of several of the net-tools utilities. It is called `ip` and effectively replaces the functionality of `ifconfig`, `route`, `iptunnel`, `ipmaddr`"