Which of the following files can be used to configure a Linux system to be an IPv6 router

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 usual systemctl commands will apply to wicked.

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:

1. firmware: iSCSI Boot Firmware Table (iBFT)

2. 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.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.

This object represents the IP address of device.

This object represents an ARP or NDISC cache entry.

This object represents the routing table entry.

This object represents a rule in the routing policy database.

This object represents a multicast address.

This object represents a multicast routing cache entry.

This 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