Appendix C. IP Address Management
Table of Contents
A machine which can access Internet resources has an IP address, whether that IP address is a public address or a private address hidden behind an SNAT router [44]. With the increasingly common use of linux machines as servers, desktops, and embedded devices and with changing network topologies and re-addressing, the need to be able to determine the current IP address of a machine and modify that address has consequently become a common need.
I assume in this chapter that the reader has some familiarity with CIDR addressing and netmasks. If any of these concepts are unfamiliar, or the reader would like to brush up, I suggest a visit to some of the links which can be found in Section I.1.3, “General IP Networking Resources”.
We'll begin our tour of the utilities for observing, changing, removing, and adding IP addresses to network devices with ifconfig, the traditional utility for IP management. We will also examine the newer and more flexible ip address, a key part of the iproute2 package.
[44] I'm sure somebody will be glad to nitpick here and tell me that s/he has a machine connected to the Internet which uses SNA, DecNET, IPX, or NetBEUI to connect to another host which actually does speak IP, thus proving that not every host which has access to the Internet is actually directly speaking IP. Another example is doubtless, wireless devices, such as telephones. Here, I'll concern myself with the majority case.
C.1. ifconfig
The venerable ifconfig is available on almost every unix I have encountered. In addition to reporting the IP addressing and usage statistics of an optionally specified interface, ifconfig can modify an interface's MTU and other flags and interface characteristics, bring up an interface and bring down an interface. This tool is the primary tool for manipulation of IP addressing on many linux distributions.
In its simplest use, ifconfig merely reports the IP interface and relevant statistics. For Ethernet devices, the hardware address, IP address, broadcast, netmask, IP interface states, and some other additional information is presented. For other interfaces, different information may be presented to the user, but the basic summary of IP addressing information will always be available. Be sure to read Section C.1.4, “Reading ifconfig output” also.
Example C.1. Viewing interface information with ifconfig
|
It is fairly common to specify the name of an interface as an argument to ifconfig, which will restrict the output to the named interface. This is the only way to retrieve information from ifconfig about link layer devices which are available, but not in an UP state. See also Section B.3, “ip link” and Section C.2, “ip address”.
There are many other options available to the ifconfig command to control addressing and interface state. Contrary to the behaviour of most other standard unix command line utilities which operate on arguments and options, ifconfig operates on a grammar after the specified interface. Subsequent examples will demonstrate how this differs from conventional modern unix tools.
Let's look at some simple operations you can perform with ifconfig. Occasionally, you will need to bring down a network interface. For an introduction to this and its side effects, see Example 1.6, “Bringing down a network interface with ifconfig” and the list of side effects.
Example C.2. Bringing down an interface with ifconfig
|
Naturally, when we view the active interfaces after downing the first Ethernet interface, we see that eth0 is no longer present. This is exactly what we had intended. Now to bring up the interface, we'll need the IP address and netmask information.
Bringing up an interface is slightly more complex than bringing an interface down because you need to have the IP addressing information handy in order to bring the interface back. For an introduction to the side effects of bringing up an IP address on an interface, see Example 1.7, “Bringing up an Ethernet interface with ifconfig” and the list of side effects.
Example C.3. Bringing up an interface with ifconfig
|
The above operations are the simple operations one can perform with ifconfig. Let's examine the output a bit more closely now, with an eye toward the other flags and settings we can manually twiddle.
The first line of each interface definition represents data which cannot be altered with ifconfig. If we consider only Ethernet interfaces, the link encapsulation will always say "Ethernet", and the hardware address cannot be altered with ifconfig [45]. Below this, one line summarizes the IP information associated with this logical interface.
The third line indicates the current states of the interface, maximum transmission unit, and the metric for this interface. Possible state options are itemized in the table below. The maximimum transmission unit is routinely set to 1500 bytes for Ethernet and promptly forgotten. MTU suddenly becomes important when IP packets are forwarded across a link layer which requires a smaller MTU. Thus ifconfig provides a method to set the MTU on an interface. For more on MTU, see Section 4.10.1, “MTU, MSS, and ICMP”. The remaining lines of output are taken from the Ethernet driver. See further discussion of these statistics below.
It is a rare occasion on which the MTU needs to be changed, but when it needs to be changed, nothing else will suffice. Here's an example of setting the MTU on an interface to 1412 bytes.
Example C.4. Changing MTU with ifconfig
|
Every device on a system has flags which indicate the state the device may be in. These flags can be altered by the ifconfig utility.
Table C.1. Interface Flags
| Flag | Description |
|---|---|
| UP | device is functioning |
| BROADCAST | device can send traffic to all hosts on the link |
| RUNNING | ??? |
| MULTICAST | device can perform and receive multicast packets |
| ALLMULTI | device receives all multicast packets on the link |
| PROMISC | device receives all traffic on the link |
I cannot confidently recommend believing the flags as reported by ifconfig output. Attestations from others and experimentation has proven to me that these flags (particularly the PROMISC flag) do not accurately represent the state of the device as reported in log files (by the kernel) and by the ip link show utility.
This does not mean, however, that the flags cannot be set with the ifconfig utility. Manipulation of the flags on an interface operates according to a peculiar grammar. To set the PROMISC flag, one issues a command with the promisc option from the grammar. If one wishes to remove the PROMISC flag from an interface, the -promisc option is required.
Example C.5. Setting interface flags with ifconfig
|
Since linux 2.0 the kernel has supported multiple IP addresses hosted on the same device. By suffixing the real interface name with a colon and a non-negative integer, you can bring up additional IP adresses on the same device. Example alias names are eth0:0 eth0:7. See Section 9.4, “Multiple IPs on an Interface” for further details.
As you can see, ifconfig is both a powerful and idiosyncratic tool for controlling network interfaces and devices.
[45] If you need to change the hardware address of an Ethernet interface, you have a strange need, but you can accomplish this using the ip link set address command.
C.2. ip address
Part of the iproute2 suite, ip address can list the IP addresses affiliated with interfaces, add IPs, delete IPs, and remove all IPs on a given device.
The first thing you'll want to do is list the IPs on your machine. The ip address tool will display IP (and terse encapsulation information) when invoked with the show verb. To specify that you wish to see the IP information for only one interface, you can add dev <device-name>
Example C.6. Displaying IP information with ip address
|
You should notice some similarity between the output of ip address and ifconfig. Each device is given an sequential number as an identifying number. This is merely a convenience, and should not be used to refer to devices. The second field in an entry is the interface name (which usually corresponds to the device name). Next, we see the familiar device flags and maximum transmission unit size.
The final fields in the first line of output for each device entry refer to the traffic control queueing discipline (qdisc) and the Ethernet buffer transmit queue length (qlen). For more on understanding and using traffic control under linux, see the LARTC documentation.
The second line of output describes the link layer characteristics of the device. For Ethernet devices, this will always say "link/ether" followed by the hardware address of the device and the media broadcast address. For more detail on the link layer characteristics of a device see Section B.3, “ip link”.
Subsequent lines of output describe the IP addresses available on each interface. In a typical installation only one address is used on each interface, although an arbitrary number of addresses can also be used on each interface.
Each line contains the IP address and netmask in CIDR notation, an optional broadcast address, scope information and a label. Let's examine the scope and label first and then discuss IP addressing and broadcast calculation. The possible values for scope are outlined in the following table.
Table C.2. IP Scope under ip address
| Scope | Description |
|---|---|
| global | valid everywhere |
| site | valid only within this site (IPv6) |
| link | valid only on this device |
| host | valid only inside this host (machine) |
Scope is normally determined by the ip utility without explicit use on the command line. For example, an IP address in the 127.0.0.0/8 range falls in the range of localhost IPs, so should not be routed out any device. This explains the presence of the host scope for addresses bound to interface lo. Usually, addresses on other interfaces are public interfaces, which means that their scope will be global. We will revisit scope again when we discuss routing with ip route, and there we will also encounter the link scope.
Now, let's examine IP addressing with the ip address utility by adding and removing IP addresses from active interfaces.
If you need to host an additional IP address on tristan, here's how you would accomplish this task.
Example C.7. Adding IP addresses to an interface with ip address
|
There are a few items of note. You can use ip address add even if the link layer on the device is down. This means that you can readdress an interface without bringing it up. When you add an address within the same CIDR network as another address on the same interface, the second address becomes a secondary address, meaning that if the first address is removed, the second address will also be purged from the interface.
In order to support compatibility with ifconfig the ip address command allows the user to specify a label on every hosted address on a given device. After adding an address to an interface as we did in Example C.7, “Adding IP addresses to an interface with ip address”, ifconfig will not report that the new IP 192.168.99.37 is hosted on the same device as the primary IP 192.168.99.35. In order to prevent this sort of confusion or apparently contradictory output, you should get in the habit of using the label option to identify each IP hosted on a device. Let's take a look at how to remove the 192.168.99.37 IP from eth0 and add it back so that ifconfig will report the presence of another IP on the eth0 device.
There is a difference between IPs considered as primary addresses on an interface and secondary addresses. If in the output, an address is listed as a secondary address, removing the primary address will also remove the secondary address.
A workaround is to set the netmask on the second address added to the interface to /32. Unfortunately, this subterfuge will prevent the kernel from entering the correct corresponding network and broadcast routes.
Example C.8. Removing IP addresses from interfaces with ip address
|
Taking the minor precaution of using labels on IP addresses added to an interface will prevent confusion if there are multiple administrators of a machine, some of whom use ifconfig.
Finally, let's look at the use of ip address flush. If an interface has already had IP addresses assigned to it, and all of the addresses need to be removed (along with their routes), there is one handy command to accomplish all of these tasks. ip address flush takes an interface name as an argument. Let's look at the output of ip address show just before and just after removing all IPs.
Example C.9. Removing all IPs on an interface with ip address flush
|
As you can see, the ip address utility provides a wealth of information and a great deal of control over the IPs associated with each device. For more detailed information about the iproute2 package and included tools, see Section I.1.6, “iproute2 documentation”.
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
