20

I read some articles/tutorials on 'ifconfig' command, most of them included a common statement -

"ifconfig is deprecated by ip command"

and suggested to learn ip command. But none of them explained how 'ip' command is more powerful than 'ifconfig'.

What is the difference between both of them?

2

4 Answers 4

Reset to default
22

ifconfig is from net-tools, which hasn't been able to fully keep up with the Linux network stack for a long time. It also still uses ioctl for network configuration, which is an ugly and less powerful way of interacting with the kernel.

A lot of changes in Linux networking code, and a lot of new features aren't accessible using net-tools: multipath routing, policy routing (see the RPDB). route allows you to do stupid things like adding multiple routes to the same destination, with the same metric.

Additionally:

  • ifconfig doesn't report the proper hardware address for some devices.
  • You can't configure ipip, sit, gre, l2tp, etc. in-kernel static tunnels.
  • You can't create tun or tap devices.
  • The way of adding multiple addresses to a given interface also has poor semantics.
  • You also can't configure the Linux traffic control system using net-tools either.

See also ifconfig sucks.

EDIT: Removed assertion about net-tools development ceasing that by now I forgot where I got for this post. net-tools' has been worked on since iproute2 was released, though it's mostly bug fixing and minor enhancements and features, like internationalization.

1
7

ifconfig is a traditional command to display information about network interfaces and change some settings. In particular, it can bring interfaces up and down. It exists on most unix variants.

On Linux, the ifconfig command hasn't evolved in a long time. It's still perfectly fine for what it does. If you're using ifconfig for something, there's no reason to stop.

Linux also provides the ip command from the iproute2 tool suite. The ip command combines several classical commands and more, including ifconfig, route and arp. ip can do a lot more than ifconfig. On the other hand, ip isn't always present, especially on embedded systems (and never on unix variants other than Linux).

Parsing ifconfig's output kinda sucks. Parsing ip's output kinda sucks. No winner there.

2
  • I've always thought parsing ip's output to be fairly simple, and certainly a heck of a lot simpler than ifconfig. I also love that in many cases the output of an ip command can be used as the input to another ip command with little or no modification (for example, every line of ip route show can be used as the arguments to ip route add).
    – phemmer
    Oct 4, 2013 at 4:21
  • 1
    @Patrick parsing the ip route, and ip rule output is pretty clear and pretty easy to parse. But ip link, or ip addr is a pain. I really wish someone would submit a patch or something to make the ip addr print out the exact statements, perhaps with a switch, that you would use setup the current config, like you get with ip route show.
    – Zoredache
    Oct 4, 2013 at 4:59
5

Just to add some bits to the answer by pilona. Around 2005 a new mechanism for controlling the network stack was introduced - netlink sockets.

To configure the network interface iproute2 makes use of that full-duplex netlink socket mechanism, while ifconfig relies on an ioctl system call. Here are 2 main papers on motivation behind netlink and usage of rtnetlink.

0

In my experience I have found the output of ifconfig easier to digest when compared with ip-* commands, which IMO visually leave a bit to be desired. In my typical use I only need a subset of what is given, for example interface, status, ipaddress and in this regard ifconfig is easier to read.

ifconfig:

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
    inet 127.0.0.1  netmask 255.0.0.0
    loop  txqueuelen 1000  (Local Loopback)
    RX packets 297454  bytes 14872700 (14.1 MiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 297454  bytes 14872700 (14.1 MiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.0.0.10  netmask 255.255.255.0  broadcast 10.0.0.255
    ether aa:aa:aa:aa:aa:aa  txqueuelen 1000  (Ethernet)
    aa:aa:aa:aa:aa:aabytes 596277 (582.3 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 9083  bytes 738309 (721.0 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 10.0.0.20  netmask 255.255.255.0  broadcast 10.0.0.255
    ether aa:aa:aa:aa:aa:aa  txqueuelen 1000  (Ethernet)
    aa:aa:aa:aa:aa:aabytes 596277 (582.3 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 9083  bytes 738309 (721.0 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Compared with ip-address:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
inet 10.0.0.10/24 brd 10.0.0.255 scope global eth0
   valid_lft forever preferred_lft forever
3: eth1 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
inet 10.0.0.20/24 brd 10.0.0.255 scope global eth1
   valid_lft forever preferred_lft forever

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .