To display link layer information, ip link show will fetch characteristics of the link layer devices currently available. Any networking device which has a driver loaded can be classified as an available device. It is immaterial to ip link whether the device is in use by any higher layer protocols (e.g., IP). You can specify which device you want to know more about with the dev <interface> option.

[root@tristan]# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
          

Here we see that the only devices with drivers loaded on tristan are lo and eth0. Note, as with ip address show, the ip utility will sequentially number the output. These numbers are dynamically calcualted, so should not be used to refer to the interfaces. It is far better (and more intuitive) to refer to the interfaces by name.

For each device, two lines will summarize the link state and characteristics. If you are familiar with ifconfig output, you should notice that these two lines are a terse summary of lines 1 and 3 of each ifconfig device entry.

The flags here are the same flags reported by ifconfig, although by contrast to ifconfig, ip link show seems to report the state of the device flags accurately.

Let's take a brief tour of the ip link show output. Line one summarizes the current name of the device, the flags set on the device, the maximum transmission unit (MTU) the active queueing mechanism (if any), and the queue size if there is a queue present. The second line will always indicate the type of link layer in use on the device, and link layer specific information. For Ethernet, the common case, the current hardware address and Ethernet broadcast address will be displayed.

Frankly, with the exception of ip link set up and ip link set down I have not found need to use the ip link set command with any of the toggle flags Regardless, here's an example of the proper operation of the utility. Paranoid network administrators or those who wish to map Ethernet addresses manually should take special note of the ip link set arp off command.

[root@tristan]# ip link set dev eth0 promisc on
[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
[root@tristan]# ip link set dev eth0 multicast off promisc off
[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
[root@tristan]# ip link set arp off
Not enough of information: "dev" argument is required.
[root@tristan]# ip link set arp off dev eth0
[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
[root@enclitic root]# ip link set dev eth0 arp on 
[root@tristan root]# ip link show dev eth0
2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
          

Any of the below flags are valid on any device.

Users who would like more information about flags on link layer devices and their meanings should refer to Alexey Kuznetsov's excellent iproute2 reference. See the Section 1.6, “iproute2 documentation” for further links.

In the same way that using the tool ifconfig <interface> down can summarily stop networking, ip link set dev <interface> down will have a number of side effects for higher networking layers which are bound to this device.

Let's look at the side effects of using ip link to bring an interface down.

[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
[root@tristan]# ip route show
192.168.99.0/24 dev eth0  proto kernel  scope link  src 192.168.99.35
127.0.0.0/8 dev lo  scope link 
default via 192.168.99.254 dev eth0
[root@tristan]# ip link set dev eth0 down
[root@tristan]# ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.35/24 brd 192.168.99.255 scope global eth0
[root@tristan]# ip route show
127.0.0.0/8 dev lo  scope link
          

In our first command, we are able to determine that the eth0 is in an UP state. Naturally, ip link will not tell us if there is an IP bound to the device (use ip address to answer this question). Let's assume that tristan was operating normally on 192.168.199.35. If so, the routing table will appear exactly is it appears in Example B.8, “Deactivating a link layer device with ip link set”.

Now when we down the link layer on eth0, we'll see that there is now no longer a flag UP in the link layer output of ip address. More interesting, though, all of our IP routes to destinations via eth0 are now missing.

Before an interface can be bound to a device, the kernel needs to support the physical networking device (beyond the scope of this document) either as a module or as part of the monolithic kernel. If ip link show lists the device, then this condition has been satisfied, and ip link set dev <interface> can be used to activate the interface.

[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
[root@tristan]# arping -D -I eth0 192.168.99.35
Interface "eth0" is down
[root@tristan]# ip link set dev eth0 up
[root@tristan]# ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.35/24 brd 192.168.99.255 scope global eth0
[root@tristan]# ip route show
192.168.99.0/24 dev eth0  proto kernel  scope link  src 192.168.99.35
127.0.0.0/8 dev lo  scope link
          

Once the device itself has been activated, operations which require the ability to read data from the device or write data to the device will succeed. Refer to Example B.5, “Duplicate Address Detection with arping” for a clear example of a network operation which does not require a functional IP layer but need access to a functioning link layer.

I'll suggest that the reader consider what other common networking device might not want to have a functional IP layer, but would need a functioning link layer. FIXME -- Why in the world does tcpdump work even though the link layer is down? -- FIXME

In Example B.9, “Activating a link layer device with ip link set”, we are bringing up a device which already has IP address information bound to the device. Notice that as soon as the link layer is brought up, the network route to the local network is entered into the main routing table. By comparing Example B.9, “Activating a link layer device with ip link set” and Example B.8, “Deactivating a link layer device with ip link set”, we notice that when the link layer is brought up the default route is not returned! This is the most significant side effect of bringing down an interface through which other networks are reachable. There are several ways to repair the frightful missing default route condition: you can use ip route add, route add, or you can run the networking startup scripts again.

Changing the MTU on an interface is a classical example of an operation which, prior to the arrival of iproute2 one could only accomplish with the ifconfig command. Since iproute2 has separate utilities for managing the link layer, addressing, routing, and other IP-related objects, it becomes clear even with the command-line utilities that the MTU is really a function of the link layer protocol.

[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
[root@tristan]# # ip link set dev eth0 mtu 1412
[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,UP> mtu 1412 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
          

This simple example demonstrates exactly how to change the MTU. For a broader discussion of MTU, please consult Section 10.1, “MTU, MSS, and ICMP”. The remaining options to the ip link command cannot be used while the interface is in an UP state.

For the occasional need to rename an interface from one name to another, the command ip link set provides the desired functionality. Though this command must be used when the device is not in an UP state, the command itself is quite simple. Let's name the interface inside0.

[root@tristan]# ip link set dev eth0 mtu 1500
[root@tristan]# ip link set dev eth0 name inside
[root@tristan]# ip link show dev inside
2: inside: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:4a:51 brd ff:ff:ff:ff:ff:ff
          

The convenience of being able to rename devices can be substantial when you are managing many machines and want to use the same name on many different machines, which may have different hardware. Of course, by changing the name of the device, you may foil any scripts which assume conventional device names (eth0, eth1, ppp0).

This command changes the hardware or broadcast address of a device as used on the media to which it is connected. Supposedly there can be name clashes between two different Ethernet cards sharing the same hardware address. I have yet to see this problem, so I suspect that changing the hardware address is more commonly used in vulnerabliity testing or even more nefarious purposes.

Alternatively, one can set the broadcast address to a different value, which as Alexey remarks as an aside in the iproute2 manual will "break networking." Changing the Ethernet broadcast address implies that no conventionally configured host will answer broadcast ARP frames transmitted onto the Ethernet. Since conventional ARP requests are sent to the Ethernet broadcast of ff:ff:ff:ff:ff:ff, broadcast frames sent after changing the link layer broadcast address will not be received by other hosts on the segment. To echo Alexey's sentiments: if you are not sure what you are doing, don't change this. You'll break networking terribly.

[root@tristan]# ip link set dev inside name eth0
[root@tristan]# ip link set dev eth0 address 00:80:c8:f8:be:ef
[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:be:ef brd ff:ff:ff:ff:ff:ff
[root@tristan]# ip link set dev eth0 broadcast ff:ff:88:ff:ff:88
[root@tristan]# ip link show dev eth0
2: eth0: <BROADCAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:80:c8:f8:be:ef brd ff:ff:88:ff:ff:88
[root@tristan]# ping -c 1 -n 192.168.99.254 >/dev/null 2>&1 &
[root@tristan]# tcpdump -nnqtei eth0
tcpdump: listening on eth0
0:80:c8:f8:be:ef ff:ff:88:ff:ff:88 42: arp who-has 192.168.99.254 tell 192.168.99.35
0:80:c8:f8:be:ef ff:ff:88:ff:ff:88 42: arp who-has 192.168.99.254 tell 192.168.99.35
          

This practical example demonstrates setting the hardware address and the broadcast address. Changing the hardware address, also known as the media access control (MAC) address, is not usually necessary. It is a simple operation without detrimental side effects, provided there is no address clash with an existing device.

Note, however, in the tcpdump output, the effect of changing the Ethernet broadcast address. As discussed in the paragraph above, changing the broadcast is probably not a good idea ^[42].

As you can see, the ip link utility is a treasure trove of information and allows a great deal of control over the devices on a linux system.