The section here will cover tools which manipulate, display characteristics of or probe Ethernet devices.
Because Ethernet is one of the most available and widely spread networking media in use today, we’ll concentrate on Ethernet rather than other link layer protocols.
As with any networking stack, the lower layers must be functioning properly in order for the higher layer protocols to operate. The tools covered in this section will provide the resources you need to verify the proper operation of your linux machine in an Ethernet environment.
You probably knew before reading this that you can look at the link light on your Ethernet switch/hub and the link light on your Ethernet card to verify a good connection. Now you can use mii-tool to ask the Ethernet driver if it agrees. Once you have verified a good media connection, you may want to set other link layer characteristics on your Ethernet device. For this, ip link is the perfect tool.
To see if anybody is using an IP address already on the Ethernet to which you are connecting, you can use arping and if you want to play with the arp tables, the arp command is there to help you accomplish your objective.
arp
An often overlooked tool, arp is used to view and manipulate the entries in the arp table. See the Section called The ARP cache in Chapter 2 for a fuller discussion of the arp table.
The most common uses for arp are to add an address for which to proxy arp, delete an address from the arp table or view the arp table itself.
In the simplest invocation, you simply want to see the current state of the arp table. Invoking arp with no options will provide you exactly the information you need. Typically, you may not trust DNS (or may not wish to wait for the DNS lookups), and you may wish to specify the arp table on a particular interface.
Example B-1. Displaying the arp table with arp [root@masq-gw]# arp -n -i eth3
Address HWtype HWaddress Flags Mask Iface
192.168.100.1 ether 00:C0:7B:7D:00:C8 C eth3
[root@masq-gw]# arp -n -i eth0
Address HWtype HWaddress Flags Mask Iface
192.168.100.17 ether 00:80:C8:E8:4B:8E C eth0
[root@masq-gw]# arp -a -n -i eth0
? (192.168.100.17) at 00:80:C8:E8:4B:8E [ether] on eth0
The MAC address in the third column is always a six part hexadecimal number. In practice, the MAC address (also known as the hardware address or the Ethernet address) is not normally needed for the majority of troubleshooting problems, however knowing how to retrieve the MAC address can help when tracking down problems in a network1.
The arp command can also force a permament entry into the arp table. Let’s look at an unusual networking need. Infrequently, a need arises to split a network into two parts, each part with the same network address and netmask. The router which joins the two networks is connected to both sets of
media. See the Section called Breaking a network in two with proxy ARP in Chapter 9 for more detail on when and how to do this.
The command to add arp table entries makes a static entry in the arp table. This is not recommended practice, and is probably only necessary in strange, experimental, hybrid, or pseudo-bridging situations.
Example B-2. Adding arp table entries with arp
[root@masq-gw]# arp -s 192.168.100.17 -i eth3 -D eth3 pub [root@masq-gw]# arp -n -i eth3
Address HWtype HWaddress Flags Mask Iface
192.168.100.1 ether 00:C0:7B:7D:00:C8 C eth3
192.168.100.17 * * MP eth3
After inserting an entry into the arp table on eth3, we will now respond for ARP requests on eth3 for the IP 192.168.100.17. If the service-router has a packet bound for 192.168.100.17, it will generate an ARP request to which we will respond with the Ethernet address of our eth3 interface.
Moments after you have added this arp table entry, you realize that you really do not wish service-router and isolde to exchange any IP packets. There is no reason for the isolde to initiate a telnet session with service-router and correspondingly, there are no services on isolde which should be accessible from the router.
Fortunately, it’s quite easy to remove the entry.
Example B-3. Deleting arp table entries with arp [root@masq-gw]# arp -i eth3 -d 192.168.100.17 [root@masq-gw]# arp -n -i eth3
Address HWtype HWaddress Flags Mask Iface
192.168.100.1 ether 00:C0:7B:7D:00:C8 C eth3
arp is a small utility, but one which can prove extremely handy. One minor annoyance with the arp utility is option handling. Options seem to be handled differently based on order. If in doubt, try specifying the action as the first option.
arping
An almost unknown command (mostly because it is not frequently necessary), the arping utility performs an action similar to ping, but at the Ethernet layer. Where ping tests the reachability of an IP address, arping reports the reachability and round-trip time of an IP address hosted on the local network.
There are several modes of operation for this utility. Under normal operation, arping displays the Ethernet and IP address of the target as well as the time elapsed between the arp request and the arp reply.
Example B-4. Displaying reachability of an IP on the local Ethernet with arping [root@masq-gw]# arping -I eth0 -c 2 192.168.100.17
ARPING 192.168.100.17 from 192.168.100.254 eth0
Unicast reply from 192.168.100.17 [00:80:C8:E8:4B:8E] 8.419ms Unicast reply from 192.168.100.17 [00:80:C8:E8:4B:8E] 2.095ms Sent 2 probes (1 broadcast(s))
Received 2 response(s)
Other options to the arping utility include the ability to send a broadcast arp using the -U option and the ability to send a gratuitous reply using the -A option. A kernel with support for non-local bind can be used with arping for the nefarious purpose of wreaking havoc on an otherwise properly configured Ethernet. By performing gratuitous arp and broadcasting incorrect arp information, arp tables in poorly designed IP stacks can become quite confused.
arping can detect if an IP address is currently in use on an Ethernet. Called duplicate address detection, this use of arping is increasingly common in networking scripts.
For a practical example, let’s assume a laptop named dietrich is normally connected to a home network with the same IP address as tristan of our main office network. In the boot scripts, dietrich might make good use of arping by testing reachability of the IP it wants to use before bringing up the IP layer.
Example B-5. Duplicate Address Detection with arping
[root@dietrich]# arping -D -q -I eth0 -c 2 192.168.99.35 [root@dietrich]# echo $?
1
[root@dietrich]# arping -D -q -I eth0 -c 2 192.168.99.36 [root@dietrich]# echo $?
0
First, dietrich tests reachability of its preferred IP (192.168.99.35). Because the IP address is in use by tristan, dietrich receives a response. Any response by a device on the Ethernet indicating that an IP address is in use will cause the arping command to exit with a non-zero exit code (specifically, exit code 1).
Note, that the Ethernet device must already be in an UP state (see the Section called ip link). If the Ethernet device has not been brought up, the arping utility will exit with a non-zero exit code (specifically, exit code 2).
ip link
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.
Displaying link layer characteristics with ip link show
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 [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.
Changing link layer characteristics with ip link set
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 [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.
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 the Section called iproute2 documentation in Appendix I for further links.
Deactivating a device with ip link set
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 [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.
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.
Activating a device with ip link set
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 [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 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, 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 and Example B-8, 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.
Using ip link set to change the MTU
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 [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 the Section called MTU, MSS, and ICMP in Chapter 4. The remaining options to the ip link command cannot be used while the interface is in an UP state.
Changing the device name with ip link set
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 [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).
Changing hardware or Ethernet broadcast address with ip link set
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 offf: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 [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 idea2.
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.
ip neighbor
Part of the iproute2 command suite, ip neighbor provides a command line interface to display the neighbor table (ARP cache), insert permanent entries, remove specific entries and remove a large number