Red Hat Enterprise Linux 7 Networking Guide en US
Red Hat Enterprise Linux 7 Networking Guide en US
Red Hat Enterprise Linux 7 Networking Guide en US
Networking Guide
Stephen Wadeley
Stephen Wadeley
Red Hat Engineering Co ntent Services
swadeley@redhat.co m
Legal Notice
Copyright 20102014 Red Hat, Inc.
T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux is the registered trademark of Linus T orvalds in the United States and other countries.
Java is a registered trademark of Oracle and/or its affiliates.
XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
T he OpenStack Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and
are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Abstract
T he Red Hat Enterprise Linux 7 Networking Guide documents relevant information regarding the
configuration and administration of network interfaces, networks and network services in Red Hat
Enterprise Linux 7. It is oriented towards system administrators with a basic understanding of Linux and
networking. T his book is based on the Red Hat Enterprise Linux 6 Deployment Guide. T he chapters
related to networking were taken from the Deployment Guide to form the foundation for this book.
T able of Contents
Table of Contents
. .art
P
. . .I.. IP
. . .Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . .
. .hapter
C
. . . . . . 1.
. . Introduction
. . . . . . . . . . . .to
. . Red
. . . . Hat
. . . .Enterprise
. . . . . . . . . .Linux
. . . . . Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . .
1.1. How this Book is Structured
5
1.2. IP Networks versus non-IP Networks
5
1.3. Introduction to NetworkManager
5
1.4. Installing NetworkManager
6
1.5. Network Configuration Using the Command Line Interface (CLI)
7
1.6. Network Configuration Using NetworkManager's CLI (nmcli)
7
1.7. Network Configuration Using a T ext User Interface (nmtui)
8
1.8. NetworkManager and the Network Scripts
8
1.9. Network Configuration Using sysconfig Files
9
1.10. Additional Resources
11
. .hapter
C
. . . . . . 2.
. . Configure
. . . . . . . . . .IP
. . Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
..........
2.1. Static and Dynamic Interface Settings
12
2.2. Using the T ext User Interface, nmtui
12
2.3. Using the NetworkManager Command Line T ool, nmcli
13
2.4. Using the Command Line Interface (CLI)
18
2.5. Using NetworkManager with the GNOME Graphical User Interface
22
2.6. Additional Resources
44
. .hapter
C
. . . . . . 3.
. . Configure
. . . . . . . . . .Host
. . . . Names
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. 6. . . . . . . . .
3.1. Understanding Host Names
46
3.2. Configuring Host Names Using T ext User Interface, nmtui
46
3.3. Configuring Host Names Using hostnamectl
47
3.4. Configuring Host Names Using nmcli
48
3.5. Additional Resources
49
. .hapter
C
. . . . . . 4. . .Configure
. . . . . . . . .Network
. . . . . . . .Bonding
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
..........
4 .1. Understanding the Default Behavior of Master and Slave Interfaces
50
4 .2. Configure Bonding Using the T ext User Interface, nmtui
50
4 .3. Using the NetworkManager Command Line T ool, nmcli
52
4 .4. Using the Command Line Interface (CLI)
53
4 .5. Using Channel Bonding
54
4 .6. Creating a Bond Connection Using a GUI
60
4 .7. Additional Resources
63
. .hapter
C
. . . . . . 5.
. . Configure
. . . . . . . . . .Network
. . . . . . . .T.eaming
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
..........
5.1. Understanding Network T eaming
65
5.2. Understanding the Default Behavior of Master and Slave Interfaces
65
5.3. Comparison of Network T eaming to Bonding
66
5.4. Understanding the Network T eaming Daemon and the "Runners"
66
5.5. Install the Network T eaming Daemon
67
5.6. Converting a Bond to a T eam
67
5.7. Selecting Interfaces to Use as Ports for a Network T eam
68
5.8. Selecting Network T eam Configuration Methods
68
5.9. Configure a Network T eam Using the T ext User Interface, nmtui
68
5.10. Configure a Network T eam Using the Command Line
70
5.11. Controlling teamd with teamdctl
76
5.12. Configure teamd Runners
77
5.13. Creating a Network T eam Using a GUI
84
5.14. Additional Resources
86
. .hapter
C
. . . . . . 6.
. . Configure
. . . . . . . . . .Network
. . . . . . . .Bridging
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
..........
6.1. Configure Bridging Using the T ext User Interface, nmtui
87
6.2. Using the NetworkManager Command Line T ool, nmcli
88
1
88
89
92
95
. .hapter
C
. . . . . . 7.
. . Configure
. . . . . . . . . .802.1Q
. . . . . . .VLAN
. . . . . tagging
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
..........
7.1. Configure 802.1Q VLAN tagging Using the T ext User Interface, nmtui
97
7.2. Configure 802.1Q VLAN T agging Using the Command Line T ool, nmcli
98
7.3. Configure 802.1Q VLAN T agging Using the Command Line
99
7.4. Configure 802.1Q VLAN T agging Using a GUI
101
7.5. Additional Resources
103
. .hapter
C
. . . . . . 8.
. . Configure
. . . . . . . . . .SCT
. . . .P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
...........
8.1. Introduction to Streaming Control T ransport Protocol (SCT P)
104
8.2. Understanding SCT P
105
8.3. When T o Use SCT P
107
8.4. When Not T o Use SCT P
107
8.5. Compare SCT P to Bonding and Network T eaming
107
8.6. Using SCT P
108
8.7. Additional Resources
109
. .hapter
C
. . . . . . 9.
. . Consistent
. . . . . . . . . . .Network
. . . . . . . .Device
. . . . . . Naming
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
...........
Naming Schemes for Network Interfaces
111
Naming Schemes Hierarchy
111
9.1. Understanding the Predictable Network Interface Device Names
112
9.2. Naming Scheme for Network Devices Available for Linux on System z
112
9.3. Naming Scheme for VLAN Interfaces
113
9.4. Consistent Network Device Naming Using biosdevname
113
9.5. Notes for Administrators
114
9.6. Controlling the Selection of Network Device Names
114
9.7. Understanding the Device Renaming Procedure
115
9.8. Disabling Consistent Network Device Naming
115
9.9. Additional Resources
116
. .art
P
. . .II.. .InfiniBand
. . . . . . . . . and
. . . . RDMA
. . . . . . Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
...........
. .hapter
C
. . . . . . 10.
. . . .Configure
. . . . . . . . .InfiniBand
. . . . . . . . . .and
. . . RDMA
. . . . . . Networks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
...........
10.1. Understanding InfiniBand and RDMA technologies
118
10.2. InfiniBand and RDMA related software packages
119
10.3. Configuring the Base RDMA Subsystem
120
10.4. Configuring the Subnet Manager
122
10.5. T esting Early InfiniBand RDMA operation
124
10.6. Configuring IPoIB
126
10.7. Configure InfiniBand Using the T ext User Interface, nmtui
128
10.8. Configure IPoIB using the command line tool, nmcli
130
10.9. Configure IPoIB Using the command line
131
10.10. T esting an RDMA network after IPoIB is configured
132
10.11. Configure IPoIB Using a GUI
133
10.12. Additional Resources
134
. .art
P
. . .III.
. . Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
...........
. .hapter
C
. . . . . . 11.
. . . .DHCP
. . . . . Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
...........
11.1. Why Use DHCP?
137
11.2. Configuring a DHCP Server
137
11.3. Configuring a Multihomed DHCP Server
144
11.4. DHCP for IPv6 (DHCPv6)
147
11.5. Additional Resources
148
. .hapter
C
. . . . . . 12.
. . . .DNS
. . . .Servers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
. . 9. . . . . . . . .
12.1. Introduction to DNS
149
2
T able of Contents
12.1. Introduction to DNS
12.2. BIND
149
150
.Revision
. . . . . . . .History
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
...........
A.1. Acknowledgments
176
I.ndex
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
...........
Part I. IP Networking
T his part describes how to configure the network on Red Hat Enterprise Linux.
Description
NetworkManager
nmtui
nmcli
A command line tool provided to allow users and scripts to interact with
NetworkManager
Description
control-center
nm-connection-editor
NetworkManager can be used with the following types of connections: Ethernet, VLANs, Bridges, Bonds,
T eams, Wi-Fi, mobile broadband (such as cellular 3G), and IP-over-InfiniBand. For these connection types,
NetworkManager can configure network aliases, IP addresses, static routes, DNS information, and VPN
connections, as well as many connection-specific parameters. Finally, NetworkManager provides an API
via D-Bus which allows applications to query and control network configuration and state.
For information on user privileges and gaining privileges, see the Red Hat Enterprise Linux 7 System
Administrator's Guide.
T he system ctl status command will report NetworkManager as Active: inactive (dead) if the
NetworkManager service is not running. T o start it for the current session run the following command as
the root user:
~]# systemctl start NetworkManager
Run the system ctl enable command to ensure that NetworkManager starts up every time the
system boots:
~]# systemctl enable NetworkManager
For more information on starting, stopping and managing services, see the Red Hat Enterprise Linux 7
System Administrator's Guide.
T he ip commands can be used to add and remove addresses and routes to interfaces in parallel with
NetworkManager, which will preserve them and recognize them in nmcli, nmtui, control-center, and
the D-Bus API.
Examples of using the command line and configuration files for each task are included after nmtui and
nmcli examples but before explaining the use of one of the graphical user interfaces to
NetworkManager, namely, control-center and nm-connection-editor.
If required, for details on how to verify that NetworkManager is running, see Section 1.4.1, T he
NetworkManager Daemon.
T o start nmtui, issue a command as follows:
~]$ nmtui
T he text user interface appears. T o navigate, use the arrow keys or press T ab to step forwards and
press Shift+T ab to step back through the options. Press Enter to select an option. T he Space bar
toggles the status of a check box.
T he following commands are available:
nmtui edit connection-name
If no connection name is supplied, the selection menu appears. If the connection name is supplied and
correctly identified, the relevant Edit connection screen appears.
nmtui connect connection-name
If no connection name is supplied, the selection menu appears. If the connection name is supplied and
correctly identified, the relevant connection is activated. Any invalid command prints a usage message.
At time of writing, nmtui does not support all types of connections. In particular, you cannot edit VPNs, WiFi connections using WPA Enterprise, or Ethernet connections using 802.1X.
T he above command reads all connection profiles. Alternatively, to reload only one changed file, ifcfgifname, issue a command as follows:
nmcli con load ifcfg-ifname
Followed by:
nmcli con up interface-name
T hese commands require root privileges. For more information on user privileges and gaining privileges,
see the Red Hat Enterprise Linux 7 System Administrator's Guide and the su(1) and sudo(8) man
pages.
NetworkManager does not trigger any of the network scripts, though the network scripts will try to trigger
NetworkManager if it is running when ifup commands are used. See Section 1.8, NetworkManager and
the Network Scripts for an explanation of the network scripts.
T he ifup script is a generic script which does a few things and then calls interface-specific scripts like
ifup-ethX, ifup-wireless, ifup-ppp, and so on. When a user runs ifup eth0 manually, the
following occurs:
1. ifup looks for a file called /etc/sysconfig/network-scripts/ifcfg-eth0;
2. if the ifcfg file exists, ifup looks for the T YPE key in that file to determine which type-specific
script to call;
3. ifup calls ifup-wireless or ifup-eth or ifup-XXX based on T YPE;
4. the type-specific scripts do type-specific setup;
5. and then the type-specific scripts let common functions perform IP-related tasks like DHCP or static
setup.
On bootup, /etc/init.d/network reads through all the ifcfg files and for each one that has
it checks whether NetworkManager is already starting the DEVICE from that ifcfg file. If
NetworkManager is starting that device or has already started it, nothing more is done for that file, and
the next file is checked. If NetworkManager is not yet starting that device, the initscripts
will continue with their traditional behavior and call ifup for that ifcfg file.
10
Note
It is recommended not to store backup ifcfg files in the same location as the live ones. T he script
literally does ifcfg-* with an exclude only for these extensions: .old, .orig, .rpm new,
.rpm orig, and .rpm save. T he best way is not to store backup files anywhere within the /etc/
directory.
11
T he text user interface appears. Any invalid command prints a usage message.
where OBJECT can be one of general, networking, radio, connection, or device. T he most
used options are: -t, --terse for use in scripts, the -p, --pretty option for users, and the -h, -help option. Command completion has been implemented for nmcli, so remember to press T ab when
ever you are unsure of the command options available. See the nm cli(1) man page for a complete list of
the options and commands.
T he nmcli tool has some built-in context sensitive help. For example, issue the following two commands
and notice the difference:
~]$ nmcli help
Usage: nmcli [OPTIONS] OBJECT { COMMAND | help }
OPTIONS
-t[erse]
-p[retty]
-m[ode] tabular|multiline
terse output
pretty output
output mode
13
In the second example above the help is related to the object general.
T he nm cli-exam ples(5) man page has many useful examples. A brief selection is shown here:
T o show the overall status of NetworkManager:
nmcli general status
T o show only currently active connections, add the -a, --active option as follows:
nmcli connection show --active
Commands can be shortened and some options omitted. For example the command:
nmcli connection modify id 'MyCafe' 802-11-wireless.mtu 1350
14
T he id option can been omitted because the connection ID (name) is unambiguous for nmcli in this case.
As you become familiar with the commands, further abbreviations can be made. For example:
nmcli connection add type ethernet
Note
Remember to use tab completion when in doubt.
con
con
dev
dev
up id bond0
up id port0
disconnect iface bond0
disconnect iface eth0
Note
It is recommended to use nm cli dev disconnect iface iface-name rather than nm cli
con down id id-string because disconnection places the interface into a manual mode, in
which no automatic connection will be started until the user tells NetworkManager to start a
connection or until an external event like a carrier change, hibernate, or sleep, occurs.
You will be prompted to enter a valid connection type from the list displayed. After entering a connection
type you will be placed at the nmcli prompt. If you are familiar with the connection types you can add a
valid connection type option to the nm cli con edit command and be taken straight to the nmcli
prompt. T he format is as follows for editing an existing connection profile:
nmcli con edit [id | uuid | path] ID
For adding and editing a new connection profile, the following format applies:
nmcli con edit [type new-connection-type] [con-name new-connection-name]
T ype help at the nmcli prompt to see a list of valid commands. Use the describe command to get a
description of settings and their properties. T he format is as follows:
15
For example:
nmcli> describe team.config
T he connection name is the name of a connection profile and should not be confused with the
interface name that denotes a device (wlan0, eth0, em1, and so on). Users can however name
the connections after interfaces, but they are not the same thing. T here can be multiple
connection profiles available for a device. T his is particularly useful for mobile devices or when
switching a network cable back and forth between different devices. Rather than edit the
configuration, create different profiles and apply them to the interface as needed. T he id option
also refers to the connection profile name.
id An identification string assigned by the user to a connection profile.
T he ID can be used in nm cli connection commands to identify a connection. T he NAME field
in the output always denotes the connection ID (name). It refers to the same connection profile
name that the con-nam e does.
uuid A unique identification string assigned by the system to a connection profile.
T he UUID can be used in nm cli connection commands to identify a connection.
16
CONNECTION
Profile 2
Wired connection 1
Bridge connection 1
Optionally, at the same time specify IPv6 addresses for the device as follows:
~]$ nmcli con add con-name my-eth1 ifname eth1 type ethernet ip4
192.168.100.100/24 \
gw4 192.168.100.1 ip6 abbe::cafe gw6 2001:db8::1
T o view detailed information about the newly configured connection, issue a command as follows:
~]$ nmcli -p con show my-eth1
T o make a profile usable for all compatible Ethernet interfaces, issue a command as follows:
~]$ nmcli connection add type ethernet con-name "my-eth1" ifname "*"
Note that you have to use the ifnam e argument even if you do not want to set a specific interface. Use
the wildcard character * to specify that the profile can be used with any compatible device.
T o lock a profile to a specific MAC address, issue a command as follows:
17
T o create a Wi-Fi connection profile with manual IP configuration, but allowing automatic DNS address
assignment, issue a command as follows:
~]$ nmcli con add con-name MyCafe ifname wlan0 type wifi ssid MyCafe \
p4 192.168.100.101/24 gw4 192.168.100.1
See the Red Hat Enterprise Linux 7 Security Guide for information on password security.
T o change Wi-Fi state, issue a command in the following format:
~]$ nmcli radio wifi [on | off ]
Optionally specify the hardware or MAC address using the HWADDR directive. Note that this may influence
the device naming procedure as explained in Chapter 9, Consistent Network Device Naming. You do not
need to specify the broadcast address as this is calculated automatically by ipcalc.
Dynamic Network Settings
T o configure an interface with dynamic network settings using ifcfg files, for an interface with name em1,
create a file with name ifcfg-em 1 in the /etc/sysconfig/network-scripts/ directory as follows:
DEVICE=em1
BOOTPROTO=dhcp
>
Optionally specify the hardware or MAC address using the HWADDR directive. Note that this may influence
the device naming procedure as explained in Chapter 9, Consistent Network Device Naming. You do not
need to specify the broadcast address as this is calculated automatically by ipcalc.
19
T o add a static route to a host address, in other words to a single IP address, issue a command as root:
ip route add 192.0.2.1 via 10.0.0.1 [dev ifname]
Where 192.0.2.1 is the IP address of the host in dotted decimal notation, 10.0.0.1 is the next hop address
and ifname is the exit interface leading to the next hop.
T o add a static route to a network, in other words to an IP address representing a range of IP
addresses, issue the following command as root:
ip route add 192.0.2.0/24 via 10.0.0.1 [dev ifname]
where 192.0.2.0 is the IP address of the destination network in dotted decimal notation and /24 is the
network prefix. T he network prefix is the number of enabled bits in the subnet mask. T his format of
network address slash network prefix length is sometimes referred to as classless inter-domain routing
(CIDR) notation.
Static route configuration can be stored per-interface in a /etc/sysconfig/networkscripts/route-interface file. For example, static routes for the eth0 interface would be stored in the
/etc/sysconfig/network-scripts/route-eth0 file. T he route-interface file has two formats:
ip command arguments and network/netmask directives. T hese are described below.
See the ip-route(8) man page for more information on the ip route command.
Configuring T he Default Gateway
T he default gateway is determined by the network scripts which parse the /etc/sysconfig/network
file first and then the network interface ifcfg files for interfaces that are up. T he ifcfg files are
parsed in numerically ascending order, and the last GAT EWAY directive to be read is used to compose a
default route in the routing table.
T he default route can thus be indicated by means of the GAT EWAY directive and can be specified either
globally or in interface-specific configuration files. Specifying the gateway globally has certain advantages
in static networking environments, especially if more than one network interface is present. It can make
fault finding simpler if applied consistently.
In dynamic network environments, where mobile hosts are managed by NetworkManager, gateway
information is likely to be interface specific and is best left to be assigned by DHCP. In special cases where
it is necessary to influence NetworkManager's selection of the exit interface to be used to reach a
gateway, make use of the DEFROUT E=no command in the ifcfg files for those interfaces which do not
lead to the default gateway.
Global default gateway configuration is stored in the /etc/sysconfig/network file. T his file specifies
gateway and host information for all network interfaces. .
where 192.168.1.1 is the IP address of the default gateway. T he interface is the interface that is
connected to, or can reach, the default gateway. T he dev option can be omitted, it is optional. Note that
this setting takes precedence over a setting in the /etc/sysconfig/network file.
If a route to a remote network is required, a static route can be specified as follows. Each line is parsed as
an individual route:
10.10.10.0/24 via 192.168.1.1 [dev interface]
where 10.10.10.0/24 is the network address and prefix length of the remote or destination network. T he
address 192.168.1.1 is the IP address leading to the remote network. It is preferably the next hop address
but the address of the exit interface will work. T he next hop means the remote end of a link, for example
a gateway or router. T he dev option can be used to specify the exit interface interface but it is not
required. Add as many static routes as required.
T he following is an example of a route-interface file using the ip command arguments format. T he
default gateway is 192.168.0.1, interface eth0 and a leased line or WAN connection is available at
192.168.0.10. T he two static routes are for reaching the 10.10.10.0/24 network and the
172.16.1.10/32 host:
default via 192.168.0.1 dev eth0
10.10.10.0/24 via 192.168.0.10 dev eth0
172.16.1.10/32 via 192.168.0.10 dev eth0
In the above example, packets going to the local 192.168.0.0/24 network will be directed out the
interface attached to that network. Packets going to the 10.10.10.0/24 network and 172.16.1.10/32
host will be directed to 192.168.0.10. Packets to unknown, remote, networks will use the default
gateway therefore static routes should only be configured for remote networks or hosts if the default route
is not suitable. Remote in this context means any networks or hosts that are not directly attached to the
system.
Specifying an exit interface is optional. It can be useful if you want to force traffic out of a specific interface.
For example, in the case of a VPN, you can force traffic to a remote network to pass through a tun0
interface even when the interface is in a different subnet to the destination network.
21
Important
If the default gateway is already assigned by DHCP and if the same gateway with the same metric is
specified in a configuration file, an error during start-up, or when bringing up an interface, will occur.
T he follow error message may be shown: "RT NET LINK answers: File exists". T his error may be
ignored.
Subsequent static routes must be numbered sequentially, and must not skip any values. For example,
ADDRESS0, ADDRESS1, ADDRESS2, and so on.
22
Figure 2.2. T he GNOME network menu, showing all available and connected-to networks
23
24
25
T his can also be set using graphical user interface tools. In nm-connection-editor there is the
corresponding All users m ay connect to this network checkbox on the General tab and in
the GNOME control-center Network settings Identity window there is the Make available to other
users checkbox.
NetworkManager's default policy is to allow all users to create and modify system-wide connections.
Profiles that should be available at boot time cannot be private because they will not be visible until the
user logs in. For example, if user joe creates a connection profile joe-em 2 with the Connect
Autom atically checkbox selected but the Make available to other users unselected, then the
connection will not be available at boot time.
T o restrict a connections and networking, there are two options which can be used alone or in
combination:
Unselect the Make available to other users box, which changes the connection to be
modifiable and usable only by the user doing the changing.
Use the polkit framework to restrict permissions of general network operations on a per-user basis.
T he combination of these two options provides fine-grained security and control over networking. See man
polkit(8) for more information on polkit.
Note that VPN connections are always created as private-per-user, since they are assumed to be more
private than a Wi-Fi or Ethernet connection.
26
27
28
29
See Red Hat Enterprise Linux 7 System Administrator's Guide for more information on how to install new
packages in Red Hat Enterprise Linux 7.
Establishing a Virtual Private Network (VPN) enables communication between your Local Area Network
(LAN), and another, remote LAN. T his is done by setting up a tunnel across an intermediate network such
as the Internet. T he VPN tunnel that is set up typically uses authentication and encryption. After
successfully establishing a VPN connection using a secure tunnel, a VPN router or gateway performs the
following actions upon the packets you transmit:
1. it adds an Authentication Header for routing and authentication purposes;
30
31
32
33
34
35
36
37
38
39
40
41
42
43
45
Note
A host name can be a free-form string up to 64 characters in length. However, Red Hat
recommends that both static and transient names match the fully-qualified domain name (FQDN)
used for the machine in DNS, such as host.exam ple.com . It is also recommended that the static
and transient names consists only of 7 bit ASCII lower-case characters, no spaces or dots, and
limits itself to the format allowed for DNS domain name labels, even though this is not a strict
requirement. Older specifications do not permit the underscore, and so their use is not
recommended.
T he hostnamectl tool will enforce the following: Static and transient host names to consist of a-z,
A-Z, 0-9, -, _ and . only, to not begin or end in a dot, and to not have two dots immediately
following each other. T he size limit of 64 characters is enforced.
T he text user interface appears. Any invalid command prints a usage message.
46
T his will alter the pretty, static, and transient host names alike. T he static and transient host names will be
simplified forms of the pretty host name. Spaces will be replaced with - and special characters will be
removed.
Where "" is a quoted empty string and where option is one or more of: --pretty, --static, and -transient.
Where hostname is the remote host you wish to configure. T he username is optional. T he hostnamectl
tool will use SSH to connect to the remote system.
T o set the static host name to my-server, issue the following command as root:
~]# nmcli general hostname my-server
T o force hostnamectl to notice the change in the static host name, restart hostnam ed as root:
~]# systemctl restart systemd-hostnamed
48
49
T he text user interface appears. Any invalid command prints a usage message.
T o navigate, use the arrow keys or press T ab to step forwards and press Shift+T ab to step back
through the options. Press Enter to select an option. T he Space bar toggles the status of a check box.
From the starting menu, select Edit a connection. Select Add, the New Connection screen opens.
50
Figure 4 .1. T he NetworkManager T ext User Interface Add a Bond Connection menu
Select Bond, the Edit connection screen opens. T o add slave interfaces to the bond, select Add, the
New Connection screen opens. Follow the on-screen prompts to complete the configuration.
51
Figure 4 .2. T he NetworkManager T ext User Interface Configuring a Bond Connection menu
See Section 4.6.1.1, Configuring the Bond T ab for definitions of the bond terms.
See Section 1.7, Network Configuration Using a T ext User Interface (nmtui) for information on installing
nmtui.
T o add additional slaves, repeat the previous command with a new interface, for example:
~]$ nmcli con add type bond-slave ifname ens3 master mybond0
Connection 'bond-slave-ens3-1' (50c59350-1531-45f4-ba04-33431c16e386) successfully
added.
Note that as no con-nam e was given for the slaves, the name was derived from the interface name by
prepending the type. At time of writing, nmcli only supports Ethernet slaves.
52
See Section 2.3, Using the NetworkManager Command Line T ool, nmcli for an introduction to nmcli
T his activation will not persist across system restarts. See the Red Hat Enterprise Linux 7 System
Administrator's Guide for an explanation of persistent module loading.
T o display information about the module, issue the following command:
~]$ modinfo bonding
53
Important
Parameters for the bonding kernel module must be specified as a space-separated list in the
BONDING_OPT S="bonding parameters" directive in the ifcfg-bondN interface file. Do not
specify options for the bonding device in /etc/m odprobe.d/bonding.conf, or in the
deprecated /etc/m odprobe.conf file. For further instructions and advice on configuring the
bonding module and to view the list of bonding parameters, see Section 4.5, Using Channel
Bonding.
In this example, replace N with the numerical value for the interface.
54
If you have correctly created the ifcfg-bond0 bonding interface file, you will be able to see bond0 listed
in the output of running ifconfig (without any options):
~]# ifconfig
bond0
Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0
Link encap:Ethernet HWaddr 52:54:00:26:9E:F1
inet addr:192.168.122.251 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe26:9ef1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:207 errors:0 dropped:0 overruns:0 frame:0
TX packets:205 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:70374 (68.7 KiB) TX bytes:25298 (24.7 KiB)
[output truncated]
T o view all existing bonds, even if they are not up, run:
~]# cat /sys/class/net/bonding_masters
bond0
You can configure each bond individually by manipulating the files located in the
/sys/class/net/bond<N>/bonding/ directory. First, the bond you are configuring must be taken
down:
~]# /usr/sbin/ifdown bond0
As an example, to enable MII monitoring on bond0 with a 1 second interval, run as root:
~]# echo 1000 > /sys/class/net/bond0/bonding/miimon
55
After configuring options for the bond in question, you can bring it up and test it by running
/usr/sbin/ifup bond<N>. If you decide to change the options, take the interface down, modify its
parameters using sysfs, bring it back up, and re-test.
Once you have determined the best set of parameters for your bond, add those parameters as a spaceseparated list to the BONDING_OPTS= directive of the /etc/sysconfig/network-scripts/ifcfgbond<N> file for the bonding interface you are configuring. Whenever that bond is brought up (for
example, by the system during the boot sequence if the directive is set), the bonding options
specified in the BONDING_OPTS will take effect for that bond.
T he following list provides the names of many of the more common channel bonding parameters, along
with a description of what they do. For more information, see the brief descriptions for each parm in
m odinfo bonding output, or for more detailed information, see
https://www.kernel.org/doc/Documentation/networking/bonding.txt.
Bonding Interface Parameters
arp_interval=<time_in_milliseconds>
Specifies, in milliseconds, how often ARP monitoring occurs.
Important
It is essential that both arp_interval and arp_ip_target parameters are specified,
or, alternatively, the m iim on parameter is specified. Failure to do so can cause
degradation of network performance in the event that a link fails.
If using this setting while in m ode=0 or m ode=1 (the two load-balancing modes), the network
switch must be configured to distribute packets evenly across the NICs. For more information on
how to accomplish this, see https://www.kernel.org/doc/Documentation/networking/bonding.txt.
T he value is set to 0 by default, which disables it.
arp_ip_target=<ip_address>[,<ip_address_2>, <ip_address_16>]
Specifies the target IP address of ARP requests when the arp_interval parameter is enabled.
Up to 16 IP addresses can be specified in a comma separated list.
arp_validate=<value>
Validate source/distribution of ARP probes; default is none. Other valid values are active,
backup, and all.
downdelay=<time_in_milliseconds>
Specifies (in milliseconds) how long to wait after link failure before disabling the link. T he value
must be a multiple of the value specified in the m iim on parameter. T he value is set to 0 by
default, which disables it.
lacp_rate=<value>
Specifies the rate at which link partners should transmit LACPDU packets in 802.3ad mode.
Possible values are:
56
In this command, replace <interface_name> with the name of the device interface, such as eth0,
not the bond interface. If MII is supported, the command returns:
Link detected: yes
If using a bonded interface for high availability, the module for each NIC must support MII. Setting
the value to 0 (the default), turns this feature off. When configuring this setting, a good starting
point for this parameter is 100.
Important
It is essential that both arp_interval and arp_ip_target parameters are specified,
or, alternatively, the m iim on parameter is specified. Failure to do so can cause
degradation of network performance in the event that a link fails.
m ode=<value>
Allows you to specify the bonding policy. T he <value> can be one of:
balance-rr or 0 Sets a round-robin policy for fault tolerance and load balancing.
T ransmissions are received and sent out sequentially on each bonded slave interface
beginning with the first one available.
active-backup or 1 Sets an active-backup policy for fault tolerance. T ransmissions are
received and sent out via the first available bonded slave interface. Another bonded slave
interface is only used if the active bonded slave interface fails.
balance-xor or 2 T ransmissions are based on the selected hash policy. T he default is
to derive a hash by XOR of the source and destination MAC addresses multiplied by the
modulo of the number of slave interfaces. In this mode traffic destined for specific peers will
always be sent over the same interface. As the destination is determined by the MAC
addresses this method works best for traffic to peers on the same link or local network. If
traffic has to pass through a single router then this mode of traffic balancing will be
suboptimal.
broadcast or 3 Sets a broadcast policy for fault tolerance. All transmissions are sent on
all slave interfaces.
802.3ad or 4 Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation
groups that share the same speed and duplex settings. T ransmits and receives on all slaves
in the active aggregator. Requires a switch that is 802.3ad compliant.
57
58
Note
If the bonding interface insists that the link is up when it should not be, it is possible that
your network device driver does not support netif_carrier_on/off.
xm it_hash_policy=<value>
Selects the transmit hash policy used for slave selection in balance-xor and 802.3ad modes.
Possible values are:
0 or layer2 Default setting. T his parameter uses the XOR of hardware MAC addresses to
generate the hash. T he formula used is:
(<source_MAC_address> XOR <destination_MAC>) MODULO <slave_count>
T his algorithm will place all traffic to a particular network peer on the same slave, and is
802.3ad compliant.
1 or layer3+4 Uses upper layer protocol information (when available) to generate the
hash. T his allows for traffic to a particular network peer to span multiple slaves, although a
single connection will not span multiple slaves.
T he formula for unfragmented T CP and UDP packets used is:
((<source_port> XOR <dest_port>) XOR
((<source_IP> XOR <dest_IP>) AND 0xffff)
MODULO <slave_count>
For fragmented T CP or UDP packets and all other IP protocol traffic, the source and
destination port information is omitted. For non-IP traffic, the formula is the same as the
layer2 transmit hash policy.
T his policy intends to mimic the behavior of certain switches; particularly, Cisco switches with
PFC2 as well as some Foundry and IBM products.
59
T his algorithm will place all traffic to a particular network peer on the same slave. For non-IP
traffic, the formula is the same as for the layer2 transmit hash policy.
T his policy is intended to provide a more balanced distribution of traffic than layer2 alone,
especially in environments where a layer3 gateway device is required to reach most
destinations.
T his algorithm is 802.3ad compliant.
60
61
62
63
64
65
Bonding
T eam
broadcast T x policy
Yes
Yes
round-robin T x policy
Yes
Yes
active-backup T x policy
Yes
Yes
Yes
Hash-based T x policy
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Yes
No
Yes
Limited
Yes
No (rwlock)
Yes (RCU)
VLAN support
Yes
Yes
Limited
Full
Logic in user-space
No
Yes
Extensibility
Hard
Easy
Modular design
No
Yes
Performance overhead
Low
Very Low
D-Bus interface
No
Yes
Yes
Yes
No
(in planning)
NetworkManager support
Yes
Yes
66
67
New files will be created in a directory whose name starts with /tm p/bond2team .XXXXXX, where
XXXXXX is a random string. After creating the new configuration files, move the old bonding files to a
backup folder and then move the new files to the /etc/sysconfig/network-scripts/ directory. See
the bond2team (1) man page for further details.
From the available interfaces, determine which are suitable for adding to your network team and then
proceed to Section 5.8, Selecting Network T eam Configuration Methods
Note
T he T eam developers prefer the term port rather than slave, however NetworkManager uses
the term team-slave to refer to interfaces that make up a team.
5.9. Configure a Network Team Using the Text User Interface, nmtui
T he text user interface tool nmtui can be used to configure teaming in a terminal window. Issue the
following command to start the tool:
~]$ nmtui
68
Figure 5.1. T he NetworkManager T ext User Interface Add a T eam Connection menu
Select T eam , the Edit connection screen opens. T o add port interfaces to the bond, select Add, the
New Connection screen opens. Follow the on-screen prompts to complete the configuration.
69
Figure 5.2. T he NetworkManager T ext User Interface Configuring a T eam Connection menu
See Section 5.12, Configure teamd Runners for examples of JSON strings. Note that only the relevant
sections from the example strings should be used for a team or port configuration using nmtui. Do not
specify the Device as part of the JSON string. For example, only the JSON string after device but before
port should be used in the T eam JSON configuration field. All JSON strings relevant to a port must only
be added in the port configuration field.
See Section 1.7, Network Configuration Using a T ext User Interface (nmtui) for information on installing
nmtui.
As no JSON configuration file was specified the default configuration is used. Notice that the name was
derived from the interface name by prepending the type. Alternatively, specify a name with con-nam e as
follows:
70
TYPE
team
team
TIMESTAMP-REAL
never
never
T o load a team configuration file for a team that already exists, issue a command as follows:
~]$ nmcli connection modify team-ServerA team.config JSON-config
You can specify the team configuration either as JSON string or provide a file name containing the
configuration. T he file name can include the path. In both cases, what is stored in the team.config
property is the JSON string. In the case of a JSON string, use single quotes around the string and paste
the entire string to the command line.
T o review the team.config property, enter a command as follows:
~]$ nmcli conn show team-ServerA | grep team.config
T o add an interface to the team, with name team-slave-ens3, issue a command as follows:
~]$ nmcli connection add type team-slave ifname ens3 master Team0
Connection 'team-slave-ens3' (a33d5d32-87d7-4dc4-8a27-5a44aabfa440) successfully
added.
Notice that the name was derived from the interface name by prepending the type. Alternatively, specify a
name with con-nam e as follows:
~]$ nmcli
Connection
~]$ nmcli
Connection
con add type team-slave con-name Team0-port1 ifname ens3 master Team0
'Team0-port1' (adbf21f2-51b6-492f-8fc8-48b831383ac9) successfully added.
con add type team-slave con-name Team0-port2 ifname ens7 master Team0
'Team0-port2' (e5317075-c0c1-472f-b25d-0433b0297ea3) successfully added.
You can verify the team interface was brought up by the activation of the ports, as follows:
~]$ ip link
3: Team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode
DEFAULT
link/ether 52:54:00:76:6f:f0 brd ff:ff:ff:ff:ff:f
71
See Section 2.3, Using the NetworkManager Command Line T ool, nmcli for an introduction to nmcli
loadbalance_2.conf
loadbalance_3.conf
random.conf
roundrobin_2.conf
roundrobin.conf
T o view one of the included files, such as activebackup_ethtool_1.conf, enter the following
command:
~]$ cat /usr/share/doc/teamd-*/example_configs/activebackup_ethtool_1.conf
{
"device": "team0",
"runner": {"name": "activebackup"},
"link_watch": {"name": "ethtool"},
"ports": {
"eth1": {
"prio": -10,
"sticky": true
},
"eth2": {
"prio": 100
}
}
}
Create a working configurations directory to store team d configuration files. For example, as normal user,
enter a command with the following format:
~]$ mkdir ~/teamd_working_configs
Copy the file you have chosen to your working directory and edit it as necessary. As an example, you
could use a command with the following format:
~]$ cp /usr/share/doc/teamd-*/example_configs/activebackup_ethtool_1.conf \
~/teamd_working_configs/activebackup_ethtool_1.conf
T o edit the file to suit your environment, for example to change the interfaces to be used as ports for the
network team, open the file for editing as follows:
~]$ vi ~/teamd_working_configs/activebackup_ethtool_1.conf
Make any necessary changes and save the file. See the vi(1) man page for help on using the vi editor or
use your preferred editor.
72
In this example we see that both the interfaces we plan to use are UP.
T o take down an interface, issue a command as root in the following format:
~]# ip link set down em1
T he -g option is for debug messages, -f option is to specify the configuration file to load, and the -d
option is to make the process run as a daemon after startup. See the team d(8) man page for other
options.
T o check the status of the team, issue the following command as root:
~]# teamdctl team0 state
setup:
runner: activebackup
ports:
em1
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
em2
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
runner:
active port: em1
73
T o activate the team interface, or to bring it up, issue a command as root in the following format:
~]# ip link set dev team0 up
T o temporarily deactivate the team interface, or to take it down, issue a command as root in the
following format:
~]# ip link set dev team0 down
T o terminate, or kill, an instance of the team daemon, as root user, issue a command in the following
format:
~]# teamd -t team0 -k
T he -k option is to specify that the instance of the daemon associated with the device team0 is to be
killed. See the team d(8) man page for other options.
For help on command line options for team d, issue the following command:
~]$ teamd -h
T his creates the interface to the team, in other words, this is the master.
74
Add additional port interfaces similar to the above as required, changing the DEVICE and HWADDR field to
match the ports (the network devices) being added. If port priority is not specified by prio it defaults to 0;
it accepts negative and positive values in the range -32,767 to +32,767.
Specifying the hardware or MAC address using the HWADDR directive will influence the device naming
procedure. T his is explained in Chapter 9, Consistent Network Device Naming.
T o bring up the network team, issue the following command as root:
~]# ifup team0
Add additional ports as required. T eam driver will bring ports up automatically.
T o configure a team to use active backup mode, issue the following command as root:
~]# teamnl team0 setoption mode activebackup
T o check the change in team port options, issue the following command as root:
~]# teamnl team0 getoption activeport
5
For a complete state dump in JSON format (useful for machine processing) of team0, use the following
command:
~]# teamdctl team0 state dump
For a configuration dump in JSON format of team0, use the following command:
~]# teamdctl team0 config dump
76
Where JSON-config-string is the configuration as a string of text in JSON format. T his will update the
configuration of the port using the JSON format string supplied. An example of a valid JSON string for
configuring a port would be the following:
{
"prio": -10,
"sticky": true
}
Use single quotes around the JSON configuration string and omit the line breaks.
Note that the old configuration will be overwritten and that any options omitted will be reset to the default
values. See the team dctl(8) man page for more team daemon control tool command examples.
T his will dump the JSON format configuration of the port to standard output.
77
Please see the team d.conf(5) man page for more information.
Please see the team d.conf(5) man page for more information.
78
T his example configuration uses the active-backup runner with ethtool as the link watcher. Port em2 has
higher priority. T he sticky flag ensures that if em1 becomes active, it stays active as long as the link
remains up.
{
"device": "team0",
"runner": {
"name": "activebackup"
},
"link_watch": {
"name": "ethtool"
},
"ports": {
"em1": {
"prio": -10,
"sticky": true,
"queue_id": 4
},
"em2": {
"prio": 100
}
}
}
T his example configuration adds a queue ID of 4 . It uses active-backup runner with ethtool as the link
watcher. Port em2 has higher priority. But the sticky flag ensures that if em1 becomes active, it will stay
active as long as the link remains up.
T o configure the activebackup runner using ethtool as the link watcher and applying a delay, using an
editor as root, add the following to the team JSON format configuration file:
{
"device": "team0",
"runner": {
"name": "activebackup"
},
"link_watch": {
"name": "ethtool",
"delay_up": 2500,
"delay_down": 1000
},
"ports": {
"em1": {
"prio": -10,
"sticky": true
},
"em2": {
"prio": 100
}
}
}
79
Configuration for active transmit (T x) load balancing using basic load balancer.
Please see the team d.conf(5) man page for more information.
80
Configuration for connection to a link aggregation control protocol (LACP) capable counterpart. T he LACP
runner should use ethtool to monitor the status of a link. It does not make sense to use any other link
monitoring method besides the ethtool because, for example in the case of arp_ping, the link would
never come up. T he reason is that the link has to be established first and only after that can packets, ARP
included, go through. Using ethtool prevents this because it monitors each link layer individually.
Active load balancing is possible with this runner in the same way as it is done for the loadbalance runner.
T o enable active transmit (T x) load balancing, add the following section:
"tx_balancer": {
"name": "basic"
}
Please see the team d.conf(5) man page for more information.
T o add or edit an existing delay, in milliseconds, between the link going down and the runner being notified
about it, add or edit a section as follows:
"link_watch": {
"name": "ethtool",
"delay_down": 1000
}
81
T his configuration uses arp_ping as the link watcher. T he m issed_m ax option is a limit value of the
maximum allowed number of missed replies (ARP replies for example). It should be chosen in conjunction
with the interval option in order to determine the total time before a link is reported as down.
T o load a new configuration for a team port em2, from a file containing a JSON configuration, issue the
following command as root:
~]# port config update em2 JSON-config-file
Note that the old configuration will be overwritten and that any options omitted will be reset to the default
values. See the team dctl(8) man page for more team daemon control tool command examples.
5.12.7.3. Configure IPv6 NA/NS for Link-state Monitoring
{
"device": "team0",
"runner": {"name": "activebackup"},
"link_watch": {
"name": "nsna_ping",
"interval": 200,
"missed_max": 15,
"target_host": "fe80::210:18ff:feaa:bbcc"
},
"ports": {
"em1": {
"prio": -10,
"sticky": true
},
"em2": {
"prio": 100
}
}
}
T o configure the interval between sending NS/NA packets, add or edit a section as follows:
"link_watch": {
"name": "nsna_ping",
"interval": 200
}
Value is positive number in milliseconds. It should be chosen in conjunction with the m issed_m ax option
in order to determine the total time before a link is reported as down.
82
Maximum number of missed NS/NA reply packets. If this number is exceeded, the link is reported as down.
T he m issed_m ax option is a limit value of the maximum allowed number of missed replies (ARP replies
for example). It should be chosen in conjunction with the interval option in order to determine the total
time before a link is reported as down.
T o configure the host name that is resolved to the IPv6 address target address for the NS/NA packets,
add or edit a section as follows:
"link_watch": {
"name": "nsna_ping",
"target_host": "MyStorage"
}
T he target_host option contains the host name to be converted to an IPv6 address which will be used
as the target address for the NS/NA packets. An IPv6 address can be used in place of a host name.
Please see the team d.conf(5) man page for more information.
T hese queue ID's can be used in conjunction with the tc utility to configure a multiqueue queue discipline
and filters to bias certain traffic to be transmitted on certain port devices. For example, if using the above
configuration and wanting to force all traffic bound to 192.168.1.100 to use eth1 in the team as its
output device, issue commands as root in the following format:
~]# tc qdisc add dev team0 handle 1 root multiq
~]# tc filter add dev team0 protocol ip parent 1: prio 1 u32 match ip dst \
192.168.1.100 action skbedit queue_mapping 3
T his mechanism of overriding runner selection logic in order to bind traffic to a specific port can be used
with all runners.
83
84
85
86
T he text user interface appears. Any invalid command prints a usage message.
T o navigate, use the arrow keys or press T ab to step forwards and press Shift+T ab to step back
through the options. Press Enter to select an option. T he Space bar toggles the status of a check box.
From the starting menu, select Edit a connection. Select Add, the New Connection screen opens.
Figure 6.1. T he NetworkManager T ext User Interface Add a Bridge Connection menu
Select Bridge, the Edit connection screen opens. T o add slave interfaces to the bond, select Add,
the New Connection screen opens. Follow the on-screen prompts to complete the configuration.
87
If no interface name is specified, the name will default to bridge, bridge-1, bridge-2, and so on.
T o view the connections, issue the following command:
~]$ nmcli con show
NAME
UUID
TYPE
bridge-br0 79cf6a3e-0310-4a78-b759-bda1cc3eef8d bridge
eth0
4d5c449a-a6c5-451c-8206-3c9a4ec88bca 802-3-ethernet
DEVICE
-eth0
Spanning tree protocol (ST P) is enabled by default. T he values used are from the IEEE 802.1D-1998
standard. T o disable ST P for this bridge, issue a command as follows as root:
~]# nmcli con modify bridge-br0 bridge.stp no
88
T he default bridge priority for 802.1D ST P is 32768. T he lower number is preferred in root bridge
selection. For example, a bridge with priority of 28672 would be selected as the root bridge in preference
to a bridge with priority value of 32768 (the default). T o create a bridge with a non-default value, issue a
command as follows:
~]$ nmcli con add type bridge ifname br5 stp yes priority 28672
Connection 'bridge-br5' (86b83ad3-b466-4795-aeb6-4a66eb1856c7) successfully added.
Further options for 802.1D ST P are listed in the bridge section of the nm cli(1) man page.
T o add, or enslave an interface, for example eth1, to the bridge bridge-br0, issue a command as follows:
~]$ nmcli con add type bridge-slave ifname eth1 master bridge-br0
Connection 'bridge-slave-eth1' (70ffae80-7428-4d9c-8cbd-2e35de72476e) successfully
added.
See Section 2.3, Using the NetworkManager Command Line T ool, nmcli for an introduction to nmcli
89
T o complete the bridge another interface is created, or an existing interface is modified, and pointed to the
bridge interface.
90
Optionally specify a name using the NAME directive. If no name is specified, the NetworkManager plugin, ifcfg-rh, will create a name for the connection profile in the form T ype Interface. In this example,
this means the bridge will be named Bridge br0. Alternately, if NAME=bridge-br0 is added to the
ifcfg-br0 file the connection profile will be named bridge-br0.
Note
For the DEVICE directive, almost any interface name could be used as it does not determine the
device type. T YPE=Ethernet is not strictly required. If the T YPE directive is not set, the device is
treated as an Ethernet device (unless its name explicitly matches a different interface configuration
file).
T he directives are case sensitive.
Specifying the hardware or MAC address using the HWADDR directive will influence the device naming
procedure as explained in Chapter 9, Consistent Network Device Naming.
Warning
If you are configuring bridging on a remote host, and you are connected to that host over the
physical NIC you are configuring, please consider the implications of losing connectivity before
proceeding. You will lose connectivity when restarting the service and may not be able to regain
connectivity if any errors have been made. Console, or out-of-band access is advised.
Restart the networking service in order for the changes to take effect. As root issue the following
command:
~]# systemctl restart network
An example of a network bridge formed from two or more bonded Ethernet interfaces will now be given as
this is another common application in a virtualization environment. If you are not very familiar with the
configuration files for bonded interfaces then please refer to Section 4.4.2, Create a Channel Bonding
Interface
Create or edit two or more Ethernet interface configuration files, which are to be bonded, as follows:
DEVICE=ethX
TYPE=Ethernet
91
Note
Using ethX as the interface name is common practice but almost any name could be used.
Create or edit one interface configuration file, /etc/sysconfig/network-scripts/ifcfg-bond0, as
follows:
DEVICE=bond0
>BONDING_OPTS='mode=1 miimon=100'
BRIDGE=brbond0
.
Create or edit one interface configuration file, /etc/sysconfig/network-scripts/ifcfg-brbond0,
as follows:
DEVICE=brbond0
>TYPE=Bridge
IPADDR=192.168.1.1
NETMASK=255.255.255.0
We now have two or more interface configuration files with the MAST ER=bond0 directive. T hese point to
the configuration file named /etc/sysconfig/network-scripts/ifcfg-bond0, which contains the
DEVICE=bond0 directive. T his ifcfg-bond0 in turn points to the /etc/sysconfig/networkscripts/ifcfg-brbond0 configuration file, which contains the IP address, and acts as an interface to
the virtual networks inside the host.
Restart the networking service, in order for the changes to take effect. As root issue the following
command:
~]# systemctl restart network
92
93
94
96
T he text user interface appears. Any invalid command prints a usage message.
T o navigate, use the arrow keys or press T ab to step forwards and press Shift+T ab to step back
through the options. Press Enter to select an option. T he Space bar toggles the status of a check box.
From the starting menu, select Edit a connection. Select Add, the New Connection screen opens.
Figure 7.1. T he NetworkManager T ext User Interface Add a VLAN Connection menu
Select VLAN, the Edit connection screen opens. Follow the on-screen prompts to complete the
configuration.
97
Figure 7.2. T he NetworkManager T ext User Interface Configuring a VLAN Connection menu
See Section 7.4.1.1, Configuring the VLAN T ab for definitions of the VLAN terms.
See Section 1.7, Network Configuration Using a T ext User Interface (nmtui) for information on installing
nmtui.
7.2. Configure 802.1Q VLAN Tagging Using the Command Line Tool,
nmcli
T o create an 802.1Q VLAN interface on Ethernet interface eth0, with VLAN interface VLAN10 and ID 10,
issue a command as follows:
~]$ nmcli con add type vlan ifname VLAN10 dev eth0 id 10
Connection 'vlan-VLAN10' (37750b4a-8ef5-40e6-be9b-4fb21a4b6d17) successfully added.
Note that as no con-nam e was given for the VLAN interface, the name was derived from the interface
name by prepending the type. Alternatively, specify a name with con-nam e as follows:
~]$ nmcli con add type vlan con-name VLAN12 dev eth0 id 12
Connection 'VLAN12' (b796c16a-9f5f-441c-835c-f594d40e6533) successfully added.
Further options for the VLAN command are listed in the VLAN section of the nm cli(1) man page. In the
man pages the device on which the VLAN is created is referred to as the parent device. In the example
above the device was specified by its interface name, eth0, it can also be specified by the connection UUID
or MAC address.
T o create an 802.1Q VLAN connection profile with ingress priority mapping on Ethernet interface eth1, with
name VLAN1 and ID 13, issue a command as follows:
98
T o view all the parameters associated with the VLAN created above, issue a command as follows:
~]$ nmcli connection show vlan-VLAN10
T he MT U setting determines the maximum size of the network layer packet. T he maximum size of the
payload the link-layer frame can carry in turn limits the network layer MT U. For standard Ethernet frames
this means an MT U of 1500 bytes. It should not be necessary to change the MT U when setting up a VLAN
as the link-layer header is increased in size by 4 bytes to accommodate the 802.1Q tag.
At time of writing, connection.interface-nam e and vlan.interface-nam e have to be the same
(if they are set). T hey must therefore be changed simultaneously using nmcli's interactive mode. T o
change a VLAN connections name, issue commands as follows:
~]$ nmcli con edit vlan-VLAN10
nmcli> set vlan.interface-name superVLAN
nmcli> set connection.interface-name superVLAN
nmcli> save
nmcli> quit
T he nmcli utility can be used to set and clear ioctl flags which change the way the 802.1Q code
functions. T he following VLAN flags are supported by NetworkManager:
0x01 - reordering of output packet headers
0x02 - use GVRP protocol
0x04 - loose binding of the interface and its master
T he state of the VLAN is synchronized to the state of the parent or master interface (the interface or
device on which the VLAN is created). If the parent interface is set to the down administrative state then
all associated VLANs are set down and all routes are flushed from the routing table. Flag 0x04 enables a
loose binding mode, in which only the operational state is passed from the parent to the associated
VLANs, but the VLAN device state is not changed.
T o set a VLAN flag, issue a command as follows:
~]$ nmcli connection modify vlan-VLAN10 vlan.flags 1
See Section 2.3, Using the NetworkManager Command Line T ool, nmcli for an introduction to nmcli
99
If there is a need to configure a second VLAN, with for example, VLAN ID 193, on the same interface,
eth0, add a new file with the name eth0.193 with the VLAN configuration details.
3. Restart the networking service in order for the changes to take effect. As root issue the following
command:
~]# systemctl restart network
Note that the ip utility interprets the VLAN ID as a hexadecimal value if it is preceded by 0x and as an octal
value if it has a leading 0. T his means that in order to assign a VLAN ID with a decimal value of 22, you
must not add any leading zeros.
100
VLAN interfaces created using ip commands at the command prompt will be lost if the system is shutdown
or restarted. T o configure VLAN interfaces to be persistent after a system restart, use ifcfg files. See
Section 7.3.1, Setting Up 802.1Q VLAN T agging Using ifcfg Files
101
102
103
SCT P
T CP
UDP
12 bytes
2060 bytes
8 bytes
T ransport-layer packet
Datagram
Segment
Datagram
Connection oriented
Yes
Yes
No
Both
Reliable
Unreliable
Partial Reliability
Optional
No
No
Both
Ordered
Unordered
Yes
No
Yes
Congestion control
Yes
Yes
No
ECN support
Yes
Yes
No
Path MT U discovery
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
Multihoming support
Yes
No
No
Multi-streaming support
Yes
No
No
Yes
No
N/A
Yes
No
No
104
105
106
Bonding
T eaming
SCT P
Monitoring layer
Link layer
Link layer
Network layer
Failover time
multiple seconds
107
Bonding
T eaming
SCT P
Multihome support
No
No
Yes
User-space runtime
control
Limited
Full
Full
Extensibility
Hard
Easy
Yes
For development work, in programming a new application for SCT P, the development packages are also
required. Note that these package are available from the Optional channel. Before installing packages from
the Optional channel, see Scope of Coverage Details. Information on subscribing to the Optional channel
can be found in the Red Hat Knowledgebase solution How to access Optional and Supplementary
channels. Once subscribed to the Optional channel, issue the following command as root:
~]# yum install lksctp-tools-devel
T his will also install a number of extra man pages listed in the sctp(7) man page.
108
will send messages to the peer. For more options enter the command sctp_darn and a list of options will
be displayed.
It is important to remember the programmatic control aspect of SCT P. T herefore much of how SCT P is
used stems from the application telling the protocol how to act. T herefore detailed knowledge of the
custom application using SCT P is important in drawing up a test plan and a test case to reproduce the
problem. A test case should be given to all those involved in testing. With knowledge of the application and
test cases, detailed network diagrams should be used to obtain and examine copies of routing tables and
tcpdump data from nodes likely to be carrying the SCT P traffic. Note that tcpdump needs to be used on
all relevant interfaces and often on interfaces that do not seem to be relevant. So it is important to check
that the tcpdump data includes all the links for which you have routes on the system. T he SCT P dissector
in Wireshark works well and is well maintained and can therefore be of great help in examining SCT P
traffic.
109
110
111
Description
o<index>
s<slot>[f<function>][d<dev_id>]
x<MAC>
MAC address
p<bus>s<slot>[f<function>][d<dev_id>]
p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
All multi-function PCI devices will carry the [f<function>] number in the device name, including the
function 0 device.
For USB devices the full chain of port numbers of hubs is composed. If the name gets longer than the
maximum number of 15 characters, the name is not exported.
T he USB configuration descriptors == 1 and USB interface descriptors == 0 values are suppressed
(configuration == 1 and interface == 0 are the default values if only one USB configuration or interface
exists).
Use the znetconf -c command or the lscss -a command to display available network devices and
their bus-IDs.
T able 9.2. Device Name T ypes for Linux on System z
112
Description
enccwbus-ID
slccwbus-ID
Old Name
New Name
eth[0123
]
em [1234 ] [a]
eth[0123
]
p<slot>p<ethernet port> [b ]
Virtual function
eth[0123
]
113
T o enable this feature, pass the following option on the boot command line, both during and after
installation:
biosdevname=1
Unless the system meets the minimum requirements, this option will be ignored and the system will use
the system d naming scheme as described in the beginning of the chapter.
If the biosdevnam e install option is specified, it must remain as a boot option for the lifetime of the
system.
Note
T he maximum interface name length is defined by the kernel headers and is a global limit, affecting
all applications.
114
Create your own manual naming scheme, for example by naming your interfaces internet0, dmz0 or
lan0. T o do that create your own udev rules file and set the NAME property for the devices. Make
sure to order it before the default policy file, for example by naming it /etc/udev/rules.d/70-m ynet-nam es.rules.
Alter the default policy file to pick a different naming scheme, for example to name all interfaces after
their MAC address by default. As root copy the default policy file as follows:
115
Edit the file in the /etc/udev/rules.d/ directory and change the lines as necessary.
Add the following line to the /etc/grub.conf file:
net.ifnames=0
or pass it to the kernel at boot time using the GRUB2 command line interface. For more information
about GRUB2 see Red Hat Enterprise Linux 7 System Administrator's Guide.
116
117
118
119
Startup of the rdm a service is automatic. When RDMA capable hardware, whether InfiniBand or iWARP or
RoCE/IBoE is detected, udev instructs system d to start the rdm a service. Users need not enable the
rdm a service, but they can if they wish to force it on all the time. T o do that, issue the following command:
~]# systemctl enable rdma
120
Immediately after link/infiniband is the 20 byte hardware address for the IPoIB interface. T he final 8
bytes of the address, marked in bold above, is all that is required to make a new name. Users can make up
whatever naming scheme suits them. For example, use a device_fabric naming convention such as
m lx4 _ib0 if a m lx4 device is connected to an ib0 subnet fabric. T he only thing that is not
recommended is to use the standard names, like ib0 or ib1, as these can conflict with the kernel
assigned automatic names. Next, add an entry in the rules file. Copy the existing example in the rules file,
replace the 8 bytes in the AT T R{address} entry with the highlighted 8 bytes from the device to be
renamed, and enter the new name to be used in the NAME field.
121
122
123
mgid=ff12:401b::101
mgid=ff12:401b::202
mgid=ff12:601b::1
mgid=ff12:601b::2
mgid=ff12:601b::16
mgid=ff12:601b::fb
mgid=ff12:601b::101
mgid=ff12:601b::202
mgid=ff12:601b::1:3
#
#
#
#
#
#
#
#
#
group
IPv4
IPv4
IPv6
IPv6
IPv6
IPv6
IPv6
IPv6
IPv6
NTP group
Sun RPC
All Hosts group
All Routers group
MLDv2-capable Routers group
mDNS group
NTP group
Sun RPC group
Multicast Link Local Name Resolution
group
ALL=full, ALL_SWITCHES=full;
124
port:
active_mtu:
sm_lid:
port_lid:
port_lmc:
link_layer:
2048 (4)
2
2
0x01
InfiniBand
2
state:
max_mtu:
active_mtu:
sm_lid:
port_lid:
port_lmc:
link_layer:
PORT_ACTIVE (4)
4096 (5)
4096 (5)
0
0
0x00
Ethernet
T he ibv_devinfo and ibstat commands output slightly different information (such as port MT U exists
in ibv_devinfo but not in ibstat output, and the Port GUID exists in ibstat output but not in
ibv_devinfo output), and a few things are named differently (for example, the Base local identifier (LID)
in ibstat output is the same as the port_lid output of ibv_devinfo)
Simple ping programs, such as ibping from the infiniband-diags package, can be used to test RDMA
connectivity. T he ibping program uses a client/server model. You must first start an ibping server on one
machine, then run ibping as a client on another machine and tell it to connect to the ibping server. Since
we are wanting to test the base RDMA capability, we need to use an RDMA specific address resolution
method instead of IP addresses for specifying the server.
On the server machine, the user can use the ibv_devinfo and ibstat commands to print out the
port_lid (or Base lid) and the Port GUID of the port they wish to test (assuming port 1 of the above
interface, the port_lid/Base LID is 2 and Port GUID is 0xf4 5214 03007bcba1)). T hen start ibping
with the necessary options to bind specifically to the card and port to be tested, and also specifying
ibping should run in server mode. You can see the available options to ibping by passing -? or --help,
but in this instance we will need either the -S or --Server option and for binding to the specific card and
125
T hen change to the client machine and run ibping. Make note of either the port GUID of the port the
server ibping program is bound to, or the local identifier (LID) of the port the server ibping program is
bound to. Also, take note which card and port in the client machine is physically connected to the same
network as the card and port that was bound to on the server. For example, if the second port of the first
card on the server was bound to, and that port is connected to a secondary RDMA fabric, then on the
client specify whichever card and port are necessary to also be connected to that secondary fabric. Once
these things are known, run the ibping program as a client and connect to the server using either the port
LID or GUID that was collected on the server as the address to connect to. For example:
~]$ ibping -c 10000 -f -C mlx4_0 -P 1 -L 2
--- rdma-host.example.com.(none) (Lid 2) ibping statistics --10000 packets transmitted, 10000 received, 0% packet loss, time 816 ms
rtt min/avg/max = 0.032/0.081/0.446 ms
or
~]$ ibping -c 10000 -f -C mlx4_0 -P 1 -G 0xf4521403007bcba1 \
--- rdma-host.example.com.(none) (Lid 2) ibping statistics --10000 packets transmitted, 10000 received, 0% packet loss, time 769 ms
rtt min/avg/max = 0.027/0.076/0.278 ms
T his outcome verifies that end to end RDMA communications are working for user space applications.
T he following error may be encountered:
~]$ ibv_devinfo
libibverbs: Warning: no userspace device-specific driver found for
/sys/class/infiniband_verbs/uverbs0
No IB devices found
T his error indicates that the necessary user-space library is not installed. T he administrator will need to
install one of the user-space libraries (as appropriate for their hardware) listed in section Section 10.2,
InfiniBand and RDMA related software packages. On rare occasions, this can happen if a user installs
the wrong arch type for the driver or for libibverbs. For example, if libibverbs is of arch x86_64 , and
libmlx4 is installed but is of type i686, then this error can result.
Note
Many sample applications prefer to use host names or addresses instead of LIDs to open
communication between the server and client. For those applications, it is necessary to set up IPoIB
before attempting to test end-to-end RDMA communications. T he ibping application is unusual in
that it will accept simple LIDs as a form of addressing, and this allows it to be a simple test that
eliminates possible problems with IPoIB addressing from the test scenario and therefore gives us a
more isolated view of whether or not simple RDMA communications are working.
127
T he text user interface appears. Any invalid command prints a usage message.
T o navigate, use the arrow keys or press T ab to step forwards and press Shift+T ab to step back
through the options. Press Enter to select an option. T he Space bar toggles the status of a check box.
128
Figure 10.1. T he NetworkManager T ext User Interface Add an InfiniBand Connection menu
Select InfiniBand, the Edit connection screen opens. Follow the on-screen prompts to complete
the configuration.
129
Once the devices have the name required, use the nmcli tool to create the IPoIB interface(s) as follows:
~]$ nmcli con add type infiniband con-name mlx4_ib0 ifname mlx4_ib0 transportmode connected mtu 65520
Connection 'mlx4_ib0' (8029a0d7-8b05-49ff-a826-2a6d722025cc) successfully added.
~]$ nmcli con edit mlx4_ib0
===| nmcli interactive connection editor |===
Editing existing 'infiniband' connection: 'mlx4_ib0'
Type 'help' or '?' for available commands.
Type 'describe [>setting<.>prop<]' for detailed property description.
You may edit the following settings: connection, infiniband, ipv4, ipv6
nmcli> set infiniband.mac-address
80:00:02:00:fe:80:00:00:00:00:00:00:f4:52:14:03:00:7b:cb:a3
nmcli> save
Connection 'mlx4_ib3' (8029a0d7-8b05-49ff-a826-2a6d722025cc) successfully updated.
nmcli> quit
At this point, an IPoIB interface named m lx4 _ib0 has been created and set to use connected mode, with
the maximum connected mode MT U, DHCP for IPv4 and IPv6. If using IPoIB interfaces for cluster traffic
and an Ethernet interface for out-of-cluster communications, it is likely that disabling default routes and any
default name server on the IPoIB interfaces will be required. T his is can be done as follows:
~]$ nmcli con edit mlx4_ib0
===| nmcli interactive connection editor |===
Editing existing 'infiniband' connection: 'mlx4_ib0'
Type 'help' or '?' for available commands.
Type 'describe [>setting<.>prop<]' for detailed property description.
You may edit the following settings: connection, infiniband, ipv4, ipv6
nmcli> set ipv4.ignore-auto-dns yes
nmcli> set ipv4.ignore-auto-routes yes
nmcli> set ipv4.never-default true
130
Once the devices have the name required, administrators can create ifcfg files with their preferred
editor to control the devices. A typical IPoIB configuration file with static IPv4 addressing looks as follows:
~]$ more ifcfg-mlx4_ib0
DEVICE=mlx4_ib0
TYPE=InfiniBand
>HWADDR=80:00:00:4c:fe:80:00:00:00:00:00:00:f4:52:14:03:00:7b:cb:a1
BOOTPROTO=static
IPADDR=172.31.0.254
NETMASK=255.255.255.0
NETWORK=172.31.0.0
BROADCAST=172.31.0.255
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
MTU=65520
CONNECTED_MODE=yes
NAME=mlx4_ib0
T he DEVICE field must match the custom name created in any udev renaming rules. T he NAME entry
need not match the device name. If the GUI connection editor is started, the NAME field is what is used to
present a name for this connection to the user. T he T YPE field must be InfiniBand in order for InfiniBand
options to be processed properly. CONNECT ED_MODE is either yes or no, where yes will use connected
mode and no will use datagram mode for communications (see section Section 10.6.2, Understanding
IPoIB communication modes).
For P_Key interfaces, this is a typical configuration file:
131
For all P_Key interface files, the PHYSDEV is required and must be the name of the parent device, PKEY
must be yes, and PKEY_ID must be the number of the interface (either with or without the 0x8000
membership bit added in). T he device name, however, must be the four digit hexadecimal representation of
the PKEY_ID with the 0x8000 membership bit logically ORed into the number. By default, the PKEY_ID in
the file is treated as a decimal number and converted to hexadecimal and then ORed with 0x8000 to
arrive at the proper name for the device, but users may specify the PKEY_ID in hexadecimal by
prepending the standard 0x prefix to the number.
132
133
134
135
136
Installing the dhcp package creates a file, /etc/dhcp/dhcpd.conf, which is merely an empty
configuration file:
~]# cat /etc/dhcp/dhcpd.conf
#
# DHCP Server Configuration file.
#
see /usr/share/doc/dhcp*/dhcpd.conf.example
#
see dhcpd.conf(5) man page
#
T he example configuration file can be found at /usr/share/doc/dhcp<version>/dhcpd.conf.exam ple. You should use this file to help you configure
/etc/dhcp/dhcpd.conf, which is explained in detail below.
DHCP also uses the file /var/lib/dhcpd/dhcpd.leases to store the client lease database. Refer to
Section 11.2.2, Lease Database for more information.
137
Important
If the configuration file is changed, the changes do not take effect until the DHCP daemon is
restarted with the command system ctl restart dhcpd.
Note
Instead of changing a DHCP configuration file and restarting the service each time, using the
om shell command provides an interactive way to connect to, query, and change the configuration
of a DHCP server. By using om shell, all changes can be made while the server is running. For
more information on om shell, see the om shell man page.
In Example 11.1, Subnet Declaration, the routers, subnet-m ask, dom ain-search, dom ain-nam eservers, and tim e-offset options are used for any host statements declared below it.
For every subnet which will be served, and for every subnet to which the DHCP server is connected, there
must be one subnet declaration, which tells the DHCP daemon how to recognize that an address is on
that subnet. A subnet declaration is required for each subnet even if no addresses will be dynamically
allocated to that subnet.
In this example, there are global options for every DHCP client in the subnet and a range declared. Clients
are assigned an IP address within the range.
Example 11.1. Subnet Declaration
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers
192.168.1.254;
option subnet-mask
255.255.255.0;
option domain-search
"example.com";
option domain-name-servers
192.168.1.1;
option time-offset
-18000;
# Eastern Standard Time
range 192.168.1.10 192.168.1.100;
}
138
T o assign an IP address to a client based on the MAC address of the network interface card, use the
hardware ethernet parameter within a host declaration. As demonstrated in Example 11.3, Static IP
Address Using DHCP, the host apex declaration specifies that the network interface card with the MAC
address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4 .
Note that you can also use the optional parameter host-nam e to assign a host name to the client.
Example 11.3. Static IP Address Using DHCP
host apex {
option host-name "apex.example.com";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.4;
}
Red Hat Enterprise Linux 7 supports assigning static IP addresses to InfiniBand IPoIB interfaces.
However, as these interfaces do not have a normal hardware Ethernet address, a different method of
specifying a unique identifier for the IPoIB interface must be used. T he standard is to use the option
dhcp-client-identifier= construct to specify the IPoIB interfaces dhcp-client-identifier
field. T he DHCP server host construct supports at most one hardware Ethernet and one dhcp-clientidentifier entry per host stanza. However, there may be more than one fixed-address entry and the
DHCP server will automatically respond with an address that is appropriate for the network that the DHCP
request was received on.
139
In order to find the right dhcp-client-identifier for your device, you can usually use the prefix
ff:00:00:00:00:00:02:00:00:02:c9:00 and then add the last 8 bytes of the IPoIB interface
(which happens to also be the 8 byte GUID of the InfiniBand port the IPoIB interface is on). On some
older controllers, this prefix is not correct. In that case, we recommend using tcpdump on the DHCP
server to capture the incoming IPoIB DHCP request and gather the right dhcp-client-identifier
from that capture. For example:
]$ tcpdump -vv -i mlx4_ib0
tcpdump: listening on mlx4_ib0, link-type LINUX_SLL (Linux cooked), capture size
65535 bytes
23:42:44.131447 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request,
length 300, htype 32, hlen 0, xid 0x975cb024, Flags [Broadcast] (0x8000)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 10: "rdma-qe-03"
Parameter-Request Option 55, length 18:
Subnet-Mask, BR, Time-Zone, Classless-Static-Route
Domain-Name, Domain-Name-Server, Hostname, YD
YS, NTP, MTU, Option 119
Default-Gateway, Classless-Static-Route, Classless-Static-RouteMicrosoft, Static-Route
Option 252, NTP
Client-ID Option 61, length 20: hardware-type 255,
00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:02:00:21:ac:c1
T he above dump shows the Client-ID field. T he hardware-type 255 corresponds to the initial ff: of the
ID, the rest of the ID is then quoted exactly as it needs to appear in the DHCP configuration file.
All subnets that share the same physical network should be declared within a shared-network
declaration as shown in Example 11.5, Shared-network Declaration. Parameters within the sharednetwork, but outside the enclosed subnet declarations, are considered to be global parameters. T he
name assigned to shared-network must be a descriptive title for the network, such as using the title
14 0
As demonstrated in Example 11.6, Group Declaration, the group declaration is used to apply global
parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.
Example 11.6. Group Declaration
group {
option routers
192.168.1.254;
option subnet-mask
255.255.255.0;
option domain-search
"example.com";
option domain-name-servers
192.168.1.1;
option time-offset
-18000;
# Eastern Standard Time
host apex {
option host-name "apex.example.com";
hardware ethernet 00:A0:78:8E:9E:AA;
fixed-address 192.168.1.4;
}
host raleigh {
option host-name "raleigh.example.com";
hardware ethernet 00:A1:DD:74:C3:F2;
fixed-address 192.168.1.6;
}
}
Note
You can use the provided example configuration file as a starting point and add custom
configuration options to it. T o copy this file to the proper location, use the following command as
root:
~]# cp /usr/share/doc/dhcp-<version_number>/dhcpd.conf.example
/etc/dhcp/dhcpd.conf
For a complete list of option statements and what they do, see the dhcp-options(5) man page.
14 1
T o start the DHCP service, use the command system ctl start dhcpd. T o stop the DHCP server, use
the command system ctl stop dhcpd.
By default, the DHCP service does not start at boot time. For information on how to configure the daemon to
start automatically at boot time, see Red Hat Enterprise Linux 7 System Administrator's Guide.
If more than one network interface is attached to the system, but the DHCP server should only listen for
DHCP requests on one of the interfaces, configure the DHCP server to listen only on that device. T he DHCP
daemon will only listen on interfaces for which it finds a subnet declaration in the
/etc/dhcp/dhcpd.conf file.
T his is useful for a firewall machine with two network cards. One network card can be configured as a
DHCP client to retrieve an IP address to the Internet. T he other network card can be used as a DHCP
server for the internal network behind the firewall. Specifying only the network card connected to the
internal network makes the system more secure because users can not connect to the daemon via the
Internet.
T o specify command line options, copy and then edit the dhcpd.service file as the root user. For
example, as follows:
14 2
14 3
Edit the ExecStart option under section [Service] and add one or more server IPv4 addresses to the
end of the line, for example:
ExecStart=/usr/sbin/dhcrelay -d --no-pid 192.168.1.1
If you also want to specify interfaces where the DHCP Relay Agent listens for DHCP requests, add them to
the ExecStart option with -i argument, for example:
ExecStart=/usr/sbin/dhcrelay -d --no-pid 192.168.1.1 -i em1
Edit the ExecStart option under section [Service] add -6 argument and add the lower interface and
upper interface interface, for example:
ExecStart=/usr/sbin/dhcrelay -d --no-pid -6 -l em1 -u em2
14 4
14 5
host example0
T he host declaration defines specific parameters for a single system, such as an IP address.
T o configure specific parameters for multiple hosts, use multiple host declarations.
Most DHCP clients ignore the name in host declarations, and as such, this name can be anything,
as long as it is unique to other host declarations. T o configure the same system for multiple
networks, use a different name for each host declaration, otherwise the DHCP daemon fails to
start. Systems are identified by the hardware ethernet option, not the name in the host
declaration.
hardware ethernet 00:1A:6B:6A:2E:0B;
T he hardware ethernet option identifies the system. T o find this address, run the ip link
command.
fixed-address 10.0.0.20;
T he fixed-address option assigns a valid IP address to the system specified by the
hardware ethernet option. T his address must be outside the IP address pool specified with
the range option.
If option statements do not end with a semicolon, the DHCP daemon fails to start, and an error such as
the following is logged to /var/log/m essages:
/etc/dhcp/dhcpd.conf line 20: semicolon expected.
dhcpd: }
dhcpd: ^
dhcpd: /etc/dhcp/dhcpd.conf line 38: unexpected end of file
dhcpd:
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
14 6
For this example, interface0 is the first network interface, and interface1 is the second interface.
T he different hardware ethernet options identify each interface.
If such a system connects to another network, add more host declarations, remembering to:
assign a valid fixed-address for the network the host is connecting to.
make the name in the host declaration unique.
When a name given in a host declaration is not unique, the DHCP daemon fails to start, and an error such
as the following is logged to /var/log/m essages:
dhcpd:
dhcpd:
dhcpd:
dhcpd:
T his error was caused by having multiple host interface0 declarations defined in
/etc/dhcp/dhcpd.conf.
14 7
14 8
86400
IN
192.0.2.1
T he domain name, exam ple.com , is the owner for the RR. T he value 864 00 is the time to live (T T L).
T he letters IN, meaning the Internet system, indicate the class of the RR. T he letter A indicates the
type of RR (in this example, a host address). T he host address 192.0.2.1 is the data contained in the
final section of this RR. T his one line example is a RR. A set of RRs with the same type, owner, and
class is called a resource record set (RRSet).
Z ones are defined on authoritative nameservers through the use of zone files, which contain definitions of
the resource records in each zone. Z one files are stored on primary nameservers (also called master
nameservers), where changes are made to the files, and secondary nameservers (also called slave
nameservers), which receive zone definitions from the primary nameservers. Both primary and secondary
nameservers are authoritative for the zone and look the same to clients. Depending on the configuration,
any nameserver can also serve as a primary or secondary server for multiple zones at the same time.
Note that administrators of DNS and DHCP servers, as well as any provisioning applications, should agree
on the host name format used in an organization. See Section 3.1.1, Recommended Naming Practices for
more information on the format of host names.
14 9
12.2. BIND
T his section covers BIND (Berkeley Internet Name Domain), the DNS server included in Red Hat
Enterprise Linux. It focuses on the structure of its configuration files, and describes how to administer it
both locally and remotely.
Description
/etc/nam ed.conf
150
Description
/etc/nam ed/
T he configuration file consists of a collection of statements with nested options surrounded by opening
and closing curly brackets ({ and }). Note that when editing the file, you have to be careful not to make
any syntax error, otherwise the nam ed service will not start. A typical /etc/nam ed.conf file is
organized as follows:
statement-1 ["statement-1-name"] [statement-1-class] {
option-1;
option-2;
option-N;
};
statement-2 ["statement-2-name"] [statement-2-class] {
option-1;
option-2;
option-N;
};
statement-N ["statement-N-name"] [statement-N-class] {
option-1;
option-2;
option-N;
};
151
Note
If you have installed the bind-chroot package, the BIND service will run in the
/var/nam ed/chroot environment. In that case, the initialization script will mount the above
configuration files using the m ount --bind command, so that you can manage the configuration
outside this environment. T here is no need to copy anything into the /var/nam ed/chroot
directory because it is mounted automatically. T his simplifies maintenance since you do not need to
take any special care of BIND configuration files if it is run in a chroot environment. You can
organize everything as you would with BIND not running in a chroot environment.
T he following directories are automatically mounted into /var/nam ed/chroot if they are empty in
the /var/nam ed/chroot directory. T hey must be kept empty if you want them to be mounted into
/var/nam ed/chroot:
/etc/nam ed
/etc/pki/dnssec-keys
/run/nam ed
/var/nam ed
/usr/lib64 /bind or /usr/lib/bind (architecture dependent).
T he following files are also mounted if the target file does not exist in /var/nam ed/chroot.
/etc/nam ed.conf
/etc/rndc.conf
/etc/rndc.key
/etc/nam ed.rfc1912.zones
/etc/nam ed.dnssec.keys
/etc/nam ed.iscdlv.key
/etc/nam ed.root.key
T o enable the nam ed-chroot service, first check if the nam ed service is running by issuing the following
command:
~]$ systemctl status named
T hen, to enable the nam ed-chroot service, issue the following commands as root:
152
T o check the status of the named-chroot service, issue the following command as root:
~]# systemctl status named-chroot
T he acl-name statement name is the name of the access control list, and the match-element
option is usually an individual IP address (such as 10.0.1.1) or a Classless Inter-Domain
Routing (CIDR) network notation (for example, 10.0.1.0/24 ). For a list of already defined
keywords, see T able 12.2, Predefined Access Control Lists.
T able 12.2. Predefined Access Control Lists
Keyword
Description
any
localhost
localnets
none
T he acl statement can be especially useful in conjunction with other statements such as
options. Example 12.2, Using acl in Conjunction with Options defines two access control lists,
black-hats and red-hats, and adds black-hats on the blacklist while granting red-hats
normal access.
153
include
T he include statement allows you to include files in the /etc/nam ed.conf, so that potentially
sensitive data can be placed in a separate file with restricted permissions. It takes the following
form:
include "file-name"
options
T he options statement allows you to define global server configuration options as well as to set
defaults for other statements. It can be used to specify the location of the nam ed working
directory, the types of queries allowed, and much more. It takes the following form:
options {
option;
...
};
For a list of frequently used option directives, see T able 12.3, Commonly Used Configuration
Options below.
T able 12.3. Commonly Used Configuration Options
154
Option
Description
allow-query
allow-querycache
Specifies which hosts are allowed to query the nameserver for nonauthoritative data such as recursive queries. Only localhost and
localnets are allowed by default.
Description
blackhole
Specifies which hosts are not allowed to query the nameserver. T his
option should be used when a particular host or network floods the
server with requests. T he default option is none.
directory
disable-em ptyzone
Used to disable one or more empty zones from the list of default
prefixes that would be used. Can be specified in the options statement
and also in view statements. It can be used multiple times.
dnssec-enable
dnssecvalidation
em pty-zonesenable
forwarders
forward
listen-on
listen-on-v6
m ax-cache-size
notify
155
Description
pid-file
recursion
statistics-file
Note
T he directory used by nam ed for runtime data has been moved from the BIND default
location, /var/run/nam ed/, to a new location /run/nam ed/. As a result, the PID file
has been moved from the default location /var/run/nam ed/nam ed.pid to the new
location /run/nam ed/nam ed.pid. In addition, the session-key file has been moved to
/run/nam ed/session.key. T hese locations need to be specified by statements in the
options section. See Example 12.4, Using the options Statement.
Important
T o prevent distributed denial of service (DDoS) attacks, it is recommended that you use
the allow-query-cache option to restrict recursive DNS services for a particular subset
of clients only.
Refer to the BIND 9 Administrator Reference Manual referenced in Section 12.2.8.1, Installed
Documentation, and the nam ed.conf manual page for a complete list of available options.
Example 12.4 . Using the options Statement
options {
allow-query
listen-on port
listen-on-v6 port
max-cache-size
directory
statistics-file
{ localhost; };
53 { 127.0.0.1; };
53 { ::1; };
256M;
"/var/named";
"/var/named/data/named_stats.txt";
recursion
yes;
dnssec-enable
yes;
dnssec-validation yes;
pid-file
session-keyfile
"/run/named/named.pid";
"/run/named/session.key";
};
zone
T he zone statement allows you to define the characteristics of a zone, such as the location of its
configuration file and zone-specific options, and can be used to override the global options
statements. It takes the following form:
156
T he zone-name attribute is the name of the zone, zone-class is the optional class of the zone,
and option is a zone statement option as described in T able 12.4, Commonly Used Options in
Z one Statements.
T he zone-name attribute is particularly important, as it is the default value assigned for the
$ORIGIN directive used within the corresponding zone file located in the /var/nam ed/
directory. T he nam ed daemon appends the name of the zone to any non-fully qualified domain
name listed in the zone file. For example, if a zone statement defines the namespace for
exam ple.com , use exam ple.com as the zone-name so that it is placed at the end of host
names within the exam ple.com zone file.
For more information about zone files, refer to Section 12.2.3, Editing Z one Files.
T able 12.4 . Commonly Used Options in Z one Statements
Option
Description
allow-query
allow-transfer
allow-update
file
Specifies the name of the file in the nam ed working directory that
contains the zone's configuration data.
m asters
notify
157
Description
type
Most changes to the /etc/nam ed.conf file of a primary or secondary nameserver involve
adding, modifying, or deleting zone statements, and only a small subset of zone statement
options is usually needed for a nameserver to work efficiently.
In Example 12.5, A Z one Statement for a Primary nameserver, the zone is identified as
exam ple.com , the type is set to m aster, and the nam ed service is instructed to read the
/var/nam ed/exam ple.com .zone file. It also allows only a secondary nameserver
(192.168.0.2) to transfer the zone.
Example 12.5. A Z one Statement for a Primary nameserver
zone "example.com" IN {
type master;
file "example.com.zone";
allow-transfer { 192.168.0.2; };
};
A secondary server's zone statement is slightly different. T he type is set to slave, and the
m asters directive is telling nam ed the IP address of the master server.
In Example 12.6, A Z one Statement for a Secondary nameserver, the nam ed service is
configured to query the primary server at the 192.168.0.1 IP address for information about the
exam ple.com zone. T he received information is then saved to the
/var/nam ed/slaves/exam ple.com .zone file. Note that you have to put all slave zones in
the /var/nam ed/slaves/ directory, otherwise the service will fail to transfer the zone.
158
159
#
Any text after the # character to the end of the line is considered a comment. For example:
notify yes;
/* and * /
Any block of text enclosed in /* and * / is considered a comment. For example:
notify yes;
Description
/var/nam ed/
/var/nam ed/slaves/
/var/nam ed/data/
A zone file consists of directives and resource records. Directives tell the nameserver to perform tasks or
apply special settings to the zone, resource records define the parameters of the zone and assign
identities to individual hosts. While the directives are optional, the resource records are required in order
to provide name service to a zone.
All directives and resource records should be entered on individual lines.
12.2.3.1. Common Directives
Directives begin with the dollar sign character ($) followed by the name of the directive, and usually appear
at the top of the file. T he following directives are commonly used in zone files:
$INCLUDE
T he $INCLUDE directive allows you to include another file at the place where it appears, so that
other zone settings can be stored in a separate zone file.
Example 12.7. Using the $INCLUDE Directive
$INCLUDE /var/named/penguin.example.com
$ORIGIN
T he $ORIGIN directive allows you to append the domain name to unqualified records, such as
those with the host name only. Note that the use of this directive is not necessary if the zone is
specified in /etc/nam ed.conf, since the zone name is used by default.
In Example 12.8, Using the $ORIGIN Directive, any names used in resource records that do not
end in a trailing period (the . character) are appended with exam ple.com .
Example 12.8. Using the $ORIGIN Directive
$ORIGIN example.com.
161
If the hostname value is omitted, the record will point to the last specified hostname.
In Example 12.10, Using the A Resource Record, the requests for server1.exam ple.com
are pointed to 10.0.1.3 or 10.0.1.5.
Example 12.10. Using the A Resource Record
server1
IN
IN
A
A
10.0.1.3
10.0.1.5
CNAME
T he Canonical Name record maps one name to another. Because of this, this type of record is
sometimes referred to as an alias record. It takes the following form:
alias-name IN CNAME real-name
CNAME records are most commonly used to point to services that use a common naming scheme,
such as www for Web servers. However, there are multiple restrictions for their usage:
CNAME records should not point to other CNAME records. T his is mainly to avoid possible
infinite loops.
CNAME records should not contain other resource record types (such as A, NS, MX, etc.). T he
only exception are DNSSEC related records (RRSIG, NSEC, etc.) when the zone is signed.
Other resource records that point to the fully qualified domain name (FQDN) of a host (NS, MX,
PT R) should not point to a CNAME record.
162
IN
IN
A
CNAME
10.0.1.5
server1
MX
T he Mail Exchange record specifies where the mail sent to a particular namespace controlled by
this zone should go. It takes the following form:
IN MX preference-value email-server-name
IN
IN
MX
MX
10
20
mail.example.com.
mail2.example.com.
NS
T he Nameserver record announces authoritative nameservers for a particular zone. It takes the
following form:
IN NS nameserver-name
T he nameserver-name should be a fully qualified domain name (FQDN). Note that when two
nameservers are listed as authoritative for the domain, it is not important whether these
nameservers are secondary nameservers, or if one of them is a primary server. T hey are both
still considered authoritative.
Example 12.13. Using the NS Resource Record
IN
IN
NS
NS
dns1.example.com.
dns2.example.com.
PT R
T he Pointer record points to another part of the namespace. It takes the following form:
last-IP-digit IN PTR FQDN-of-system
163
IN
164
Seconds
60
1M
1800
30M
3600
1H
10800
3H
21600
6H
43200
12H
86400
1D
259200
3D
604800
1W
31536000
365D
IN
165
IN
IN
CNAME
CNAME
services.example.com.
services.example.com.
In this example, the authoritative nameservers are set as dns1.exam ple.com and
dns2.exam ple.com , and are tied to the 10.0.1.1 and 10.0.1.2 IP addresses respectively using the
A record.
T he email servers configured with the MX records point to m ail and m ail2 via A records. Since these
names do not end in a trailing period, the $ORIGIN domain is placed after them, expanding them to
m ail.exam ple.com and m ail2.exam ple.com .
Services available at the standard names, such as www.exam ple.com (WWW), are pointed at the
appropriate servers using the CNAME record.
T his zone file would be called into service with a zone statement in the /etc/nam ed.conf similar to the
following:
166
In this example, IP addresses 10.0.1.1 through 10.0.1.6 are pointed to the corresponding fully
qualified domain name.
T his zone file would be called into service with a zone statement in the /etc/nam ed.conf file similar to
the following:
zone "1.0.10.in-addr.arpa" IN {
type master;
file "example.com.rr.zone";
allow-update { none; };
};
T here is very little difference between this example and a standard zone statement, except for the zone
name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed
followed by .in-addr.arpa. T his allows the single block of IP numbers used in the reverse name
resolution zone file to be associated with the zone.
167
Description
/etc/nam ed.conf
/etc/rndc.conf
/etc/rndc.key
T he rndc configuration is located in /etc/rndc.conf. If the file does not exist, the utility will use the key
located in /etc/rndc.key, which was generated automatically during the installation process using the
rndc-confgen -a command.
T he nam ed service is configured using the controls statement in the /etc/nam ed.conf configuration
file as described in Section 12.2.2.3, Other Statement T ypes. Unless this statement is present, only the
connections from the loopback address (127.0.0.1) will be allowed, and the key located in
/etc/rndc.key will be used.
For more information on this topic, refer to manual pages and the BIND 9 Administrator Reference Manual
listed in Section 12.2.8, Additional Resources.
Important
T o prevent unprivileged users from sending control commands to the service, make sure only root
is allowed to read the /etc/rndc.key file:
~]# chmod o-rwx /etc/rndc.key
168
T his will reload the zones while keeping all previously cached responses, so that you can make changes
to the zone files without losing all stored name resolutions.
T o reload a single zone, specify its name after the reload command, for example:
~]# rndc reload localhost
zone reload up-to-date
Finally, to reload the configuration file and newly added zones only, type:
~]# rndc reconfig
Note
If you intend to manually modify a zone that uses Dynamic DNS (DDNS), make sure you run the
freeze command first:
~]# rndc freeze localhost
Once you are finished, run the thaw command to allow the DDNS again and reload the zone:
~]# rndc thaw localhost
The zone reload and thaw was successful.
Note that to sign a zone with the above command, the auto-dnssec option has to be set to m aintain in
the zone statement. For example:
zone "localhost" IN {
type master;
file "named.localhost";
allow-update { none; };
auto-dnssec maintain;
};
169
Refer to the options statement described in Section 12.2.2.2, Common Statement T ypes for information
on how configure this option in /etc/nam ed.conf.
T he Red Hat Enterprise Linux 7 Security Guide has a comprehensive section on DNSSEC.
12.2.4 .6. Enabling the Query Logging
T o enable (or disable in case it is currently enabled) the query logging, issue the following command as
root:
~]# rndc querylog
T o check the current setting, use the status command as described in Section 12.2.4.2, Checking the
Service Status.
Refer to Section 12.2.3.2, Common Resource Records for a list of common values to use for type.
12.2.5.1. Looking Up a Nameserver
T o look up a nameserver for a particular domain, use the command in the following form:
dig name NS
In Example 12.17, A sample nameserver lookup, the dig utility is used to display nameservers for
exam ple.com .
170
99374
99374
IN
NS
IN
IN
NS
NS
a.iana-servers.net.
b.iana-servers.net.
In Example 12.18, A sample IP address lookup, the dig utility is used to display the IP address of
exam ple.com .
Example 12.18. A sample IP address lookup
~]$ dig example.com A
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com.
IN
;; ANSWER SECTION:
example.com.
155606
IN
192.0.32.10
;; AUTHORITY SECTION:
example.com.
example.com.
99175
99175
IN
IN
NS
NS
a.iana-servers.net.
b.iana-servers.net.
;;
;;
;;
;;
171
In Example 12.19, A Sample Host Name Lookup, the dig utility is used to display the host name
assigned to 192.0.32.10.
Example 12.19. A Sample Host Name Lookup
~]$ dig -x 192.0.32.10
; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> -x 192.0.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29683
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6
;; QUESTION SECTION:
;10.32.0.192.in-addr.arpa.
IN
PTR
;; ANSWER SECTION:
10.32.0.192.in-addr.arpa. 21600 IN
PTR
www.example.com.
;; AUTHORITY SECTION:
32.0.192.in-addr.arpa.
32.0.192.in-addr.arpa.
32.0.192.in-addr.arpa.
32.0.192.in-addr.arpa.
32.0.192.in-addr.arpa.
21600
21600
21600
21600
21600
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
b.iana-servers.org.
c.iana-servers.net.
d.iana-servers.net.
ns.icann.org.
a.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net.
b.iana-servers.org.
b.iana-servers.org.
c.iana-servers.net.
c.iana-servers.net.
ns.icann.org.
13688
5844
5844
12173
12173
12884
IN
IN
IN
IN
IN
IN
A
A
AAAA
A
AAAA
A
192.0.34.43
193.0.0.236
2001:610:240:2::c100:ec
139.91.1.10
2001:648:2c30::1:10
192.0.34.126
;;
;;
;;
;;
172
Important
Before attempting to use advanced features like DNSSEC, T SIG, or IXFR (Incremental Z one
T ransfer), make sure that the particular feature is supported by all nameservers in the network
environment, especially when you use older versions of BIND or non-BIND servers.
All of the features mentioned are discussed in greater detail in the BIND 9 Administrator Reference Manual
referenced in Section 12.2.8.1, Installed Documentation.
12.2.6.1. Multiple Views
Optionally, different information can be presented to a client depending on the network a request
originates from. T his is primarily used to deny sensitive DNS entries from clients outside of the local
network, while allowing queries from clients inside the local network.
T o configure multiple views, add the view statement to the /etc/nam ed.conf configuration file. Use the
m atch-clients option to match IP addresses or entire networks and give them special options and
zone data.
12.2.6.2. Incremental Z one T ransfers (IXFR)
Incremental Zone Transfers (IXFR) allow a secondary nameserver to only download the updated portions
of a zone modified on a primary nameserver. Compared to the standard transfer process, this makes the
notification and update process much more efficient.
Note that IXFR is only available when using dynamic updating to make changes to master zone records. If
manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used.
12.2.6.3. T ransaction SIGnatures (T SIG)
Transaction SIGnatures (T SIG) ensure that a shared secret key exists on both primary and secondary
nameservers before allowing a transfer. T his strengthens the standard IP address-based method of
transfer authorization, since attackers would not only need to have access to the IP address to transfer
the zone, but they would also need to know the secret key.
Since version 9, BIND also supports TKEY, which is another shared secret key method of authorizing zone
transfers.
Important
When communicating over an insecure network, do not rely on IP address-based authentication
only.
173
Warning
Using a fixed UDP source port for DNS queries is a potential security vulnerability that
could allow an attacker to conduct cache-poisoning attacks more easily. T o prevent this, by
default DNS sends from a random ephemeral port. Configure your firewall to allow outgoing
queries from a random UDP source port. T he range 1024 to 65535 is used by default.
174
175
Revision History
Revision 0.9-8
T ue July 8 2014
Red Hat Enterprise Linux 7.0 GA release of the Networking Guide.
Stephen Wadeley
Revision 0-0
Wed Dec 12 2012
Initialization of the Red Hat Enterprise Linux 7 Networking Guide.
Stephen Wadeley
A.1. Acknowledgments
Certain portions of this text first appeared in the Red Hat Enterprise Linux 6 Deployment Guide, copyright
2014 Red Hat, Inc., available at https://access.redhat.com/site/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/index.html.
Index
Symbols
/etc/named.conf (see BIND)
A
authoritative nameserver (see BIND)
B
Berkeley Internet Name Domain (see BIND)
BIND
- additional resources, Online Resources
- installed documentation, Installed Documentation
- common mistakes, Common Mistakes to Avoid
- configuration
- acl statement, Common Statement T ypes
- comment tags, Comment T ags
- controls statement, Other Statement T ypes
- include statement, Common Statement T ypes
- key statement, Other Statement T ypes
- logging statement, Other Statement T ypes
- options statement, Common Statement T ypes
- server statement, Other Statement T ypes
- trusted-keys statement, Other Statement T ypes
- view statement, Other Statement T ypes
- zone statement, Common Statement T ypes
- directories
- /etc/named/, Configuring the named Service
- /var/named/, Editing Z one Files
- /var/named/data/, Editing Z one Files
- /var/named/dynamic/, Editing Z one Files
- /var/named/slaves/, Editing Z one Files
- features
- Automatic Z one T ransfer (AXFR), Incremental Z one T ransfers (IXFR)
- DNS Security Extensions (DNSSEC), DNS Security Extensions (DNSSEC)
176
Revision History
-
- files
- /etc/named.conf, Configuring the named Service, Configuring the Utility
- /etc/rndc.conf, Configuring the Utility
- /etc/rndc.key, Configuring the Utility
- resource record, Nameserver Z ones
- types
- authoritative nameserver, Nameserver T ypes
- primary (master) nameserver, Nameserver Z ones, Nameserver T ypes
- recursive nameserver, Nameserver T ypes
- secondary (slave) nameserver, Nameserver Z ones, Nameserver T ypes
- utilities
- dig, BIND as a Nameserver, Using the dig Utility, DNS Security Extensions
(DNSSEC)
- named, BIND as a Nameserver, Configuring the named Service
- rndc, BIND as a Nameserver, Using the rndc Utility
- zones
-
C
channel bonding
- configuration, Using Channel Bonding
- description, Using Channel Bonding
- parameters to bonded interfaces, Bonding Module Directives
channel bonding interface (see kernel module)
D
default gateway, Static Routes and the Default Gateway
DHCP, DHCP Servers
- additional resources, Additional Resources
- command line options, Starting and Stopping the Server
- dhcpd.conf, Configuration File
- dhcpd.leases, Starting and Stopping the Server
- dhcpd6.conf, DHCP for IPv6 (DHCPv6)
177
K
kernel module
- bonding module, Using Channel Bonding
- description, Using Channel Bonding
- parameters to bonded interfaces, Bonding Module Directives
- module parameters
- bonding module parameters, Bonding Module Directives
M
Multihomed DHCP
- host configuration, Host Configuration
- server configuration, Configuring a Multihomed DHCP Server
N
named (see BIND)
nameserver (see DNS)
NIC
- binding into single channel, Using Channel Bonding
P
primary nameserver (see BIND)
R
recursive nameserver (see BIND)
resource record (see BIND)
rndc (see BIND)
178
Revision History
root nameserver (see BIND)
S
secondary nameserver (see BIND)
static route, Static Routes and the Default Gateway
179