Manual configuration of the network software should be the last alternative. Using YaST is recommended. However, this background information about the network configuration can also assist your work with YaST.
17.6.1 The wicked
Network Configuration
#
The tool and library called wicked
provides a new framework for network configuration.
One of the challenges with traditional network interface management is that different layers of network management get jumbled together into one single script, or at most two different scripts. These scripts interact with each other in a way that is not well-defined. This leads to unpredictable issues, obscure constraints and conventions, etc. Several layers of special hacks for a variety of different scenarios increase the maintenance burden. Address configuration protocols are being used that are implemented via daemons like dhcpcd, which interact rather poorly with the rest of the infrastructure. Funky interface naming schemes that require heavy udev support are introduced to achieve persistent identification of interfaces.
The idea of wicked is to decompose the problem in several ways. None of them is entirely novel, but trying to put ideas from different projects together is hopefully going to create a better solution overall.
One approach is to use a client/server model. This allows wicked to define standardized facilities for things like address configuration that are well integrated with the overall framework. For example, using a specific address configuration, the administrator may request that an interface should be configured via DHCP or IPv4 zeroconf. In this case, the address configuration service simply obtains the lease from its server and passes it on to the wicked server process that installs the requested addresses and routes.
The other approach to decomposing the problem is to enforce the layering aspect. For any type of network interface, it is possible to define a dbus service that configures the network interface's device layer—a VLAN, a bridge, a bonding, or a paravirtualized device. Common functionality, such as address configuration, is implemented by joint services that are layered on top of these device specific services without having to implement them specifically.
The wicked framework implements these two aspects by using a variety of dbus services, which get attached to a network interface depending on its type. Here is a rough overview of the current object hierarchy in wicked.
Each network interface is represented via a
child object of /org/opensuse/Network/Interfaces
. The name of the child object is given by its ifindex. For example, the loopback interface, which usually gets ifindex 1, is /org/opensuse/Network/Interfaces/1
, the first Ethernet interface registered is /org/opensuse/Network/Interfaces/2
.
Each network interface has a “class” associated with it, which is used to select the dbus interfaces it supports. By default, each network interface is of class netif
, and wickedd
will automatically attach all interfaces compatible with this class.
In the current implementation, this includes the following interfaces:
org.opensuse.Network.Interface
Generic network interface functions, such as taking the link up or down, assigning an MTU, etc.
org.opensuse.Network.Addrconf.ipv4.dhcp, org.opensuse.Network.Addrconf.ipv6.dhcp, org.opensuse.Network.Addrconf.ipv4.autoAddress configuration services for DHCP, IPv4 zeroconf, etc.
Beyond this, network interfaces may require or offer special configuration mechanisms. For an Ethernet device, for example, you should be able to control the link speed, offloading of checksumming, etc. To achieve this, Ethernet devices have a class of their own, called netif-ethernet
, which is a subclass of netif
. As a consequence, the dbus interfaces assigned to an Ethernet interface include all the services listed above, plus the
org.opensuse.Network.Ethernet
service available only to objects belonging to the netif-ethernet
class.
Similarly, there exist classes for interface types like bridges, VLANs, bonds, or infinibands.
How do you interact with an interface like VLAN [which is really a virtual network interface that sits on top of an Ethernet device] that needs to be created first? For this, wicked defines factory interfaces, such as org.opensuse.Network.VLAN.Factory
. Such a factory interface offers a single function
that lets you create an interface of the requested type. These factory interfaces are attached to the /org/opensuse/Network/Interfaces
list node.
17.6.1.1 wicked
Architecture and Features #
The wicked
service comprises several parts as depicted in Figure 17.4, “wicked
architecture”.
Figure 17.4: wicked
architecture #
wicked
currently supports the following:
Configuration file back-ends to parse SUSE style
/etc/sysconfig/network
files.An internal configuration back-end to represent network interface configuration in XML.
Bring up and shutdown of “normal” network interfaces such as Ethernet or InfiniBand, VLAN, bridge, bonds, tun, tap, dummy, macvlan, macvtap, hsi, qeth, iucv, and wireless [currently limited to one wpa-psk/eap network] devices.
A built-in DHCPv4 client and a built-in DHCPv6 client.
The nanny daemon [enabled by default] helps to automatically bring up configured interfaces when the device is available [interface hotplugging] and set up the IP configuration when a link [carrier] is detected. See Section 17.6.1.3, “Nanny” for more information.
wicked
was implemented as a group of DBus services that are integrated with systemd. So the usualsystemctl
commands will apply towicked
.
17.6.1.2
Using wicked
#
On SUSE Linux Enterprise, wicked
runs by default. If you want to check what is currently enabled and whether it is running, call:
If wicked
is enabled, you will see something along these lines:
wicked.service - wicked managed network interfaces Loaded: loaded [/usr/lib/systemd/system/wicked.service; enabled] ...
In case something different is running [for example,
NetworkManager] and you want to switch to wicked
, first stop what is running and then enable wicked
:
systemctl is-active network && \ systemctl stop network systemctl enable --force wicked
This enables the wicked services, creates the network.service
to wicked.service
alias link, and starts the network at the next boot.
Starting the server process:
This starts wickedd
[the main server] and associated supplicants:
/usr/lib/wicked/bin/wickedd-auto4 --systemd --foreground /usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground /usr/lib/wicked/bin/wickedd-dhcp6 --systemd --foreground /usr/sbin/wickedd --systemd --foreground /usr/sbin/wickedd-nanny --systemd --foreground
Then bringing up the network:
Alternatively use the network.service
alias:
These commands are using
the default or system configuration sources as defined in /etc/wicked/client.xml
.
To enable debugging, set WICKED_DEBUG
in /etc/sysconfig/network/config
, for example:
Or, to omit some:
WICKED_DEBUG="all,-dbus,-objectmodel,-xpath,-xml"
Use the client utility to display interface information for all interfaces or the interface specified with IFNAME:
wicked show all wicked show IFNAME
In XML output:
wicked show-xml all wicked show-xml IFNAME
Bringing up one interface:
wicked ifup eth0 wicked ifup wlan0 ...
Because there is no configuration source specified, the wicked
client checks its default sources of configuration defined in /etc/wicked/client.xml
:
firmware:
iSCSI Boot Firmware Table [iBFT]compat:
ifcfg
files—implemented for compatibility
Whatever wicked
gets from those sources for a given interface is applied. The intended order of importance is firmware
, then compat
—this may be changed in the future.
For more information, see the wicked
man page.
17.6.1.3 Nanny #
Nanny is an event and policy driven daemon that is responsible for asynchronous or unsolicited scenarios such as hotplugging devices. Thus the nanny daemon helps with starting or restarting delayed or
temporarily gone devices. Nanny monitors device and link changes, and integrates new devices defined by the current policy set. Nanny continues to set up even if ifup
already exited because of specified timeout constraints.
By default, the nanny daemon is active on the system. It is enabled in the /etc/wicked/common.xml
configuration file:
... true
This setting causes ifup and ifreload to apply a policy with the effective configuration to the nanny daemon; then, nanny configures
wickedd
and thus ensures hotplug support. It waits in the background for events or changes [such as new devices or carrier on].
17.6.1.4 Bringing Up Multiple Interfaces #
For bonds and bridges, it may make sense to define the entire device topology in one file [ifcfg-bondX], and bring it up in one go. wicked then can bring up the whole configuration if you specify the top level interface names [of the bridge or bond]:
This command automatically sets up the bridge and its dependencies in the appropriate order without the need to list the dependencies [ports, etc.] separately.
To bring up multiple interfaces in one command:
wicked ifup bond0 br0 br1 br2
Or also all interfaces:
17.6.1.5 Using Tunnels with Wicked #
When you need to use tunnels with Wicked, the TUNNEL_DEVICE
is used for this. It permits to specify an optional device name to bind the
tunnel to the device. The tunneled packets will only be routed via this device.
For more information, refer to man 5 ifcfg-tunnel
.
17.6.1.6 Handling Incremental Changes #
With
wicked
, there is no need to actually take down an interface to reconfigure it [unless it is required by the kernel]. For example, to add another IP address or route to a statically configured network interface, add the IP address to the interface definition, and do another “ifup” operation. The server will try hard to update only those settings that have changed. This applies to link-level options such as the device MTU or the MAC address, and network-level
settings, such as addresses, routes, or even the address configuration mode [for example, when moving from a static configuration to DHCP].
Things get tricky of course with virtual interfaces combining several real devices such as bridges or bonds. For bonded devices, it is not possible to change certain parameters while the device is up. Doing that will result in an error.
However, what should still work, is the act of adding or removing the child devices of a bond or bridge, or choosing a bond's primary interface.
17.6.1.7 Wicked Extensions: Address Configuration #
wicked
is designed to be extensible with shell scripts. These
extensions can be defined in the config.xml
file.
Currently, several classes of extensions are supported:
link configuration: these are scripts responsible for setting up a device's link layer according to the configuration provided by the client, and for tearing it down again.
address configuration: these are scripts responsible for managing a device's address configuration. Usually address configuration and DHCP are managed by
wicked
itself, but can be implemented by means of extensions.firewall extension: these scripts can apply firewall rules.
Typically, extensions have a start and a stop command, an optional “pid file”, and a set of environment variables that get passed to the script.
To illustrate how this is supposed to work, look at a firewall extension defined in etc/server.xml
:
The extension is attached to the tag and defines
commands to execute for the actions of this interface. Further, the declaration can define and initialize environment variables passed to the actions.
17.6.1.8 Wicked Extensions: Configuration Files #
You can extend the handling of configuration files with scripts as well. For example, DNS updates from leases are ultimately handled by the extensions/resolver
script, with behavior configured in server.xml
:
When an update arrives in wickedd
, the system updater routines parse the lease and call the
appropriate commands [backup
, install
, etc.] in the resolver script. This in turn configures the DNS settings using /sbin/netconfig
, or by manually writing /etc/resolv.conf
as a fallback.
17.6.3 Testing the Configuration #
Before you write your configuration to the configuration files, you can test it. To set up a test configuration, use the ip
command. To test the connection, use the ping
command.
The command ip
changes the network configuration directly without saving it in the configuration file. Unless you enter your
configuration in the correct configuration files, the changed network configuration is lost on reboot.
Note: ifconfig
and route
Are Obsolete
The ifconfig
and route
tools are obsolete. Use ip
instead. ifconfig
, for example, limits interface names to 9 characters.
17.6.3.1 Configuring a Network Interface with ip
#
ip
is a tool to show and configure network devices, routing, policy routing, and tunnels.
ip
is a very complex
tool. Its common syntax is ip
OPTIONS
OBJECT
COMMAND
. You can work with the following objects:
link
This object represents a network device.
addressThis object represents the IP address of device.
neighborThis object represents an ARP or NDISC cache entry.
routeThis object represents the routing table entry.
ruleThis object represents a rule in the routing policy database.
maddressThis object represents a multicast address.
mrouteThis object represents a multicast routing cache entry.
tunnelThis object represents a tunnel over IP.
If no command is given, the default command is used [usually list
].
Change the state of a device with the command:
tux >
sudo
ip link set DEV_NAME
For example, to deactivate device eth0, enter
tux >
sudo
ip link set eth0 down
To activate it again, use
tux >
sudo
ip link set eth0 up
Tip: Disconnecting NIC Device
If you deactivate a device with
tux >
sudo
ip link set DEV_NAME down
it disables the network interface on a software level.
If you want to simulate losing the link as if the ethernet cable is unplugged or the connected switch is turned off, run
tux >
sudo
ip link set DEV_NAME carrier off
For example, while ip link set
DEV_NAME down
drops all routes using DEV_NAME,
ip link set DEV carrier
off
does not. Be aware that carrier off
requires support from the network device driver.
To connect the device back to the physical network, run
tux >
sudo
ip link set DEV_NAME carrier on
After activating a device, you can configure it. To set the IP address, use
tux >
sudo
ip addr add IP_ADDRESS + dev DEV_NAME
For example, to set the address of the interface eth0 to 192.168.12.154/30 with standard broadcast [option brd
], enter
tux >
sudo
ip addr add 192.168.12.154/30 brd + dev eth0
To have a working connection, you must also configure the default gateway. To set a gateway for your system, enter
tux >
sudo
ip route add default via gateway_ip_address
To display all devices, use
To display the running interfaces only, use
To print interface statistics for a device, enter
tux >
sudo
ip -s link ls DEV_NAME
To view additional useful information, specifically about virtual network devices, enter
tux >
sudo
ip -d link ls DEV_NAME
Moreover, to view network layer [IPv4, IPv6] addresses of your devices, enter
In the output, you can find information about MAC addresses of your devices. To show all routes, use
For more information about using ip
, enter ip
help
or see the man 8 ip
manual page. The help
option is also available for all ip
subcommands, such as:
Find the ip
manual in /usr/share/doc/packages/iproute2/ip-cref.pdf
.
17.6.3.2 Testing a Connection with ping #
The ping
command is the standard tool for testing whether a TCP/IP connection works. It uses the ICMP protocol to send a small data packet, ECHO_REQUEST datagram, to the destination host, requesting an immediate reply. If this works, ping
displays a message to that effect. This
indicates that the network link is functioning.
ping
does more than only test the function of the connection between two computers: it also provides some basic information about the quality of the connection. In Example 17.11, “Output of the Command ping”, you can see an example of the ping
output. The
second-to-last line contains information about the number of transmitted packets, packet loss, and total time of ping
running.
As the destination, you can use a host name or IP address, for example, ping
example.com
or ping
192.168.3.100
. The program sends packets until you press Ctrl–C.
If you only need to check the functionality of the connection, you can limit the number of the packets with the -c
option. For example
to limit ping to three packets, enter ping
-c 3 example.com
.
Example 17.11: Output of the Command ping #
ping -c 3 example.com PING example.com [192.168.3.100] 56[84] bytes of data. 64 bytes from example.com [192.168.3.100]: icmp_seq=1 ttl=49 time=188 ms 64 bytes from example.com [192.168.3.100]: icmp_seq=2 ttl=49 time=184 ms 64 bytes from example.com [192.168.3.100]: icmp_seq=3 ttl=49 time=183 ms --- example.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2007ms rtt min/avg/max/mdev = 183.417/185.447/188.259/2.052 ms
The default interval between two packets is one second. To change the
interval, ping provides the option -i
. For example, to increase the ping interval to ten seconds, enter ping
-i 10 example.com
.
In a system with multiple network devices, it is sometimes useful to send the ping through a specific interface address. To do so, use the -I
option with the name of the selected device, for example, ping
-I wlan1
example.com
.
For more options and information about using ping, enter ping
-h
or see the ping [8]
man page.
Tip: Pinging IPv6 Addresses
For IPv6 addresses use the ping6
command. Note, to ping link-local addresses, you must specify the interface with -I
. The following command works, if the address is reachable via eth2
:
ping6 -I eth2 fe80::117:21ff:feda:a425
17.6.4 Unit Files and Start-Up Scripts #
Apart from the configuration files described above, there are also systemd unit files and various scripts that load the network services while the machine is
booting. These are started when the system is switched to the multi-user.target
target. Some of these unit files and scripts are described in Some Unit Files and Start-Up Scripts for Network Programs. For more information about systemd
, see
Chapter 14, The systemd
Daemon and for more information about the systemd
targets, see the man page of systemd.special
[man
systemd.special
].
Some Unit Files and Start-Up Scripts for Network Programs #
network.target
network.target
is the systemd target for networking, but its mean depends on the settings provided by the system administrator.
For more information, see //www.freedesktop.org/wiki/Software/systemd/NetworkTarget/.
multi-user.target
multi-user.target
is the systemd target for a multiuser system with all required network services.
xinetd
Starts xinetd. xinetd can be used to make server services available on the system. For example, it can start vsftpd whenever an FTP connection is initiated.
rpcbind
Starts the rpcbind utility that converts RPC program numbers to universal addresses. It is needed for RPC services, such as an NFS server.
ypserv
Starts the NIS server.
ypbind
Starts the NIS client.
/etc/init.d/nfsserver
Starts the NFS server.
/etc/init.d/postfix
Controls the postfix process.