Part of the iproute2 suite, ip link provides the ability to display link layer information, activate an interface, deactivate an interface, change link layer state flags, change MTU, the name of the interface, and even the hardware and Ethernet broadcast address.
The ip link tool provides the following two verbs: ip link show and ip link set.
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.
Example B.6. Using ip link show
|
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.
Example B.7. Using ip link set to change device flags
|
Any of the below flags are valid on any device.
Table B.1. ip link link layer device states
| Flag | Possible States |
|---|---|
| arp | on | off |
| promisc | on | off |
| allmulti | on | off |
| multicast | on | off |
| dynamic | on | off |
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 I.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.
Example B.8. Deactivating a link layer device with ip link set
|
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.
Example B.9. Activating a link layer device with ip link set
|
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.
Example B.10. Using ip link set to change device flags
|
This simple example demonstrates exactly how to change the MTU. For a broader discussion of MTU, please consult Section 4.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.
Example B.11. Changing the device name with ip link set
|
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.
Example B.12. Changing broadcast and hardware addresses with ip link set
|
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.