Linux Networking
Linux provides several methods for managing network devices and interfaces on a system. Usually, a system administrator can accomplish the same task using several different methods. A network device or an interface is managed by the kernel, and each method accesses the Linux kernel via a different path. There are three popular methods for managing Linux networking:
Using the command-line ip utility
Using the NetworkManager service
Using network configuration files
This section covers these three methods listed. It should be fairly easy to use the help resources on your Linux distro, such as the man and info pages, to learn about any utility not covered here.
The ip Utility
ip is a command-line utility that is part of the iproute2 group of utilities. It is invoked using the command ip [options] {object} {action}. This syntax is quite intuitive in that the action in the command indicates what action you would want to apply to an object. For example, the command ip link show applies the action show to the object link. As you may have guessed, this command displays the state of all network interfaces (links) on the system, as shown in Example 3-40. To limit the output to one specific interface, you can add dev {intf} to the end of the command, as also shown in the example.
Example 3-40 Output of the Command ip link show
[NetProg@localhost ~]$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
DEFAULT qlen 1000
link/ether 08:00:27:a7:32:f7 brd ff:ff:ff:ff:ff:ff
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
DEFAULT qlen 1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
4: enp0s9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
DEFAULT qlen 1000
link/ether 08:00:27:b4:ce:55 brd ff:ff:ff:ff:ff:ff
5: enp0s10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
mode DEFAULT qlen 1000
link/ether 08:00:27:48:59:02 brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
mode DEFAULT qlen 1000
link/ether 52:54:00:ea:c5:d4 brd ff:ff:ff:ff:ff:ff
7: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state
DOWN mode DEFAULT qlen 1000
link/ether 52:54:00:ea:c5:d4 brd ff:ff:ff:ff:ff:ff
[NetProg@localhost ~]$ ip link show dev enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
DEFAULT qlen 1000
link/ether 08:00:27:a7:32:f7 brd ff:ff:ff:ff:ff:ff
[NetProg@localhost ~]$
Table 3-1 lists some of the objects that are commonly used with the ip command.
Table 3-1 Objects That Are Commonly Used with the ip Command
Object |
Description |
|---|---|
address |
IPv4 or IPv6 protocol address |
link |
Network interface |
route |
Routing table entry |
maddress |
Multicast address |
neigh |
ARP entry |
As of this writing, there are 19 objects that can be acted upon by using the ip command. A full list of objects can be found in the man pages for the ip command. Objects can be written in full or in abbreviated form, such as address or addr. The actions that can be used with the ip command are limited to three options listed in Table 3-2.
Table 3-2 Actions That Can Be Used with the ip Command
Action |
Description |
|---|---|
add |
Adds the object |
delete |
Deletes the object |
show (or list) |
Displays information about the object |
The keyword show or list can be dropped from a command, and the command will still be interpreted as a show action. For example, the command ip link show is equivalent to just ip link.
The ip addr command lists all interfaces on the system, each with its IP address information, and the ip maddr command displays the multicast information for each and every interface. The ip neigh command displays the ARP table. The ARP table consists of a list of neighbors on each interface on the local network. The examples in this section show how to use these show commands.
You can bring an interface on Linux up or down by using the command ip link set {intf} {up|down}. The set action is only applicable to the link object and therefore was not listed in Table 3-2. Example 3-41 shows how to bring interface enp0s8 down and then up again. Note that changing networking configuration on Linux, including toggling an interface’s state, requires root privileges. The show commands, however, do not. To keep Example 3-41 short and avoid the frequent password prompt, all commands in the example are issued by the root user. However, running commands as root in general is not a recommended practice. On a production network, make sure to avoid logging in as root. It is best practice to log in with your regular user account and use the sudo command whenever a command requires root privileges to execute, as explained in Chapter 2.
Example 3-41 Toggling Interface State
[root@localhost ~]# ip link show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
DEFAULT qlen 1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
[root@localhost ~]# ip link set enp0s8 down
[root@localhost ~]# ip link show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT
qlen 1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
[root@localhost ~]# ip link set enp0s8 up
[root@localhost ~]# ip link show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode
DEFAULT qlen 1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
[root@localhost ~]#
You can add an IP address to an interface by using the command ip addr add {IP_address} dev {intf}. By replacing the action add with del, you remove the IP address. In Example 3-42, IP address 10.1.0.10/24 is added to interface enp0s8, and then the original IP address, 10.1.0.1/24, is removed. The ip addr show dev enp0s8 command is used to inspect the interface IP address before and after the change.
Example 3-42 Adding and Removing IP Addresses on Interfaces
[root@localhost ~]# ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.1/24 brd 10.1.0.255 scope global enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::8b8:d663:847f:79d9/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]# ip addr add 10.1.0.10/24 dev enp0s8
[root@localhost ~]# ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.1/24 brd 10.1.0.255 scope global enp0s8
valid_lft forever preferred_lft forever
inet 10.1.0.10/24 scope global secondary enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::8b8:d663:847f:79d9/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]# ip addr del 10.1.0.1/24 dev enp0s8
[root@localhost ~]# ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 08:00:27:83:40:75 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.10/24 scope global enp0s8
valid_lft forever preferred_lft forever
inet6 fe80::8b8:d663:847f:79d9/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]#
Notice that the IP address 10.1.0.10/24 is added as a secondary address, as long as another IP address is configured on the interface. When the original IP address is removed, the new IP address becomes the primary address.
Notice the mtu value in the output of the ip addr show command in Example 3-42. By default the mtu is set to 1500 bytes. To change that value, you use the command ip link set {intf} mtu {mtu_value}.
A very useful feature that any network engineer would truly appreciate is interface promiscuous mode. By default, when an Ethernet frame is received on an interface, that frame is passed on to the upper layers for processing only if the destination MAC address of the frame matches the MAC address of the interface (or if the destination MAC address is a broadcast address). If the MAC addresses do not match, the frame is ignored. This renders packet sniffing applications such as Wireshark and features such as port mirroring unusable. In promiscuous mode, an interface accepts any and all incoming packets, whether the packets are addressed to that interface or not. You can enable promiscuous mode by using the command ip link set {intf} promisc on.
In the routing table, the list of routes on the system can be displayed by using the command ip route. Example 3-43 shows that the routing table is empty when no IP addresses are configured on any of the interfaces. When the IP address 10.2.0.30/24 is configured on interface enp0s3, one entry, corresponding to that interface, is added to the routing table.
Example 3-43 Viewing a Routing Table by Using the ip route Command
[NetProg@server4 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 08:00:27:2c:61:d0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a00:27ff:fe2c:61d0/64 scope link
valid_lft forever preferred_lft forever
[NetProg@server4 ~]$ ip route
[NetProg@server4 ~]$ sudo ip addr add 10.2.0.30/24 dev enp0s3
[sudo] password for NetProg:
[NetProg@server4 ~]$ ip addr show dev enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen
1000
link/ether 08:00:27:2c:61:d0 brd ff:ff:ff:ff:ff:ff
inet 10.2.0.30/24 scope global enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe2c:61d0/64 scope link
valid_lft forever preferred_lft forever
[NetProg@server4 ~]$ ip route
10.2.0.0/24 dev enp0s3 proto kernel scope link src 10.2.0.30
[NetProg@server4 ~]$
Routing tables on Linux systems are very similar to routing tables on routers. In fact, a Linux server could easily function as a router. In order to display routing table functionality in Linux, server1 in the topology in Figure 3-2 is used as a router to route traffic between server2 and server3. server2 is connected to network 10.1.0.0/24, and server3 is connected to network 10.2.0.0/24. All three servers are configured such that server1 routes between the two networks, and eventually server2 should be able to ping server3.
)
Figure 3-2 Server1 Configured to Route Between server2 and server3, Each on a Different Subnet
IP addressing needs to be configured first. server1 is configured with IP addresses ending with .10, server2 with an IP address ending in .20, and server3 with an IP address ending in .30, as shown in Example 3-44.
Example 3-44 Configuring IP Addresses on the Interfaces Connecting The Three Servers
! server1
[root@server1 ~]# ip addr add 10.1.0.10/24 dev enp0s8
[root@server1 ~]# ip addr add 10.2.0.10/24 dev enp0s9
[root@server1 ~]# ip addr show enp0s8 | grep "inet "
inet 10.1.0.10/24 scope global enp0s8
[root@server1 ~]# ip addr show enp0s9 | grep "inet "
inet 10.2.0.10/24 scope global enp0s9
[root@server1 ~]#
! server2
[root@server2 ~]# ip addr add 10.1.0.20/24 dev enp0s3
[root@server2 ~]# ip addr show enp0s3 | grep "inet "
inet 10.1.0.20/24 scope global enp0s3
[root@server2 ~]#
! server3
[root@server3 ~]# ip addr add 10.2.0.30/24 dev enp0s3
[root@server3 ~]# ip addr show dev enp0s3 | grep "inet "
inet 10.2.0.30/24 scope global enp0s3
[root@server3 ~]#
A ping to the directly connected server is successful on all three servers. However, when server2 attempts to ping server3, the ping fails, as shown in Example 3-45.
Example 3-45 Pinging the Directly Connected Interfaces Is Successful but Pinging server3 From server2 Is Not
! Pinging the directly connected interfaces ! server2 to server1 [root@server2 ~]# ping -c 1 10.1.0.10 PING 10.1.0.10 (10.1.0.10) 56(84) bytes of data. 64 bytes from 10.1.0.10: icmp_seq=1 ttl=64 time=0.796 ms --- 10.1.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.796/0.796/0.796/0.000 ms [root@server2 ~]# ! server3 to server1 [root@server3 ~]# ping -c 1 10.2.0.10 PING 10.2.0.10 (10.2.0.10) 56(84) bytes of data. 64 bytes from 10.2.0.10: icmp_seq=1 ttl=64 time=1.13 ms --- 10.2.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.139/1.139/1.139/0.000 ms [root@server3 ~]# ! Pinging server2 to server3 and vice versa is not successful ! server2 to subnet 10.2.0.0/24 [root@server2 ~]# ping 10.2.0.10 connect: Network is unreachable [root@server2 ~]# ping 10.2.0.30 connect: Network is unreachable [root@server2 ~]# ! server3 to subnet 10.1.0.0/24 [root@server3 ~]# ping -c 1 10.1.0.10 connect: Network is unreachable [root@server3 ~]# ping -c 1 10.1.0.20 connect: Network is unreachable [root@server3 ~]#
You are probably very familiar with the ping command. ping works on Linux exactly as it does on network devices: by sending one or more ICMP packets to the destination and either receiving an ICMP reply if the ping is successful (one reply per packet sent) or receiving an ICMP unreachable packet or no response at all if the ping is not. The command in Example 3-45 uses the -c 1 option to send a single ICMP packet, which is enough to test the reachability of the destination.
Example 3-46 shows how to use the command ip route add 10.2.0.0/24 via 10.1.0.10 on server2 and the command ip route add 10.1.0.0/24 via 10.2.0.10 on server3 to add routes to the routing tables of each server. The general syntax for adding a route to the routing table is ip route add {destination}{/mask} via {nexthop}. The routes instruct each server to use server1 as the next hop to reach the remote network. After the routes are added, server2 and server3 are able to ping server1’s interface on the remote network, but they are still not able to ping each other.
Example 3-46 Adding Routing Table Entries for Remote Subnets on server2 and server3. server2 and server3 Can Ping the Remote Subnets on server1, But Still Cannot Ping Each Other
! server2 [root@server2 ~]# ip route add 10.2.0.0/24 via 10.1.0.10 [root@server2 ~]# ip route 10.1.0.0/24 dev enp0s3 proto kernel scope link src 10.1.0.20 10.2.0.0/24 via 10.1.0.10 dev enp0s3 [root@server2 ~]# ping -c 1 10.2.0.10 PING 10.2.0.10 (10.2.0.10) 56(84) bytes of data. 64 bytes from 10.2.0.10: icmp_seq=1 ttl=64 time=0.822 ms --- 10.2.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.822/0.822/0.822/0.000 ms [root@server2 ~]# ping -c 1 10.2.0.30 PING 10.2.0.30 (10.2.0.30) 56(84) bytes of data. --- 10.2.0.30 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms [root@server2 ~]# ! server3 [root@server3 ~]# ip route add 10.1.0.0/24 via 10.2.0.10 [root@server3 ~]# ip route 10.1.0.0/24 via 10.2.0.10 dev enp0s3 10.2.0.0/24 dev enp0s3 proto kernel scope link src 10.2.0.30 [root@server3 ~]# ping -c 1 10.1.0.10 PING 10.1.0.10 (10.1.0.10) 56(84) bytes of data. 64 bytes from 10.1.0.10: icmp_seq=1 ttl=64 time=0.865 ms --- 10.1.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.865/0.865/0.865/0.000 ms [root@server3 ~]# ping -c 1 10.1.0.20 PING 10.1.0.20 (10.1.0.20) 56(84) bytes of data. --- 10.1.0.20 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms [root@server3 ~]#
Forwarding between the interfaces on server1 is disabled by default for security reasons. Therefore, the remaining step is to enable forwarding in the kernel of server1 by toggling the default value of 0 in file /proc/sys/net/ipv4/ip_forward to 1 by using either the command echo 1 > /proc/sys/net/ipv4/ip_forward or the command /sbin/sysctl -w net.ipv4.ip_forwad=1. After either command is used, forwarding is enabled, and both servers can ping each other successfully, as shown in Example 3-47.
Example 3-47 Enabling Routing on Server1 Resulting in Successful ping Between server2 and server3
! Enabling routing on server1 [root@server1 ~]# echo 1 > /proc/sys/net/ipv4/ip_forward [root@server1 ~]# cat /proc/sys/net/ipv4/ip_forward 1 ! server2 to server3 ping is successful [root@server2 ~]# ping -c 1 10.2.0.30 PING 10.2.0.30 (10.2.0.30) 56(84) bytes of data. 64 bytes from 10.2.0.30: icmp_seq=1 ttl=63 time=0.953 ms --- 10.2.0.30 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.953/0.953/0.953/0.000 ms [root@server2 ~]# ! server3 to server2 ping is successful [root@server3 ~]# ping -c 1 10.1.0.20 PING 10.1.0.20 (10.1.0.20) 56(84) bytes of data. 64 bytes from 10.1.0.20: icmp_seq=1 ttl=63 time=1.39 ms --- 10.1.0.20 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.394/1.394/1.394/0.000 ms [root@server3 ~]#
Note that two commands to achieve the same result are mentioned here. The first method gets the job done by editing a file, and the second gets the same job done by using the command sysctl. Which one you should use depends on several factors, the first of which is personal preference. Another issue is whether you know which file in the /proc/sys/ directory contains the kernel setting (sometimes referred to as a kernel tunable) that you need to change. If you do not know the file, you can simply use the sysctl command to target the parameter directly, regardless of where it is located. You can list all kernel tunables by using the command /sbni/sysctl -a.
To remove a routing table entry, you use the syntax ip route delete {destination}{/mask} via {nexthop}. You can also have routes point to exit interfaces rather than next hops by using the syntax ip route add {destination}{/mask} dev {intf}. You can add a default route by using the syntax ip route add default via {next_hop} dev {intf}.
One final note on the ip utility is that any configuration performed using the commands discussed in this section is not persistent. Any changes to the configuration disappear after a system reboot. Persistent configuration is discussed in the following sections.
The NetworkManager Service
NetworkManager is the default network management service on several Linux distros, including Red Hat and Fedora. Because NetworkManager is a service, you can check its status, and you can start, stop, enable, or disable it as you can any other service on Linux by using the systemctl command. For example, the command systemctl status networkmanager displays the current status of the service. To poll NetworkManager for information or push configuration to it, you can use one of several user interfaces:
Graphical user interfaces (GUIs): There are two main graphical user interface tools that interact with NetworkManager. The first is the Network Control Center, which is accessible via the Settings menu. The Settings window has an icon labeled Network that opens the network control center, which provides basic network configuration. The other GUI tool is the Connection Editor and is used to configure more advanced settings. You can start the Connection Editor from the terminal by entering the command nm-connection-editor.
NetworkManager command-line interface (nmcli): The NetworkManager CLI is a command-line utility that you can use to control NetworkManager. You can use this interface to NetworkManager via the nmcli command in the Bash shell.
NetworkManager text user interface (nmtui): Similar to the interface used to configure a computer’s BIOS settings or old DOS-based programs, the nmtui provides an interface to NetworkManager that displays graphics in text mode. You start the text user interface by issuing the nmtui command in the shell.
API: NetworkManager provides an API that can be used by applications for programmatic access to NetworkManager.
Because the majority of automation is typically performed through CLI tools (and API calls) and not the GUI, this section cover NetworkManager configuration via the nmcli interface.
NetworkManager deals with objects called connections. A connection is a representation of a link to the outside world and may represent, for example, a wired connection, a wireless connection, or a VPN connection. To display the current status of all network connections on a system, use the command nmcli con show, as shown in Example 3-48.
Example 3-48 Listing All Connections on a System
[root@server1 ~]# nmcli con show NAME UUID TYPE DEVICE Wired connection 1 d8323782-5cf2-3afc-abcd-e603605ac4f8 802-3-ethernet -- Wired connection 2 669fefb4-bc57-3d19-b83b-2b2125e0036b 802-3-ethernet -- [root@server1 ~]#
The output in Example 3-48 indicates that there are two connections, named Wired connection 1 and Wired connection 2. These connections are not bound (applied) to any interfaces, as indicated by the -- in the last column. Both connections are of type Ethernet. A connection is uniquely identified by its universally unique identifier (UUID). Although not shown in the command output, a connection can either be active or inactive. To activate an inactive connection, you use the command nmcli con up {connection_ name}. To deactivate a connection, you replace the keyword up with the keyword down.
Each connection is known as a connection profile and contains several attributes or properties that you can set. These properties are known as settings. Connection profile settings are created and then applied to a device or device type. Settings are represented in a dot notation. For example, a connection’s IPv4 addresses are represented by the setting ipv4.addresses. To drill down on the details for a specific connection and list its settings and their values, you can use the command nmcli con show {connection_name}. Example 3-49 lists the connection profile settings for Wired connection 1. The output is truncated due to the length of the list. A full list of settings and their meanings can be found in the man pages for the nmcli command.
Example 3-49 Connection Attributes for Wired Connection 1
[root@server1 ~]# nmcli con show "Wired connection 1" connection.id: Wired connection 1 connection.uuid: d8323782-5cf2-3afc-abcd-e603605ac4f8 connection.stable-id: -- connection.interface-name: -- connection.type: 802-3-ethernet connection.autoconnect: yes connection.autoconnect-priority: -999 connection.autoconnect-retries: -1 (default) connection.timestamp: 1525512827 connection.read-only: no connection.permissions: -- connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: -- connection.gateway-ping-timeout: 0 connection.metered: unknown connection.lldp: -1 (default) 802-3-ethernet.port: -- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: no 802-3-ethernet.mac-address: 08:00:27:83:40:75 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.generate-mac-address-mask:-- 802-3-ethernet.mac-address-blacklist: -- 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: -- 802-3-ethernet.s390-nettype: -- 802-3-ethernet.s390-options: -- 802-3-ethernet.wake-on-lan: 1 (default) 802-3-ethernet.wake-on-lan-password: -- ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: (default) ipv4.dns-priority: 0 ipv4.addresses: -- ipv4.gateway: -- ipv4.routes: -- --------- OUTPUT TRUNCATED FOR BREVITY ---------
To list the devices (aka interfaces) on the system and the status of each one, you use the command nmcli dev status for all devices or the command nmcli dev show {device_name} for a specific device, as shown in Example 3-50.
Example 3-50 Device Status Using the nmcli dev status and nmcli dev show Commands
[root@server1 ~]# nmcli dev status DEVICE TYPE STATE CONNECTION enp0s8 ethernet disconnected -- enp0s9 ethernet disconnected -- lo loopback unmanaged -- [root@server1 ~]# nmcli dev show enp0s8 GENERAL.DEVICE: enp0s8 GENERAL.TYPE: ethernet GENERAL.HWADDR: 08:00:27:83:40:75 GENERAL.MTU: 1500 GENERAL.STATE: 30 (disconnected) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- WIRED-PROPERTIES.CARRIER: on [root@server1 ~]#
As you can see from the outputs in Examples 3-49 and 3-50, connections and devices are mutually exclusive. A connection profile may or may not be applied to a device after it is created.
In Example 3-51, both of the wired connections are deleted, and one new connection named NetDev_1 is created. NetDev_1 is of type ethernet and is applied to device enp0s8. Connections are deleted using the command nmcli con del {connection_name}. You create new connections and configure their settings by using the command nmcli con add {connection_name} {setting} {value}. In Example 3-51, the type, ifname, ip4, and gw4 settings are set to Ethernet, enp0s8, 10.1.0.10/24, and 10.1.0.254, respectively. Note that in this command, setting can either be entered in the full dot format or in abbreviated format. For example, the IP address can be set using either ip4 or ipv4.address.
Example 3-51 Deleting and Creating Connections
[root@server1 ~]# nmcli con show NAME UUID TYPE DEVICE Wired connection 1 d8323782-5cf2-3afc-abcd-e603605ac4f8 802-3-ethernet -- Wired connection 2 669fefb4-bc57-3d19-b83b-2b2125e0036b 802-3-ethernet -- [root@server1 ~]# nmcli con del "Wired connection 1" Connection 'Wired connection 1' (d8323782-5cf2-3afc-abcd-e603605ac4f8) successfully deleted. [root@server1 ~]# nmcli con del "Wired connection 2" Connection 'Wired connection 2' (669fefb4-bc57-3d19-b83b-2b2125e0036b) successfully deleted. [root@server1 ~]# nmcli con show NAME UUID TYPE DEVICE [root@server1 ~]# nmcli con add con-name NetDev_1 type ethernet ifname enp0s8 ip4 10.1.0.10/24 gw4 10.1.0.254 Connection 'NetDev_1' (a8ac9116-697a-4a0a-85a2-63428d6e75a3) successfully added. [root@server1 ~]# nmcli con show NAME UUID TYPE DEVICE NetDev_1 a8ac9116-697a-4a0a-85a2-63428d6e75a3 802-3-ethernet enp0s8 [root@server1 ~]# nmcli con show --active NAME UUID TYPE DEVICE NetDev_1 a8ac9116-697a-4a0a-85a2-63428d6e75a3 802-3-ethernet enp0s8 [root@server1 ~]# nmcli dev status DEVICE TYPE STATE CONNECTION enp0s8 ethernet connected NetDev_1 enp0s9 ethernet disconnected -- lo loopback unmanaged -- [root@server1 ~]# nmcli dev show enp0s8 GENERAL.DEVICE: enp0s8 GENERAL.TYPE: ethernet GENERAL.HWADDR: 08:00:27:83:40:75 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: NetDev_1 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/359 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 10.1.0.10/24 IP4.GATEWAY: 10.1.0.254 IP6.ADDRESS[1]: fe80::8c1f:4c4a:51a5:6423/64 IP6.GATEWAY: -- [root@server1 ~]# ping 10.1.0.20 -c 3 PING 10.1.0.20 (10.1.0.20) 56(84) bytes of data. 64 bytes from 10.1.0.20: icmp_seq=1 ttl=64 time=0.604 ms 64 bytes from 10.1.0.20: icmp_seq=2 ttl=64 time=0.602 ms 64 bytes from 10.1.0.20: icmp_seq=3 ttl=64 time=0.732 ms --- 10.1.0.20 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2011ms rtt min/avg/max/mdev = 0.602/0.646/0.732/0.060 ms [root@server1 ~]#
Notice that once a connection has been created and the device enp0s8 has been bound to it (all in the same command), the connection and device both come up, and that results in the device successfully pinging server2 on the other end of the link.
After a connection is created, you can modify its settings by using the command nmcli con mod {connection_name} {setting} {value}. When modifying a setting, the full dot format is required in the command. If the shorthand format is used, the new value in the command may be added to the existing value of the setting. For example, if the shorthand format is used to modify the IP address, the new IP address in the command is added to the device as a secondary IP address. On the other hand, if the full dot format is used, the IP address in the command replaces the IP address configured on the device. Example 3-52 shows how to modify the IP address of device enp0s8 to 10.1.0.100/24.
Example 3-52 Deleting and Creating Connections
[root@server1 ~]# nmcli con show NetDev_1 | grep ipv4.addr ipv4.addresses: 10.1.0.10/24 [root@server1 ~]# nmcli dev show enp0s8 | grep IP4.ADD IP4.ADDRESS[1]: 10.1.0.10/24 [root@server1 ~]# nmcli con mod NetDev_1 ip4 10.1.0.100/24 ! The new IP address is added as a secondary address due to the shorthand format [root@server1 ~]# nmcli con show NetDev_1 | grep ipv4.addr ipv4.addresses: 10.1.0.10/24, 10.1.0.100/24 ! The new IP address is not reflected to the device enp0s8 [root@server1 ~]# nmcli dev show enp0s8 | grep IP4.ADD IP4.ADDRESS[1]: 10.1.0.10/24 [root@server1 ~]# nmcli con up NetDev_1 Connection successfully activated (D-Bus active path: /org/freedesktop/ NetworkManager/ActiveConnection/366) ! After resetting the con, the new IP address now is reflected to the device [root@server1 ~]# nmcli dev show enp0s8 | grep IP4.ADD IP4.ADDRESS[1]: 10.1.0.10/24 IP4.ADDRESS[2]: 10.1.0.100/24 ! Using the full dot format will replace the old IP address with the new one [root@server1 ~]# nmcli con mod NetDev_1 ipv4.address 10.1.0.100/24 [root@server1 ~]# nmcli con up NetDev_1 Connection successfully activated (D-Bus active path: /org/freedesktop/ NetworkManager/ActiveConnection/367) [root@server1 ~]# nmcli con show NetDev_1 | grep ipv4.addr ipv4.addresses: 10.1.0.100/24 [root@server1 ~]# nmcli dev show enp0s8 | grep IP4.ADD IP4.ADDRESS[1]: 10.1.0.100/24 [root@server1 ~]#
Note that each time a change is made to a connection using nmcli, the connection needs to be reactivated in order for the changes to be reflected to the device.
Adding routes using nmcli is different than adding routes using the ip utility in that when using nmcli, routes are added per interface and not globally. You add routes by using the syntax nmcli con mod {intf} +ipv4.routes {destination} ipv4.gateway {next_hop}. Therefore, to accomplish the same task that was done earlier by using the ip utility (to add a route on server2 to direct traffic destined for network 10.2.0.0/24 using the next hop 10.1.0.10 on server1), you use the following command: nmcli con mod enp0s3 +ipv4.routes 10.2.0.0/24 ipv4.gateway 10.1.0.10.
Unlike with the ip utility, changes made through nmcli are, by default, persistent and will survive a system reload.
It is important to understand the difference between the ip utility and NetworkManager. The ip utility is a program. When you use the ip command, you run this program, which makes a system call to the kernel, either to retrieve information or configure a component of the Linux networking system.
On the other hand, NetworkManager is a system daemon. It is software that runs (lurks) in the background, by default, and oversees the operation of the Linux network system. NetworkManager may be used to configure components of the network or to retrieve information about the network by using a variety of methods discussed earlier in this section–one of them being nmcli.
The nuances of how the ip utility interacts with NetworkManager are not discussed in detail here. All you need to know for now is that changes to the network that are made via the ip utility are detected and preserved by NetworkManager. There is no conflict between them. As mentioned at the very beginning of this section, different software on Linux can achieve the same result via different communication channels with the kernel. However, any software that needs access to the network will eventually have to go through the kernel.
Network Scripts and Configuration Files
The third method for configuring network devices and interfaces is to modify network scripts and configuration files directly. Different files in Linux control different components of the networking ecosystem, and editing these files was the only way to configure networking on Linux before NetworkManager was developed. Configuration files and scripts can still be used instead of, or in addition to, NetworkManager.
On Linux distros in the Red Hat family, configuration files for network interfaces are located in the /etc/sysconfig/network-scripts directory, and each interface configuration file is named ifcfg-<intf_name>. The first script that is executed on system bootup is /etc/init.d/network. When the system boots up, this script reads through all interface configuration files whose names start with ifcfg. Example 3-53 shows the ifcfg file for the enp0s8 interface.
Example 3-53 Interface Configuration File for Interface enp0s8
[root@server1 network-scripts]# cat ifcfg-enp0s8 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=NetDev_1 UUID=a8ac9116-697a-4a0a-85a2-63428d6e75a3 DEVICE=enp0s8 ONBOOT=yes [root@server1 network-scripts]#
The filename just needs to be prefixed with ifcfg. The network script simply scans the directory and reads any file whose name has this prefix. Therefore, you can safely assume that the configuration file is for the interface or connection. However, while the filename has to start with ifcfg, there is general consensus that the value in the DEVICE field (interface) should follow the ifcfg prefix.
The TYPE field in the file indicates the connection type, which is Ethernet in this case. The BOOTPROTO field is set to dhcp, which means the connection gets an IP address via DHCP. If a static IP address is required on the interface, then dhcp is replaced with none. The interface associated with this configuration is also shown in the DEVICE field (enp0s8 in this case), and the ONBOOT field indicates that this connection is to be brought up at system bootup. When a static IP address is required on the interface, the fields IPADDR, PREFIX, and GATEWAY and their respective values are added to the file.
When ONBOOT=yes is set, the /etc/init.d/network script checks whether this interface is managed by NetworkManager. If it is and the connection has already been activated, no further action is taken. If the connection has not been activated, the script requests NetworkManager to activate the connection. In case the connection is not managed by NetworkManager, the network script activates the connection by running another script, /usr/sbin/ifup. The ifup script checks the field TYPE in the ifcfg file, and based on that, it calls another type-specific script. For example, if the type of the connection is Ethernet, the ifup-eth script is called. Linux requires type-specific scripts because different connection types require different configuration parameters. For example, the concept of an SSID (wireless network name) does not exist for an Ethernet connection. Similarly, to bring down an interface for an unmanaged interface, the ifdown script is called. The vast majority of interface types are managed by NetworkManager by default, unless the line NM_CONTROLLED=no has been added to the ifcfg file.
While the recommended method for configuring interfaces is to use the nmcli utility, as discussed in the previous section, you can also configure interfaces by editing the corresponding ifcfg file.
Static routes configured on a system have configuration files named route-<intf_name> in the same directory as the interface configuration files. As you have probably guessed, the name has to be prefixed with route. However, the -<intf_name> is just a naming convention, and the file may have any name as long as the prefix route is there. The routing entries in the file may have one of two formats:
The ip command arguments format:
{destination}/{mask} via {next_hop} [dev interface]
With this format, specifying the interface using [dev interface] is optional.
The network/netmask directives format:
ADDRESS{N}:{destination}
NETMASK{N}:{netmask}
GATEWAY{N}:{next_hop}
where N is the routing table entry starting with 0 and incrementing by 1 for each entry, without skipping any values. In other words, if the routing table has four entries, the entries are numbered from 0 to 3.
Going back to the network of three servers in Figure 3-2, where server1 is required to route between server2 on subnet 10.1.0.0/24 and server3 on subnet 10.2.0.0/24: the static routes previously configured in order to route between the servers are deleted, after which the ping from server2 to server3 fails, as shown in Example 3-54.
Example 3-54 Ping Fails Due To Lack of Static Routes on server2 and server3
! No routes in routing table of server2 to remote subnet 10.2.0.0/24 [root@server2 ~]# ip route 10.1.0.0/24 dev enp0s3 proto kernel scope link src 10.1.0.20 metric 100 [root@server2 ~]# ! Ping to the directly connected interface on server1 is successful [root@server2 ~]# ping -c 1 10.1.0.10 PING 10.1.0.10 (10.1.0.10) 56(84) bytes of data. 64 bytes from 10.1.0.10: icmp_seq=1 ttl=64 time=0.828 ms --- 10.1.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.828/0.828/0.828/0.000 ms [root@server2 ~]# ! Ping to server3 on subnet 10.2.0.0/24 is not successful [root@server2 ~]# ping -c 1 10.2.0.30 connect: Network is unreachable [root@server2 ~]# ! No routes in routing table of server3 to remote subnet 10.1.0.0/24 [root@server3 ~]# ip route 10.2.0.0/24 dev enp0s3 proto kernel scope link src 10.2.0.30 metric 100 [root@server3 ~]# ! Ping to the directly connected interface on server1 is successful [root@server3 ~]# ping -c 1 10.2.0.10 PING 10.2.0.10 (10.2.0.10) 56(84) bytes of data. 64 bytes from 10.2.0.10: icmp_seq=1 ttl=64 time=0.780 ms --- 10.2.0.10 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.780/0.780/0.780/0.000 ms [root@server3 ~]# ! Ping to server2 on subnet 10.1.0.0/24 is not successful [root@server3 ~]# ping -c 1 10.1.0.20 connect: Network is unreachable [root@server3 ~]#
The file route-enp0s3 is created under the directory /etc/sysconfig/network-scripts/ on both servers. A routing entry is added to the routing configuration file on server2 by using the ip command arguments format, and a routing entry is added to the file on server3 by using the network/netmask directives format, as shown in Example 3-55.
Example 3-55 Routing Configuration Files Added on Both server2 and server3
! server2 ! No routing configuration files in the directory [root@server2 ~]# cd /etc/sysconfig/network-scripts/ [root@server2 network-scripts]# ls -l | grep "route" [root@server2 network-scripts]# ! Create the file route-enp0s3 and populate it with a route to the remote subnet 10.2.0.0/24 using the IP Command Arguments format [root@server2 network-scripts]# touch route-enp0s3 [root@server2 network-scripts]# echo "10.2.0.0/24 via 10.1.0.10" >> route-enp0s3 [root@server2 network-scripts]# ls -l | grep " route" -rw-r--r--. 1 root root 26 Aug 17 15:52 route-enp0s3 [root@server2 network-scripts]# cat route-enp0s3 10.2.0.0/24 via 10.1.0.10 [root@server2 network-scripts]# ! Restart the network service and check the routing table [root@server2 network-scripts]# systemctl restart network [root@server2 network-scripts]# ip route 10.1.0.0/24 dev enp0s3 proto kernel scope link src 10.1.0.20 metric 100 10.2.0.0/24 via 10.1.0.10 dev enp0s3 proto static metric 100 [root@server2 network-scripts]# ! server3 ! No routing configuration files in the directory [root@server3 ~]# cd /etc/sysconfig/network-scripts/ [root@server3 network-scripts]# ls -l | grep " route" ! Create the file route-enp0s3 and populate it with a route to the remote subnet 10.1.0.0/24 using the Network/Netmask Directives format [root@server3 network-scripts]# touch route-enp0s3 [root@server3 network-scripts]# echo "ADDRESS0=10.1.0.0" >> route-enp0s3 [root@server3 network-scripts]# echo "NETMASK0=255.255.255.0" >> route-enp0s3 [root@server3 network-scripts]# echo "GATEWAY0=10.2.0.10" >> route-enp0s3 [root@server3 network-scripts]# ls -l | grep " route" -rw-r--r--. 1 root root 60 Aug 17 16:04 route-enp0s3 [root@server3 network-scripts]# cat route-enp0s3 ADDRESS0=10.1.0.0 NETMASK0=255.255.255.0 GATEWAY0=10.2.0.10 [root@server3 network-scripts]# ! Restart the network service and check the routing table [root@server3 network-scripts]# systemctl restart network [root@server3 network-scripts]# ip route 10.1.0.0/24 via 10.2.0.10 dev enp0s3 proto static metric 100 10.2.0.0/24 dev enp0s3 proto kernel scope link src 10.2.0.30 metric 100 [root@server3 network-scripts]#
The ping test is now successful, and server2 can reach server3, as shown in Example 3-56.
Example 3-56 Ping from server2 to server3 and Vice Versa Is Successful Now
[root@server2 network-scripts]# ping -c 1 10.2.0.30 PING 10.2.0.30 (10.2.0.30) 56(84) bytes of data. 64 bytes from 10.2.0.30: icmp_seq=1 ttl=63 time=2.11 ms --- 10.2.0.30 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.119/2.119/2.119/0.000 ms [root@server2 network-scripts]# [root@server3 network-scripts]# ping -c 1 10.1.0.20 PING 10.1.0.20 (10.1.0.20) 56(84) bytes of data. 64 bytes from 10.1.0.20: icmp_seq=1 ttl=63 time=1.58 ms --- 10.1.0.20 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.585/1.585/1.585/0.000 ms [root@server3 network-scripts]#
The network script is run as a service and, like any other service, can be controlled by using the command systemctl {start|stop|restart|status} network. To enable/disable the network service at startup, you use the command chkconfig network {on|off}. Keep in mind that after a configuration file is changed, the network service has to be restarted for the changes to take effect. It goes without saying that any configuration done via amending the network configuration files is persistent and will remain intact after a system reload.
Network Services: DNS
Domain Name System (DNS) is a hierarchical naming system used on the Internet and some private networks to assign domain names to resources on the network. Domain names tend to be easier to remember than IP addresses. Using domain names provides the additional capability to resolve a domain name to multiple IP addresses for purposes such as high availability or routing user traffic based on the geographically closest server.
DNS uses the concept of a resolver, commonly referred to as a DNS server, which is a server or a database that contains mappings between domain names and the information related to each of those domain names, such as the IP addresses. These mappings are called records. DNS is hierarchical and distributed. The majority of DNS servers maintain records for only some domain names and then initiate queries to other DNS servers for the rest of the domain names, for which it does not maintain records.
Performing a DNS query means sending a request to a DNS server to resolve the domain name and return the data associated with that domain name. To resolve a domain name on Linux to its corresponding information, including its IP address, you use the dig command, which stands for domain information groper. Example 3-57 shows dig being used to resolve google.com to its public IP address. The public IP address received from the DNS response is highlighted in the example.
Example 3-57 Using the dig Command to Resolve google.com
[root@server1 ~]# dig google.com ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38879 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 264 IN A 216.58.207.14 ;; Query time: 31 msec ;; SERVER: 192.168.8.1#53(192.168.8.1) ;; WHEN: Fri Aug 17 17:16:06 +03 2018 ;; MSG SIZE rcvd: 55 [root@server1 ~]#
In Example 3-57, the DNS server used for the name resolution is 192.168.8.1. The IP address of this DNS server is configured in the /etc/resolv.conf file, shown in Example 3-58. To configure other DNS servers, you list each server’s IP address on a new line in this file.
Example 3-58 List of DNS Servers in the /etc/resolv.conf File
[root@server1 ~]# cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.8.1 [root@server1 ~]#
Manual DNS entries are configured in the /etc/hosts file. If an entry for a domain name is found in that file, the DNS servers are not consulted for resolution. There is one caveat, though: The dig command still requests the name resolution from the DNS server configured in /etc/resolv.conf. However, the ping command and also the web browsers on the system use the hosts file, and, therefore, use the manual entry there. Try to add a manual entry for google.com in the hosts file, pointing to an IP address that is not reachable and then try to use dig, use ping, and browse to google.com and notice how each of these behave differently.