Implementing Quality Of Service in Vyatta router

Stephen Hemminger Vyatta Belmont, California USA



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.



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 class algorithms for packet servicing: FIFO, rate limiting, prioritization, 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

we first present more details of the hierarchical configuration. In the next sections. The basic iproute commands for configuring Linux are terse and significantly different from the configuration of a typical router. etc. But when using a over crowded Internet link or using delay sensitive application such as Voice Over IP (VOIP). more control is needed.g. the system configuration is conceptually represented in a hierarchy.prioritization. Instead of individual commands. The open source routing tools: Quagga[4] and XORP[8]1 provide command line interfaces similar to proprietary routers.) to effect configuration changes. that do this for the common configurations such as shared DSL connection. This project is targeted towards simulation and traffic control offloading. and then we will discuss the main components: configuration templates. including its IP address. Hierarchical Token Bucket (HTB)[3] and Hierarchical Fair Service Curve (HFSC)[12]. routing engine. Some work was done to create an more integrated set of network configuration tools. but this was never completed[7]. Another approach to configuration is taken in the Traffic Control Next Generation tcng[1] project. Figure 1 is an example showing a part of the configuration hierarchy.0. Several Linux queuing disciplines have been built to manage this: Class Based Queueing (CBQ)[5].1/24 duplex: auto speed: auto firewall Figure 1: Configuration hierarchy for interface eth0 The portion of the configuration depicted in the figure specifies the settings for the network interface eth0. Figure 2 shows the high-level architecture of the configuration system.. and configuration backend.init. and is no longer active. The Vyatta configuration system maintains and manipulates the hierarchical configuration according to user commands and interacts with the underlying functional subsystems (e.1. These command interpreters are tightly coupled and limited mostly to routing control. This provides much needed abstraction and make large configurations manageable. a tree of configuration nodes. kernel. 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. There are several pre-packaged scripts of commands such as wondershaper[9] or htb. configuration front-end. 3 Vyatta Configuration System Architecture On a Vyatta router. a clean and compact configuration language is compiled into traffic control API.1 Hierarchical configuration There are three different types of configuration node in the example in Figure 1. and speed. Other tools have also seen the need for a more friendly command line integration. 3. interfaces ethernet eth0 address: 10. Vyatta wanted to provide a router administration environment that is integrated for all the networking components and similar to the environment of commercial routers. and beyond the patience of most users. Figuring out the proper policy is still confusing..e. duplex. The initial versions of Vyatta software used XORP but it was abandoned because of performance and the dependence on C++ for extensibility 1 . i.

In the example.g. The interfaces node is a non-leaf node in the example. Non-leaf node: A non-leaf node has child nodes under it in the configuration hierarchy.. duplex. Each "directory" in the hierarchy corresponds to a configuration . address.Configuration front-end User FusionCLI Web GUI Configuration templates Configuration backend Kernel Routing engine …… Actual subsystems Figure 2: High-level architecture of the Vyatta configuration system 1. A leaf node can be assigned a value (e. For simplicity.. This hierarchy represents all the system settings that have been configured for the active subsystems. and speed are leaf nodes.... for example.val . in the following discussion we will assume such an implementation is used. "auto" for both duplex and speed) or multiple values (e. Figure 3: Configuration template hierarchy structure.. 3. Figure 3 shows the hierarchy of the running configuration corresponding to the previous example. which is one possible implementation. . At any time. "eth1" for ethernet. 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). there can be multiple IP addresses assigned to the address node).val duplex/ node. . the ethernet node is a tag node that has one tag "eth0".. In the example. and each tag will have its own subtree in the configuration hierarchy. The running configuration tree in the figure is presented as a filesystem directory running-config/ interfaces/ ethernet/ eth0/ address/ node. 2. Multiple tags can be assigned to a tag node. Leaf node: A leaf node is a "terminal" node of the configuration hierarchy. the configuration system maintains a "running configuration" conceptually similar to the hierarchy in Figure 1.val speed/ node..g.

and the node. if a user does not configure the firewall subsystem. changed. Each "directory" represents a configuration node in the hierarchy. 3. ethernet is a tag node. Below is a brief description of some commonly-used fields. ..2 Configuration templates Configuration templates are a set of text files organized into a tree. respectively). update. 3. etc. the ethernet directory contains a node. templates/ interfaces/ node.node. Figure 4: Configuration template hierarchy Note that the tree is presented as a filesystem directory structure.def file contains a set of "fields". On the other hand. the node.tag sub-directory. The configuration template node. 2.. for example. These fields include: syntax (how to validate the node’s value). Figure 4 shows the hierarchy of the configuration templates for the nodes in the previous example. which represents all available configuration nodes for the Vyatta system.tag directory is an exception and is present under a tag node. then the running configuration will not contain the firewall node and its child nodes. Therefore. and each leaf node has a node. removed. For simplicity.. which contains the value(s) of the node. Configuration actions: A node’s template needs to tell the configuration system what actions to take when the node is configured. for example. multi (whether the leaf node can have multiple values). Help information: Some fields provide help information for user interfaces (e.def for a node specifies the details of the node.val file.. Node type and value: These include the following fields: tag (whether the node is a tag node). CLI auto-completion): help and allowed.def duplex/ node.def file within the directory is the configuration template for the node. 1. and the available fields can be divided into three categories... and delete (what to do when the node is added.def speed/ node. create. in the following discussion we will assume such an implementation is used. and type (data type of the leaf node’s value or the tag node’s tag).val for speed contains the string "auto". for example. Note that tag nodes are a special case. the Vyatta configuration system also maintains a "tree" of configuration templates that represent all available configuration nodes..tag/ address/ node.def ethernet/ node.g. in addition to the running configuration. which is one possible implementation of the template hierarchy.def . as mentioned earlier the ethernet node is a tag node. changed. . and deleted. For example. and therefore.def node. The node. . note that the running configuration only contains a subset of all available configuration. A node. and its "tag" eth0 is represented as a subdirectory.

before executing the whole string with a shell. ethernet (which is a tag node. the configuration system will replace these references with the strings "auto". "10000" update: if [ x$VAR(@) != xauto ]. and the type field specifies that the data type of the node’s value is "text". the configuration system basically takes the whole string and executes it using a shell. Figure 5 shows the simplified template for the speed node. so we will focus on the FusionCLI.3 Configuration front-end The Vyatta configuration system provides two different configuration front-ends for user interaction.e. attempting to auto-complete the node)./@) speed $VAR(@) duplex $VAR(. a user can issue Vyatta configuration commands and use regular Unix commands from the same CLI. (The syntax field also supports regular expression and many other operators not presented here. The help string "Set the speed for this interface" will be shown when a user requests help for the node (for example. 3./@) autoneg on fi delete: ethtool -s $VAR(.e. and "auto"./@) autoneg on Figure 5: Configuration template for the speed node structure.. then ethtool -s $VAR(. "100". we already know that the node is a leaf node. i. so the value actually refers to the tag). the speed node. $VAR(. Note that the actions are specified as a "shell script".As an example. The Web GUI is currently under extensive development... "10". respectively. i.) The update and delete fields specify the "actions" to take when a user updates and deletes the node.. and $VAR(.. i.. respectively. User FusionCLI bash Vyatta-specific changes Programmable completion Configuration backend Help text Auto-completion Vyatta completion scripts Configuration templates Figure 6: Overview of Vyatta FusionCLI . "1000"../duplex/@) refers to the value of the sibling node duplex. with a few exceptions. the Vyatta FusionCLI™ and the Vyatta Web GUI. In other words. 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. From the directory type: txt help: Set the speed for this interface syntax: $VAR(@) in "auto"../duplex/@) autoneg off else ethtool -s $VAR(. 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 absence of the multi field in the template indicates that the node takes a single value. In this template. "2500". Due to space constraint. "eth0"./@) refers to the value of the parent node. Therefore. the details of variable references are not presented here.e. $VAR(@) refers to the value of "this" node.. using the previous configuration example (Figure 1). 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.

g. discussed in the next section. 3. extracts the validation and actual actions. The set is deemed successful. When the commit is issued. syntax and type) specified in the corresponding node’s template is performed. Some modifications to bash were also performed to add Vyatta-specific functionality. The validation and actions are performed by the configuration backend. For example. At any point. so the backend records this change in a "working" area but does not actually change the running configuration. 3. only the validation (e. the backend interacts with the actual subsystems and effects the changes. to configure the settings in Figure 1. the bash programmable completion mechanism allows developers to define auto-completion starting at the second word on the command line. the user can hit the "Tab" key for auto-completion or the "?" key to display the help text for the "current" node. set interfaces ethernet eth0 address 10.Figure 6 provides an overview of Vyatta FusionCLI. update and delete) are only performed when the commit command is issued. 4. It verifies that the user-entered value "auto" is of the correct type. the backend parses the template for the speed node (see Figure 5) and finds that the data type of the node value is "text". 2. set interfaces ethernet eth0 speed auto commit The backend behaves as follows. the backend parses the configuration templates for the relevant nodes. The backend verifies that "auto" is one of them. The help text and auto-completion are implemented using bash’s programmable completion feature [6] along with a set of completion environment scripts. We modified the mechanism to provide help and completion on the first word so that they would work for the Vyatta commands. and commit (for committing a set of changes made using set and delete).1. suppose the user issues the following commands.4 Configuration backend The configuration backend maintains and manipulates the running configuration according to commands from users (issued through the configuration front-end). The FusionCLI obtains the help text and auto-completion information from the configuration templates described in the previous section. and scripts that implement the configuration commands set. etc. commit. The Vyatta configuration commands include set (for adding a new node or changing an existing node). When the set command is issued. For example.. and when the running configuration is changed. delete (for removing an existing node). libraries. and performs the appropriate validation or action. .g. The FusionCLI implementation is based on the GNU Bourne Again Shell (bash). the backend iterates through all the changes recorded in the working area so far and. 1. The template also specifies syntax with a list of valid values. When a command is issued.1/24 set interfaces ethernet eth0 duplex auto set interfaces ethernet eth0 speed auto commit Note that when a set command is issued. a user can issue the following sequence of commands. The "actions" (e. carries out the actions specified in the template for the changed node. The backend includes a set of programs. For example. for each change.0.. delete.

replaces all the variable references in the string as discussed earlier. Setting up fair-queue is done by issuing three commands in configuration mode. interfaces { ethernet eth0 { address 10. the design is based on qos-policy templates. even by external contributors.. as shown in Figure 7. } . The format of Vyatta configuration files is a textual representation of the hierarchical. This policy provides an interface to the Stochastic Fair Queue[10]. # set qos-policy fair-queue fq # set interfaces ethernet eth0 qos-policy out fq # commit . Figure 7: Configuration file format To summarize. 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. In this particular example. and executes the string as a shell command. User’s wanted a way to configure QoS to provide better service for Voice Over IP (VoIP) traffic.1/24 duplex auto speed auto . Like firewall rules. 4..0.. a queueing discipline that divides traffic into random groups and does not let any one group monopolize the flow..1.. Two types of policy were implemented initially. The user can then load such a file later to restore the saved configuration. the underlying infrastructure can be hidden or exposed. the Vyatta configuration system makes our software easily extensible. and it changes the speed setting on the actual network interface eth0. the backend extracts the update field from the template of the speed node (since the node’s value is set by the user). 6. 4 QoS Architecture When adding a new abstraction layer. The use of text-based templates eliminates the need for compilation and even allows changes at run time.1 Fair Queue A simple policy fair-queue was implemented first. for example. The ability to specify shell-based commands for configuration actions in the templates further simplifies the integration effort. turning on auto-negotiation. In addition to supporting individual commands. SFQ is a good choice for a router when many flows are competing for a single congested link.5. the backend also allows a user to save the running configuration into a configuration file that can be copied elsewhere. In this case the ethtool program is run.. } .

) $VAR(@) $VAR(@) $VAR(./.) is always “out” but eventually the same template can be copied for use on “in”.. deleting or changing a policy 2 ./@) $VAR(. the parent $VAR(.tag qos-policy node. a one line shell command is used. For now. and invokes a Perl script to to do the real work of adding.) The templates actions can be implemented in any language.. the grandparent of the node $VAR(. This command sequence is created by the directory trees shown in Figure 8./@) $VAR(./. 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(..def node.def qos-policy fair-queue node.) $VAR(@) QoS configuration also needs an additional template for attaching a policy to an interface interfaces/ethernet/ In this template.) (“fair-queue”).def out node./. The variable names reflect the contents of the current node $VAR(@) and the parent $VAR(.templates/ interfaces ethernet node.) $VAR(@) delete: vyatta-qos --delete-interface $VAR(. The second statement applies that policy to the first Ethernet device(eth0). The last one makes the change happen. 2 Examples are simplified for clarity . For example: show system kernel-messages just runs the standard “dmesg” command..tag queue-limit node. Theqos-policy/fair-queue/node. For simple things... But most configuration commands have to deal with configuration state and interacting with other programs therefore the Perl scripting language is used.def file allows a text value (with some restrictions)./@) refers to the name of the ethernet device (eth0). type: txt help: Set output QOS policy for specified ethernet interface allowed: vyatta-qos --list-policy update: vyatta-qos --update-interface $VAR(.def Figure 8: template file system hierarchy The first command defines a policy and uses all the default values.

my $config = new VyattaConfig. $type. sub make_policy { my ($config. my $out. $name).pl is the QoS script for converting the configuration state to commands.1 is the object factory factory pattern to create a policy specific". The commands method generates the commands to tc to create the configured policy. "|-" or exec qw:sudo /sbin/tc -batch -:. open $out. $shaper->commands($out. $name). $config->setLevel(’qos-policy’). ). The typical call to update the interfaces goes has a generic and then a policy specific portion. The new method creates a new data structure and stores the contents of the configured variable. close $out. $name) = @_. Figure 4. VyattaQosFairQueue for this example. . $interface). $name ) = @_. my $location = "$class. ’fair-queue’ => "VyattaQosFairQueue". # This means template exists but we don’t know what it %policies = ( ’traffic-shaper’ => "VyattaQosTrafficShaper". followed by calling policy to produce a list of tc commands. require $location. my $class = $policies{$type}. defined $class or die "Unknown policy type $type". } } } Figure 9: vyatta-qos. $direction). $type. return $class->new($config. delete_interface($interface. $direction. The real policy specific work is done in the VyattQosFairQueue Perl module. foreach my $type ( $config->listNodes() ) { my $shaper = make_policy($ code for policy creation The vyatta-qos. } sub update_interface { my ($interface. $config->setLevel("qos-policy $type $name").

$class. sub new { my ( $that. } Figure 10: VyattaQosFairQueue Perl module . } sub commands { my ( $self. print {$out} "qdisc add dev $dev root sfq". my $class = ref($that) || $ %fields = ( _limit => undef. $dev ) = @_. return bless $self. $config ) = @_. print {$out} " limit $self->{_limit}" if ( defined $self->{_limit} ). print "\n". ). my $self = {%fields}. $out. $self->{_limit} = $config->returnValue(’queue-limit’).

If a packet matches none of the defined .2 Traffic Shaper Although fair-queue is a useful policy. This policy encapsulates the Hierarchical Token Bucket (HTB) queuing discipline allowing traffic groups and shaping this traffic at different rates. The traffic-shaper is more versatile. 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.4. The template for the top level node is almost the same. the configuration is more of a toy example.

Most of these values have reasonable defaults and the interface tries to be as smart as possible. The sample configuration (Figure 11) shows how traffic is broken up into classes defined by match rules and assigned bandwidth values. 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.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. The auto bandwidth value queries ethtool to find the speed of the underlying interface. 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. and individual class bandwidth values can be specified as a percent of the overall bandwidth. it goes obeys the specification of the default class.classes. and each class can have a different underlying queue type. class ftp { bandwidth 100 match ftp { ip { source { port 20 } destination { port 21 } } } } . 4. Each class can have a different reserved bandwidth and a maximum bandwidth ceiling and underlying queue discipline. Each class defined corresponds to a class in the HTB queue discipline.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.

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 } } } } .Or the user may want to match either source port 20 or destination port 21.

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". # 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. When matching IP protocols any value contained in /etc/protocols is allowed so the allowed rule is: allowed: awk ’ /^#/ { next } { printf "%s ". burst and other special arguments used in the tc commands. In the Qos case. An external program can also be used to validate a field that has other possibilities or restrictions. mbit. . # 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. minus sign or underline. the content of this field must be an embedded shell script that outputs the list of all values. $1 }’ </etc/protocols 5. gbps) For many configuration fields only a certain set of values is possible. This uses the help tag of each possibility to provide more information. This handled using the allowed field. digits. Next example is how to allow any of a set of choices. There are two forms of help. This approach allows the list to be dynamically generated based on the state of the system. gbit) bytes per sec (kbps.5 Error handling The configuration template system is designed to avoid syntax errors by providing help and a list of options. "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. mbps. the first is shown when looking for the correct option using tab for completion. the vyatta-qos-util Perl script contains code to do syntax checking for the rate. the comp_help field in the node definition is displayed.1 Syntax checking Additional restrictions on the contents of a node can also be done by using the syntax field.

this allows programmatic update actions. 990. The program or script that is done during the commit cycle can print an error message and exit with a failed error code. 6. Since the begin and end tags are always run. For example. 1005.def file uses a finalizing end to walk through all the qos-policy configuration and find changes.2 Semantic checking With Perl module: my %config_rank = ( ’qos-policy’ ’firewall’ ’service nat’ ’system host-name’ ’interfaces’ ’interfaces bridge’ ’interfaces ethernet’ ’interfaces tunnel’ . For example. . to workaround this templates can use the end tag.5. But the end rule in the qos-policy/node. There is no update propagation mechanism. 1020. The top-level qos-policy/node. 1010.tag/default/bandwidth but does not cause any update event to occur on qos-policy/node.tag/traffic-shaper/node. 910.1 Initialization ordering During system initialization some areas need to be configured before others. 980.def.tag/traffic-shaper/node. The configuration is handled by a special table in the VyattaConfigLoad. These occur because the configuration evaluation system is unaware of any dependencies between different areas of the configuration. 1000. qos-policy need to be loaded from the configuration file before they can be applied to the actual Ethernet interfaces. These are done during the commit process. # 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.2 Nested update Changes to a QoS policy cause all the interfaces using that policy need to be updated. .def template runs a script that traverses all the configured policies and updates any changed parameters. => => => => => => => => 1100. The user can then go back and fix the problem. that require workarounds. like most configuration there are additional restrictions that can not be checked until the whole configuration is known. 6. and this blocks the commit from taking effect. the change to an existing policy: # set qos-policy traffic-shaper myshaper default bandwidth 100 # commit Would update the node qos-policy/node. .

The CLI can be used to manage any router function. An-Cheng Huang did most of the FusionCLI implementation and contributed the section on the Vyatta configuration system architecture. But some network hardware doesn’t support the necessary ethtool interface and the speed is not known until the device is online. so other alternatives are being evaluated. . one of the features is the ability to define a policy which uses the speed setting of the Ethernet device as the base rate.6. There is a question about whether this is the best and safest choice.3 Automatic speed detection In the QoS system. The use of templates and configuration infrastructure make QoS configuration simpler. 7 Conclusion FusionCLI is a flexible way to integrate Linux router functions into a complete package that is familiar to network router administrators. 8 Acknowledgments Robert Bays did the initial design for the CLI and QoS. The current behavior is to just fallback to 100Mbit if speed information is not available. Arkady Rabinov did the initial implementation of the configuration backend. and Vyatta hopes to make it accessible for community by documenting and explaining how it works.

[8] Mark Handley. Traffic Control . The wonder shaper. 2003. Stochastic fairness queuing. [2] Werner Almesberger and Epfl Ica. 2002. A routing software package for TCP/IP networks. and T S Eugene Ng. [12] Ion Stoica. In Netconf. [9] Bert Hubert. Hui Zhang. IEEE/ACM Trans. 2002. Xorp: An open platform for network research. 1997. Kuznetsov. [4] Kunihiro Ishiguro et al. Khosravi. Rfc 3549 linux netlink as an ip services protocol. Kleen. and A. Mckenney. HTB Linux queuing discipline manual . H. Networking. [10] Paul E. [5] S Floyd and V Jacobson. pages 53–57. Link-share and resource management models for packet networks.References [1] Werner Almesberger. [3] Martin Devera. [11] J. 2005. Orion Hodson. New network configuration architecture . 2006. Quagga. Salim.implementation overview. The GNU Bash Reference Manual. 2006. Linux network traffic control . A hierarchical fair service curve algorithm for. [7] Thomas Graf. In ACM SIGCOMM Computer Communication Review. and Eddie Kohler. 1999. 2003.Next Generation Reference Manual. A. In Proceedings of SIGCOMM. [6] Free Software Foundation. 1990. .user guide. 1995.packet classification and scheduling.

Sign up to vote on this title
UsefulNot useful