CLI Magic: Is iproute2 right for you?

Good news, my dweebs! If you’re tired of platform wars, editor wars, browser wars, and environment wars, take heart! I am here to offer you a tasty new morsel for your war-addicted palate. But in order to enjoy it, you’ll have to retreat from the GUI and come down to my tiny little DMZ on the CLI. That’s where you’ll have the best view of the battle between the ancients (tools like ifconfig, route, and netstat) and the neo command set of iproute2.Why are there new tools? They reflect new features in the Linux kernel which showed up in the 2.2 release. This is explained succinctly in the iproute2 Howto, which I quote from below:

Most Linux distributions, and most Unixes, currently use the venerable arp, ifconfig, and route commands. While these tools work, they show some unexpected behavior under Linux 2.2 and up. For example, GRE tunnels are an integral part of routing these days, but require completely different tools.

With iproute2, tunnels are an integral part of the tool set.

The 2.2 and above Linux kernels include a completely redesigned network subsystem. This new networking code brings Linux performance and a feature set with little competition in the general OS arena. In fact, the new routing, filtering, and classifying code is more featureful than the one provided by many dedicated routers and firewalls and traffic shaping products.

As new networking concepts have been invented, people have found ways to plaster them on top of the existing framework in existing OSes. This constant layering of cruft has lead to networking code that is filled with strange behavior, much like most human languages. In the past, Linux emulated SunOS’s handling of many of these things, which was not ideal.

This new framework makes it possible to clearly express features previously beyond Linux’s reach.

So the good news is that you can create a tunnel with the same tool you use to add a route. But there’s more to it than that. There’s policy routing, for instance, as explained in another Howto:

The standard network tools (e.g. ifconfig, route, and netstat) aren’t capable on setting up some of the features used in newer LVSs, e.g. routing based on src_addr. For this we use iproute2, which allows routing based on almost any of the parameters of a packet (src, dest, proto, tos…). iproute2 implements similar functionality to Cisco’s IOS.

If there is only one possible route for packets, then ifconfig and route are just fine. If multiple routes exist then iproute2 is needed.

Presumably routing in Linux and the setup of LVS will move more toward using iproute2. The configure script will use the iproute2 package to do some configuration if you have it installed.

What about us ordinary users? Is it good for us, too? Let’s compare it with ifconfig.
Remember the column on ifconfig? We learned how easy it was to learn the following four things about an interface, simply by typing ifconfig:

• The hardware address of the Ethernet card
• The IP address
• The inet6 IP address
• The status of the connection (UP)

It’s got to be that easy — or even easier — with this newfangled stuff. Hmmm. The man page is a bit intimidating. Let’s try this:

ip link show

1: lo:  mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: sit0:  mtu 1480 qdisc noqueue
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:8d:4e:9d:d0 brd ff:ff:ff:ff:ff:ff

Well, not too bad, the command returns only two out of the four items we got with ifconfig. Maybe this variant:

ip route show

192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.100
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.0.1 dev eth0

Well, that got one more of the original four. We now know our IP address, too. Let’s try another:

ip addr show

1: lo:  mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: sit0:  mtu 1480 qdisc noqueue
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:8d:4e:9d:d0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.100/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::250:8dff:fe4e:9dd0/64 scope link
       valid_lft forever preferred_lft forever

Aha! Should have used that the first time. Will it tell us if the card has been put in promiscuous mode? Let’s try. First use ifconfig eth0 promisc to put the interface in the mood for love. Then repeat the ip addr show command. Yep, there it is, IN ALL CAPS. So we’ve found an equivalent method of displaying information about the interface.

Can you modify settings as easily as with ifconfig? Let’s try getting the card back in a monogamous relationship.

Whoops, wrong example You can’t do that. Not with the ip command, at least. According to one explanation I read online, “The ip command does not allow changing the PROMISC or ALLMULTI flags as these flags are considered obsolete and should not be changed administratively.”

The ip command set probably compares more favorably with route than it does with ifconfig anyway. Let’s try a couple of things and see. Just entering a naked route command gives a pretty good picture of the kernel IP routing table. Here’s the output I get:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

On the ip command set side of the table, we’ll try this:

ip route show

192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.100
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 192.168.0.1 dev eth0

Hmmmm. Less information, poorer organization and display of results. Yeah, this is progress alright.

But please, don’t give up there. Go wading through the man ip pages. In total, they are only the size of a robust EULA crafted in Redmond. And you don’t even have to view them through a 1×3-inch window! That’s not to say there might not be an option which provides that.

I’m sorry, the new ip commands may be right for you, but they are definitely not right for me. They offer me no new value, reduced functionality, and no new ease of use. Instead they bring new levels of complexity to the command syntax. If you like the lack of design and focus inherent in Emacs, however, you’ll love the iproute2 command set.

I admit I’m not being entirely fair in my treatment of iproute2. Some sysadmins have told me that the new tools included in iproute2 provide them with a lot of added productivity and functionality. But if you’re like me, a simple Linux desktop user, using Linux for just that, to be my desktop box, instead of a cheap alternative for an expensive hardware router, it’s a clear case of overkill. I’ll keep ifconfig and route in my toolset, thanks just the same.