Vyatta-Implementing Quality of Service in Vyatta Router

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 options 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 existing 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: 10.1.0.1/24

duplex: auto

speed: 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

Kernel

Routing 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 configuration, 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 configuration, 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 configuration 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 implementation of the template hierarchy. For simplicity, in the following discussion we will assume such an implementation 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 exception 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 provides 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.




FusionCLI

User

bash

Help text Auto-completion

Configuration backend

Vyatta-specific changes Programmable completion

Vyatta completion scripts

Figure 6: Overview of Vyatta FusionCLI

Configuration templates

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 modifications 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 second 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 using 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 commands 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 external 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(@) create: vyatta-qos --create-policy delete: vyatta-qos --delete-policy update: vyatta-qos --update-policy

"^[[:alnum:]][-_[:alnum:]]*$" $VAR(.) $VAR(@) $VAR(@) $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 configuration 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 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 Allowed values: Bandwidth in Kbps % Percentage of overall rate (default 100%) 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 }’
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 configuration.

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’ ’firewall’ ’service nat’ ’system host-name’ ’interfaces’ ’interfaces bridge’ ’interfaces ethernet’ ’interfaces tunnel’ . . .

6.2

=> => => => => => => =>

1100, 1020, 1010, 1005, 1000, 990, 980, 910,

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