Implementing Quality Of Service in Vyatta router

Stephen Hemminger
Vyatta
Belmont, California
USA
[email protected]

1 Abstract
The challenge with managing Quality Of Service (QoS) configuration is how to present the available op-
tions to support what the user requirements, without becoming overwhelming. Vyatta software provides
an integrated command line interface similar to traditional routers. Configuration is done by defining
policies using a syntax that is similar to proprietary router operating systems, but keeps using the exist-
ing Linux traffic control infrastructure. For the initial implementation, two selections are available: a
fair-queue policy using the Stochastic Fair Queuing (SFQ) discipline, and a more complex traffic-shaper
based on the the Hierarchical Token Bucket (HTB) discipline.

2 Introduction
Traditionally routers have been built using special purpose hardware and large monolithic proprietary
software. With the advancement of commodity hardware and open source software, it is possible to
build an equivalent solution at a lower cost with increased flexibility and with no loss of performance.
Because the functionality is implemented in software, there is complete control over how packets are
processed. Linux routing is divided into forwarding using the routing tables, firewalling using netfilter,
QoS using traffic control and network device drivers.
QoS is router terminology for services which change how traffic is processed based on a set of
rules. In Linux, this is implemented by the traffic control subsystem[2] controlled by the tc utility in the
iproute2 command package.

There are several components to Linux traffic control system:

filter match packets based on contents (IP port, . . . ) or meta-data (incoming interface, length, etc.)
qdisc algorithms for packet servicing: FIFO, rate limiting, prioritization,
class traffic group in qdisc based on results of filter
actions allow for dropping and duplicating packets
Each of these is controlled by an option to the tc command, that is converted to a netlink[11] message to
the Linux kernel.

Traffic control can happen either when packets enter the system, ingress, or before packets are sent
to the hardware device driver, egress. If no other configuration is done, on output, Linux uses a priority
first-in-first-out (FIFO) queue. The priority is determined by the setting of the IP Type Of Service (TOS)
value. The default is fine for normal usage where there is no special need for reduced latency or traffic
prioritization. But when using a over crowded Internet link or using delay sensitive application such as
Voice Over IP (VOIP), more control is needed.
Determining the optimum QoS settings is a technical (and social) problem, which involves minor
reduction in service for some types of traffic in order to optimize for other types of traffic. Several Linux
queuing disciplines have been built to manage this: Class Based Queueing (CBQ)[5], Hierarchical Token
Bucket (HTB)[3] and Hierarchical Fair Service Curve (HFSC)[12]. Figuring out the proper policy is still
confusing, and beyond the patience of most users. There are several pre-packaged scripts of commands
such as wondershaper[9] or htb.init, that do this for the common configurations such as shared DSL
connection.
Another approach to configuration is taken in the Traffic Control Next Generation tcng[1] project.
Instead of individual commands, a clean and compact configuration language is compiled into traffic
control API. This provides much needed abstraction and make large configurations manageable. This
project is targeted towards simulation and traffic control offloading, and is no longer active.
The basic iproute commands for configuring Linux are terse and significantly different from the
configuration of a typical router. Some work was done to create an more integrated set of network
configuration tools, but this was never completed[7].
Other tools have also seen the need for a more friendly command line integration. The open source
routing tools: Quagga[4] and XORP[8]1 provide command line interfaces similar to proprietary routers.
These command interpreters are tightly coupled and limited mostly to routing control. Vyatta wanted
to provide a router administration environment that is integrated for all the networking components and
similar to the environment of commercial routers.

3 Vyatta Configuration System Architecture

On a Vyatta router, the system configuration is conceptually represented in a hierarchy, i.e., a tree of
configuration nodes. Figure 1 is an example showing a part of the configuration hierarchy.

interfaces firewall

ethernet eth0

address: duplex: speed:

10.1.0.1/24 auto auto

Figure 1: Configuration hierarchy for interface eth0

The portion of the configuration depicted in the figure specifies the settings for the network interface
eth0, including its IP address, duplex, and speed.
The Vyatta configuration system maintains and manipulates the hierarchical configuration according
to user commands and interacts with the underlying functional subsystems (e.g., kernel, routing engine,
etc.) to effect configuration changes. Figure 2 shows the high-level architecture of the configuration
system.
In the next sections, we first present more details of the hierarchical configuration, and then we
will discuss the main components: configuration templates, configuration front-end, and configuration
backend.

3.1 Hierarchical configuration

There are three different types of configuration node in the example in Figure 1.
1
The initial versions of Vyatta software used XORP but it was abandoned because of performance and the dependence on
C++ for extensibility
 Configuration
templates
Configuration
front-end

User FusionCLI
Configuration
backend
Web GUI

Routing ……
Kernel
engine
Actual subsystems

Figure 2: High-level architecture of the Vyatta configuration system

1. Leaf node: A leaf node is a "terminal" node of the configuration hierarchy. In the example,
address, duplex, and speed are leaf nodes. A leaf node can be assigned a value (e.g., "auto"
for both duplex and speed) or multiple values (e.g., there can be multiple IP addresses assigned
to the address node).

2. Non-leaf node: A non-leaf node has child nodes under it in the configuration hierarchy. The
interfaces node is a non-leaf node in the example.

3. Tag node: A tag node is a special non-leaf node in that it can be assigned values called "tags"
(to distinguish them from values for leaf nodes). In the example, the ethernet node is a tag
node that has one tag "eth0". Multiple tags can be assigned to a tag node, for example, "eth1" for
ethernet, and each tag will have its own subtree in the configuration hierarchy.

At any time, the configuration system maintains a "running configuration" conceptually similar to
the hierarchy in Figure 1. This hierarchy represents all the system settings that have been configured
for the active subsystems. Figure 3 shows the hierarchy of the running configuration corresponding to
the previous example. The running configuration tree in the figure is presented as a filesystem directory

running-config/
interfaces/
ethernet/
eth0/
address/
node.val
duplex/
node.val
speed/
node.val
...
...
...

Figure 3: Configuration template hierarchy

structure, which is one possible implementation. For simplicity, in the following discussion we will
assume such an implementation is used. Each "directory" in the hierarchy corresponds to a configuration
node, and each leaf node has a node.val file, which contains the value(s) of the node, for example, the
node.val for speed contains the string "auto". Note that tag nodes are a special case, for example,
ethernet is a tag node, and its "tag" eth0 is represented as a subdirectory.
On the other hand, note that the running configuration only contains a subset of all available config-
uration, for example, if a user does not configure the firewall subsystem, then the running configuration
will not contain the firewall node and its child nodes. Therefore, in addition to the running configu-
ration, the Vyatta configuration system also maintains a "tree" of configuration templates that represent
all available configuration nodes.

3.2 Configuration templates

Configuration templates are a set of text files organized into a tree, which represents all available config-
uration nodes for the Vyatta system. Figure 4 shows the hierarchy of the configuration templates for the
nodes in the previous example.

templates/
interfaces/
node.def
ethernet/
node.def
node.tag/
address/
node.def
duplex/
node.def
speed/
node.def
...
...
...

Figure 4: Configuration template hierarchy

Note that the tree is presented as a filesystem directory structure, which is one possible implementa-
tion of the template hierarchy. For simplicity, in the following discussion we will assume such an imple-
mentation is used. Each "directory" represents a configuration node in the hierarchy, and the node.def
file within the directory is the configuration template for the node. The node.tag directory is an ex-
ception and is present under a tag node. For example, as mentioned earlier the ethernet node is a tag
node, and therefore, the ethernet directory contains a node.tag sub-directory.
The configuration template node.def for a node specifies the details of the node. A node.def
file contains a set of "fields", and the available fields can be divided into three categories. Below is a
brief description of some commonly-used fields.
1. Node type and value: These include the following fields: tag (whether the node is a tag node),
multi (whether the leaf node can have multiple values), and type (data type of the leaf node’s
value or the tag node’s tag).
2. Help information: Some fields provide help information for user interfaces (e.g., CLI auto-completion):
help and allowed.
3. Configuration actions: A node’s template needs to tell the configuration system what actions to
take when the node is configured, removed, changed, etc. These fields include: syntax (how to
validate the node’s value), create, update, and delete (what to do when the node is added,
changed, and deleted, respectively).
 As an example, Figure 5 shows the simplified template for the speed node. From the directory
type: txt
help: Set the speed for this interface
syntax: $VAR(@) in "auto", "10", "100", "1000", "2500", "10000"
update:
if [ x$VAR(@) != xauto ]; then
ethtool -s $VAR(../@) speed $VAR(@) duplex $VAR(../duplex/@) autoneg off
else
ethtool -s $VAR(../@) autoneg on
fi
delete: ethtool -s $VAR(../@) autoneg on

Figure 5: Configuration template for the speed node

structure, we already know that the node is a leaf node. The absence of the multi field in the template
indicates that the node takes a single value, and the type field specifies that the data type of the node’s
value is "text". The help string "Set the speed for this interface" will be shown when a user requests help
for the node (for example, attempting to auto-complete the node). The syntax field specifies the list of
valid values for the node so that an error can be generated when a user attempts to enter any other value.
(The syntax field also supports regular expression and many other operators not presented here.)
The update and delete fields specify the "actions" to take when a user updates and deletes the
node, respectively. Note that the actions are specified as a "shell script", i.e., the configuration system
basically takes the whole string and executes it using a shell, with a few exceptions. One such exception
is that the configuration system replaces variable references (denoted by the $VAR() notation) in the
string with the actual values from the configuration.
In this template, $VAR(@) refers to the value of "this" node, i.e., the speed node; $VAR(../@)
refers to the value of the parent node, i.e., ethernet (which is a tag node, so the value actually refers to
the tag); and $VAR(../duplex/@) refers to the value of the sibling node duplex. Therefore, using
the previous configuration example (Figure 1), the configuration system will replace these references
with the strings "auto", "eth0", and "auto", respectively, before executing the whole string with a shell.
Due to space constraint, the details of variable references are not presented here.

3.3 Configuration front-end

The Vyatta configuration system provides two different configuration front-ends for user interaction, the
Vyatta FusionCLI™ and the Vyatta Web GUI. The Web GUI is currently under extensive development,
so we will focus on the FusionCLI. The Vyatta FusionCLI is a command-line interface (CLI) that pro-
vides help text and auto-completion features for all Vyatta commands while at the same time provides
a regular Unix shell environment. In other words, a user can issue Vyatta configuration commands and
use regular Unix commands from the same CLI.

User FusionCLI
bash Configuration
backend
Vyatta-specific changes
Help text Programmable
Auto-completion completion

Vyatta completion scripts

Configuration
templates

Figure 6: Overview of Vyatta FusionCLI

 Figure 6 provides an overview of Vyatta FusionCLI. The FusionCLI implementation is based on the
GNU Bourne Again Shell (bash). The help text and auto-completion are implemented using bash’s
programmable completion feature [6] along with a set of completion environment scripts. Some mod-
ifications to bash were also performed to add Vyatta-specific functionality. For example, the bash
programmable completion mechanism allows developers to define auto-completion starting at the sec-
ond word on the command line. We modified the mechanism to provide help and completion on the first
word so that they would work for the Vyatta commands.
The Vyatta configuration commands include set (for adding a new node or changing an existing
node), delete (for removing an existing node), and commit (for committing a set of changes made us-
ing set and delete). For example, to configure the settings in Figure 1, a user can issue the following
sequence of commands.

set interfaces ethernet eth0 address 10.1.0.1/24

set interfaces ethernet eth0 duplex auto
set interfaces ethernet eth0 speed auto
commit

Note that when a set command is issued, only the validation (e.g., syntax and type) specified in
the corresponding node’s template is performed. The "actions" (e.g., update and delete) are only
performed when the commit command is issued. The validation and actions are performed by the
configuration backend, discussed in the next section.
At any point, the user can hit the "Tab" key for auto-completion or the "?" key to display the help
text for the "current" node. The FusionCLI obtains the help text and auto-completion information from
the configuration templates described in the previous section.

3.4 Configuration backend

The configuration backend maintains and manipulates the running configuration according to commands
from users (issued through the configuration front-end), and when the running configuration is changed,
the backend interacts with the actual subsystems and effects the changes.
The backend includes a set of programs, libraries, and scripts that implement the configuration com-
mands set, delete, commit, etc. When a command is issued, the backend parses the configuration
templates for the relevant nodes, extracts the validation and actual actions, and performs the appropriate
validation or action.
For example, suppose the user issues the following commands.

set interfaces ethernet eth0 speed auto

commit

The backend behaves as follows.

1. When the set command is issued, the backend parses the template for the speed node (see
Figure 5) and finds that the data type of the node value is "text". It verifies that the user-entered
value "auto" is of the correct type.

2. The template also specifies syntax with a list of valid values. The backend verifies that "auto" is
one of them.

3. The set is deemed successful, so the backend records this change in a "working" area but does
not actually change the running configuration.

4. When the commit is issued, the backend iterates through all the changes recorded in the working
area so far and, for each change, carries out the actions specified in the template for the changed
node.
 5. In this particular example, the backend extracts the update field from the template of the speed
node (since the node’s value is set by the user), replaces all the variable references in the string
as discussed earlier, and executes the string as a shell command.

6. In this case the ethtool program is run, and it changes the speed setting on the actual network
interface eth0, turning on auto-negotiation.

In addition to supporting individual commands, the backend also allows a user to save the running
configuration into a configuration file that can be copied elsewhere, for example. The user can then load
such a file later to restore the saved configuration. The format of Vyatta configuration files is a textual
representation of the hierarchical, as shown in Figure 7.
interfaces {
ethernet eth0 {
address 10.1.0.1/24
duplex auto
speed auto
...
}
...
}
...

Figure 7: Configuration file format

To summarize, the Vyatta configuration system makes our software easily extensible, even by ex-
ternal contributors. Integrating an external project into a Vyatta system is often as simple as defining a
configuration hierarchy for the new functionality and then writing the corresponding templates. The use
of text-based templates eliminates the need for compilation and even allows changes at run time. The
ability to specify shell-based commands for configuration actions in the templates further simplifies the
integration effort.

4 QoS Architecture
When adding a new abstraction layer, the underlying infrastructure can be hidden or exposed. User’s
wanted a way to configure QoS to provide better service for Voice Over IP (VoIP) traffic. Like firewall
rules, the design is based on qos-policy templates. Two types of policy were implemented initially.

4.1 Fair Queue

A simple policy fair-queue was implemented first. This policy provides an interface to the Stochastic
Fair Queue[10], a queueing discipline that divides traffic into random groups and does not let any one
group monopolize the flow. SFQ is a good choice for a router when many flows are competing for a
single congested link.

Setting up fair-queue is done by issuing three commands in configuration mode.

# set qos-policy fair-queue fq

# set interfaces ethernet eth0 qos-policy out fq
# commit
 templates/
interfaces
ethernet
node.tag
qos-policy
node.def
out
node.def
qos-policy
fair-queue
node.def
node.tag
queue-limit
node.def

Figure 8: template file system hierarchy

The first command defines a policy and uses all the default values. The second statement applies that
policy to the first Ethernet device(eth0). The last one makes the change happen.
This command sequence is created by the directory trees shown in Figure 8.
Theqos-policy/fair-queue/node.def file allows a text value (with some restrictions), and
invokes a Perl script to to do the real work of adding, deleting or changing a policy 2 . The variable names
reflect the contents of the current node $VAR(@) and the parent $VAR(.) (“fair-queue”).

tag:
type: txt
help: Set fair queueing policy
syntax:expression: pattern $VAR(@) "^[[:alnum:]][-_[:alnum:]]*$"
create: vyatta-qos --create-policy $VAR(.) $VAR(@)
delete: vyatta-qos --delete-policy $VAR(@)
update: vyatta-qos --update-policy $VAR(.) $VAR(@)

QoS configuration also needs an additional template for attaching a policy to an interface interfaces/ethernet/
In this template, the grandparent of the node $VAR(../../@) refers to the name of the ethernet device
(eth0). For now, the parent $VAR(.) is always “out” but eventually the same template can be copied for
use on “in”.

type: txt
help: Set output QOS policy for specified ethernet interface
allowed: vyatta-qos --list-policy
update: vyatta-qos --update-interface $VAR(../../@) $VAR(.) $VAR(@)
delete: vyatta-qos --delete-interface $VAR(../../@) $VAR(.)

The templates actions can be implemented in any language. For simple things, a one line shell
command is used. For example:

show system kernel-messages

just runs the standard “dmesg” command. But most configuration commands have to deal with configu-
ration state and interacting with other programs therefore the Perl scripting language is used.

2
Examples are simplified for clarity
my %policies = (
’traffic-shaper’ => "VyattaQosTrafficShaper",
’fair-queue’ => "VyattaQosFairQueue",
);

sub make_policy {
my ($config, $type, $name) = @_;
my $class = $policies{$type};

# This means template exists but we don’t know what it is.

defined $class or die "Unknown policy type $type";

my $location = "$class.pm";
require $location;

$config->setLevel("qos-policy $type $name");

return $class->new($config, $name);
}

sub update_interface {
my ($interface, $direction, $name ) = @_;
my $config = new VyattaConfig;

$config->setLevel(’qos-policy’);
foreach my $type ( $config->listNodes() ) {
my $shaper = make_policy($config, $type, $name);

delete_interface($interface, $direction);

my $out;
open $out, "|-" or exec qw:sudo /sbin/tc -batch -:;

$shaper->commands($out, $interface);
close $out;
}
}
}

Figure 9: vyatta-qos.pl code for policy creation

The vyatta-qos.pl is the QoS script for converting the configuration state to commands. The
typical call to update the interfaces goes has a generic and then a policy specific portion. Figure 4.1 is
the object factory factory pattern to create a policy specific mechanism, VyattaQosFairQueue for this
example; followed by calling policy to produce a list of tc commands.
The real policy specific work is done in the VyattQosFairQueue Perl module. The new method
creates a new data structure and stores the contents of the configured variable. The commands method
generates the commands to tc to create the configured policy.
my %fields = (
_limit => undef,
);

sub new {
my ( $that, $config ) = @_;
my $class = ref($that) || $that;
my $self = {%fields};

$self->{_limit} = $config->returnValue(’queue-limit’);
return bless $self, $class;
}

sub commands {
my ( $self, $out, $dev ) = @_;

print {$out} "qdisc add dev $dev root sfq";

print {$out} " limit $self->{_limit}"
if ( defined $self->{_limit} );
print "\n";
}

Figure 10: VyattaQosFairQueue Perl module

4.2 Traffic Shaper
Although fair-queue is a useful policy, the configuration is more of a toy example. The traffic-shaper
is more versatile. This policy encapsulates the Hierarchical Token Bucket (HTB) queuing discipline
allowing traffic groups and shaping this traffic at different rates. The template for the top level node is
almost the same. The difference is that the traffic shaper has many more configuration possibilities.
qos-policy {
traffic-shaper myshaper {
bandwidth 1mbit
class 3 {
bandwidth 80%
burst 15k
match icmp {
ip {
protocol icmp
}
}
match mindelay {
ip {
dscp 0x10
}
}
priority 1
queue-type drop-tail
}
class 4 {
bandwidth 40%
burst 15k
match bt {
ip {
destination {
port 6881
}
}
}
priority 7
queue-type random-detect
}
default {
bandwidth 90%
burst 15k
ceiling 90%
priority 2
queue-type fair-queue
}
}
}

Figure 11: Traffic-shaper configuration

Traffic is grouped into classes based on matching rules. If a packet matches none of the defined
classes, it goes obeys the specification of the default class. Each class can have a different reserved
bandwidth and a maximum bandwidth ceiling and underlying queue discipline. The sample configuration
(Figure 11) shows how traffic is broken up into classes defined by match rules and assigned bandwidth
values.
qdisc add dev eth0 root handle 1: htb default 5
class add dev eth0 parent 1: classid 1:1 htb rate 1000000
class add dev eth0 parent 1:1 classid 1:5 htb rate 900000 \
ceil 900000 burst 15k prio 2
qdisc add dev eth0 parent 1:5 sfq
class add dev eth0 parent 1:1 classid 1:3 htb rate 800000 \
burst 15k prio 1
qdisc add dev eth0 parent 1:3 pfifo
filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \
match ip dsfield 0 0xff classid 1:3
filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \
match ip protocol 1 0xff classid 1:3
class add dev eth0 parent 1:1 classid 1:4 htb rate 400000 \
burst 15k prio 7
qdisc add dev eth0 parent 1:4 red \
limit 200000 min 8333 max 25000 avpkt 1000 burst 13 \
probability 0.02 bandwidth 400 ecn
filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \
match ip dport 6881 0xffff classid 1:4

Figure 12: Traffic-shaper tc output

Normally, the tc rules are sent directly to the kernel but using debug hooks it is possible to capture
the corresponding tc commands are shown in Figure 12. Each class defined corresponds to a class in the
HTB queue discipline, and each class can have a different underlying queue type.
Most of these values have reasonable defaults and the interface tries to be as smart as possible. The
auto bandwidth value queries ethtool to find the speed of the underlying interface, and individual class
bandwidth values can be specified as a percent of the overall bandwidth.

4.3 Matching logical expressions

One not obvious part of the matching rules is the ability to handle boolean combinations. This expression
will match connections whose source port is 20 and the destination port is 21.
class ftp {
bandwidth 100
match ftp {
ip {
source {
port 20
}
destination {
port 21
}
}
}
}
 Or the user may want to match either source port 20 or destination port 21. This is done by defining
two matches in the same class:

class ftp {
bandwidth 100
match ftp1 {
ip {
source {
port 20
}
}
match ftp2 {
destination {
port 21
}
}
}
}
5 Error handling
The configuration template system is designed to avoid syntax errors by providing help and a list of
options. There are two forms of help, the first is shown when looking for the correct option using tab for
completion. This uses the help tag of each possibility to provide more information.

# set qos-policy traffic-shaper myshaper class 3 <tab><tab>

Possible completions:
bandwidth Set the bandwidth used for this class
burst Set the burst size for this class (default: 15kb)
ceiling Set the bandwidth limit for this class
description Set description for this traffic class
match Set class matching rule name
priority Set priority for usage of excess bandwidth
queue-limit Set maximum queue size (packets)
queue-type Set the queue type for this class
set-dscp Change the Differentiated Services field

If the user is looking for the correct value for a configuration field, the comp_help field in the node
definition is displayed.

# set qos-policy traffic-shaper myshaper class 3 bandwidth <tab><tab>

Allowed values:
<number> Bandwidth in Kbps
<number>% Percentage of overall rate (default 100%)
<number><suffix> Value with scaling suffix
bits per sec (kbit, mbit, gbit)
bytes per sec (kbps, mbps, gbps)

For many configuration fields only a certain set of values is possible. This handled using the allowed
field; the content of this field must be an embedded shell script that outputs the list of all values. This
approach allows the list to be dynamically generated based on the state of the system. When matching
IP protocols any value contained in /etc/protocols is allowed so the allowed rule is:

allowed: awk ’
/^#/ { next }
{ printf "%s ", $1 }’ </etc/protocols

5.1 Syntax checking

Additional restrictions on the contents of a node can also be done by using the syntax field. This field
has some additional matching rules and can print a message if the syntax does match.

syntax:expression: pattern $VAR(@) "^[[:alnum:]][-_[:alnum:]]*$"

syntax:expression: $VAR(@) in "fair-queue", "priority"

syntax:expression: exec "vyatta-qos-util --rate $VAR(@)"

The first one uses regular expression pattern matching to allow any name starting with a letter or
digit followed by more letters, digits, minus sign or underline. Next example is how to allow any of a
set of choices. An external program can also be used to validate a field that has other possibilities or
restrictions. In the Qos case, the vyatta-qos-util Perl script contains code to do syntax checking for the
rate, burst and other special arguments used in the tc commands.
5.2 Semantic checking
With QoS, like most configuration there are additional restrictions that can not be checked until the whole
configuration is known. These are done during the commit process. The program or script that is done
during the commit cycle can print an error message and exit with a failed error code, and this blocks the
commit from taking effect. The user can then go back and fix the problem.

# commit
qos-policy traffic-shaper myshaper default bandwidth not defined
Commit failed
# set qos-policy traffic-shaper myshaper default bandwidth 90%
# commit

6 Problem areas
The CLI template system does expose some problems, that require workarounds. These occur because
the configuration evaluation system is unaware of any dependencies between different areas of the con-
figuration.

6.1 Initialization ordering

During system initialization some areas need to be configured before others. For example, qos-policy
need to be loaded from the configuration file before they can be applied to the actual Ethernet interfaces.
The configuration is handled by a special table in the VyattaConfigLoad.pm Perl module:

my %config_rank = (
’qos-policy’ => 1100,
’firewall’ => 1020,
’service nat’ => 1010,
’system host-name’ => 1005,
’interfaces’ => 1000,
’interfaces bridge’ => 990,
’interfaces ethernet’ => 980,
’interfaces tunnel’ => 910,
. . .

6.2 Nested update

Changes to a QoS policy cause all the interfaces using that policy need to be updated. There is no update
propagation mechanism, to workaround this templates can use the end tag. Since the begin and end tags
are always run, this allows programmatic update actions. The top-level qos-policy/node.def file
uses a finalizing end to walk through all the qos-policy configuration and find changes.
For example, the change to an existing policy:

# set qos-policy traffic-shaper myshaper default bandwidth 100

# commit

Would update the node qos-policy/node.tag/traffic-shaper/node.tag/default/bandwidth

but does not cause any update event to occur on qos-policy/node.tag/traffic-shaper/node.def.
But the end rule in the qos-policy/node.def template runs a script that traverses all the configured
policies and updates any changed parameters.
6.3 Automatic speed detection
In the QoS system, one of the features is the ability to define a policy which uses the speed setting of
the Ethernet device as the base rate. But some network hardware doesn’t support the necessary ethtool
interface and the speed is not known until the device is online. The current behavior is to just fallback
to 100Mbit if speed information is not available. There is a question about whether this is the best and
safest choice, so other alternatives are being evaluated.

7 Conclusion
FusionCLI is a flexible way to integrate Linux router functions into a complete package that is familiar
to network router administrators. The use of templates and configuration infrastructure make QoS con-
figuration simpler. The CLI can be used to manage any router function, and Vyatta hopes to make it
accessible for community by documenting and explaining how it works.

8 Acknowledgments
Robert Bays did the initial design for the CLI and QoS. Arkady Rabinov did the initial implementation of
the configuration backend. An-Cheng Huang did most of the FusionCLI implementation and contributed
the section on the Vyatta configuration system architecture.
References
[1] Werner Almesberger. Traffic Control - Next Generation Reference Manual, 2003.

[2] Werner Almesberger and Epfl Ica. Linux network traffic control - implementation overview, 1999.

[3] Martin Devera. HTB Linux queuing discipline manual - user guide.

[4] Kunihiro Ishiguro et al. Quagga, A routing software package for TCP/IP networks, 2006.

[5] S Floyd and V Jacobson. Link-share and resource management models for packet networks.
IEEE/ACM Trans. Networking, 1995.

[6] Free Software Foundation. The GNU Bash Reference Manual, 2006.

[7] Thomas Graf. New network configuration architecture - packet classification and scheduling. In
Netconf, 2005.

[8] Mark Handley, Orion Hodson, and Eddie Kohler. Xorp: An open platform for network research. In
ACM SIGCOMM Computer Communication Review, pages 53–57, 2002.

[9] Bert Hubert. The wonder shaper, 2002.

[10] Paul E. Mckenney. Stochastic fairness queuing, 1990.

[11] J. Salim, H. Khosravi, A. Kleen, and A. Kuznetsov. Rfc 3549 linux netlink as an ip services
protocol, 2003.

[12] Ion Stoica, Hui Zhang, and T S Eugene Ng. A hierarchical fair service curve algorithm for. In
Proceedings of SIGCOMM, 1997.