Once a network interface is configured, setting up this traffic limitation is achieved by running wondershaper interface download_rate upload_rate. The interface can be eth0 or ppp0 for example, and both rates are expressed in kilobits per second. The wondershaper remove interface command disables traffic control on the specified interface.
For an Ethernet connection, this script is best called right after the interface is configured. This is done by adding up and down directives to the /etc/network/interfaces file allowing declared commands to be run, respectively, after the interface is configured and before it is deconfigured. For example:
Example 10.9. Changes in the /etc/network/interfaces file
iface eth0 inet dhcp
up /sbin/wondershaper eth0 500 100
down /sbin/wondershaper remove eth0
In the PPP case, creating a script that calls wondershaper in /etc/ppp/ip-up.d/ will enable traffic control as soon as the connection is up.
GOING FURTHER Optimal configuration
The /usr/share/doc/wondershaper/README.Debian.gz file describes, in some detail, the configuration method recommended by the package maintainer. In particular, it advises measuring the download and upload speeds so as to best evaluate real limits.
10.3.2.2. Standard Configuration
Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the ToS field (Type of Service) of this packet; modifying this field is enough to take advantage of the scheduling features. There are five possible values:
Normal-Service (0);
Minimize-Cost (2);
Maximize-Reliability (4);
Maximize-Throughput (8);
Minimize-Delay (16).
The ToS field can be set by applications that generate IP packets, or modified on the fly by netfilter. The following rules are sufficient to increase responsiveness for a server's SSH service:
iptables -t mangle -A PREROUTING -p tcp --sport ssh -j TOS --set-tos Minimize-Delay
iptables -t mangle -A PREROUTING -p tcp --dport ssh -j TOS --set-tos Minimize-Delay
10.4. Dynamic Routing
The reference tool for dynamic routing is currently quagga, from the similarly-named package; it used to be zebra until development of the latter stopped. However, quagga kept the names of the programs for compatibility reasons which explains the zebra commands below.
BACK TO BASICS Dynamic routing
Dynamic routing allows routers to adjust, in real time, the paths used for transmitting IP packets. Each protocol involves its own method of defining routes (shortest path, use routes advertized by peers, and so on).
In the Linux kernel, a route links a network device to a set of machines that can be reached through this device. The route command defines new routes and displays existing ones.
Quagga is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon. The zebra daemon collects information from other daemons and handles static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, and ripngd.
Daemons are enabled by editing the /etc/quagga/daemons file and creating the appropriate configuration file in /etc/quagga/; this configuration file must be named after the daemon, with a .conf extension, and belong to the quagga user and the quaggavty group, in order for the /etc/init.d/quagga script to invoke the daemon.
The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but the quagga-doc provides ample explanation in the form of an info file. The same contents may be more easily browsed as HTML on the Quagga website:
→ http://www.quagga.net/docs/docs-info.php
In addition, the syntax is very close to a standard router's configuration interface, and network administrators will adapt quickly to quagga.
IN PRACTICE OPSF, BGP or RIP?
OSPF is generally the best protocol to use for dynamic routing on private networks, but BGP is more common for Internet-wide routing. RIP is rather ancient, and hardly used anymore.
10.5. IPv6
IPv6, successor to IPv4, is a new version of the IP protocol designed to fix its flaws, most notably the scarcity of available IP addresses. This protocol handles the network layer; its purpose is to provide a way to address machines, to convey data to their intended destination, and to handle data fragmentation if needed (in other words, to split packets into chunks with a size that depends on the network links to be used on the path and to reassemble the chunks in their proper order on arrival).
Debian kernels include IPv6 handling in the core kernel (which was not always the case; the ipv6 module used to be optional). Basic tools such as ping and traceroute have their IPv6 equivalents in ping6 and traceroute6, available respectively in the iputils-ping and iputils-tracepath packages.
The IPv6 network is configured similarly to IPv4, in /etc/network/interfaces. But if you want that network to be globally available, you must ensure that you have an IPv6-capable router relaying traffic to the global IPv6 network.
CULTURE The 6bone
During the experimental phase of the IPv6 protocol, a global network infrastructure was set up to facilitate testing of the new protocol. That network was known as the 6bone, a contraction of the 6 in IPv6 and the network backbone. This 6bone officially disappeared on the 6th of June, 2006 (note the omnipresence of the number 6), but the nickname is still used to refer to that part of the Internet capable of handling IPv6.
Example 10.10. Example of IPv6 configuration
iface eth0 inet6 static
address 3ffe:ffff:1234:5::1:1
netmask 64
# Disabling auto-configuration
# up echo 0 >/proc/sys/net/ipv6/conf/all/autoconf
# The router is auto-configured and has no fixed address
# (/proc/sys/net/ipv6/conf/all/accept_ra). If it had:
# gateway 3ffe:ffff:1234:5::1
If a native IPv6 connection is not available, the fallback method is to use a tunnel over IPv4. Freenet6 is one (free) provider of such tunnels:
→ http://www.freenet6.net/
To use a Freenet6 tunnel, you need to register on the website, then install the tspc package and configure the tunnel. This requires editing the /etc/tsp/tspc.conf file: userid and password lines received by e-mail should be added, and server should be replaced with broker.freenet6.net.
IPv6 connectivity is proposed to all machines on a local network by adding the three following directives to the /etc/tsp/tspc.conf file (assuming the local network is connected to the eth0 interface):