ZeroShell    Forum
   Feed RSS Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth an interface for Captive Portal


      What is it?
      Screenshots
      License
      Announcements
      Mailing List
      Forum
      Documentation  
      FAQ
      Hardware
      Download
      On-line Updates
      Kerberos Tutorial  
      Terms of use
      Contact me


  In greater details:
      Hotspot Router
      RADIUS Accounting
      Shibboleth SP
      Performances
      Net Balancer
      UMTS Router
      Soekris Net5501
      Proxy with Antivirus
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS and LDAP
      X.509 Certificates
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional

QoS and Traffic Shaping in Transparent Bridge mode

The purpose of this document is to describe the realization of a transparent bridge which is able to perform QoS (Quality of Service) and bandwidth management on the network traffic that crosses it. The bridge mode choice (instead that routed mode) is justified by the simplicity with which this component can be introduced inside a network topology without having to change the IP parameters such as the subnet and the Default Gateway
As shown in the diagram of the Figure 1, we will add the QoS Bridge between the Internet router and the layer 2 switch through which the hosts of the LAN are connected. Note that the simplicity of the chosen configuration does not affect the generality of the proceeding which will be possible to apply in more complex network topologies. In any case, keep in mind that the proceeding still remains valid even if Zeroshell is configured to act as a layer 3 router instead that as bridge. This is because the QoS classes are attached directly to the network interfaces (Ethernet, VPN, PPPoE, VPN bond and Bridge) and do not depend on the selected forwarding mode (routing or bridging).

QoS and Traffic Shaping in Bridge mode
Figure 1. QoS and Traffic Shaping in bridge mode.


In the following example configuration, we will create a certain number of classes of traffic to which we will assign the QoS parameters such as the Priority, the Guaranteed Minimum Bandwidth in the case of congested network and the Maximum Bandwidth not surmountable either when the network is not congested.
We will use the Layer 7 Filters, that with the DPI (Deep Packet Inspection) can classify traffics such as VoIp and Peer-to-Peer that are not possible to intercept by using filters on TCP and UDP ports.
In greater details, we will obtain the following results:
  • To classify the VoIP (Voice over IP) traffic such as the one produced by SIP, H323, Skype and MSN Messenger connections inside a class with high priority and guaranteed bandwidth. Doing so, the latency time is reduced and therefore the quality of video and voice reproduction is increased;
  • To limit the maximum bandwidth available for the file sharing P2P (Peer to Peer) transfers;
  • To avoid that the interactive traffic such as the one produced by telnet and SSH remote shell is delayed. This is achieved by classifying this type of traffic inside a class with high priority and low latency;
  • To classify the bulk traffic, that is the flow generated by the ftp and smtp transfers, in which a lot of large data packets are moved across the network, but they do not need to be delivered with low latency. In this case, we have to use a class with low priority, but without a maximum bandwidth limit.
In order to fix the ideas, we will suppose to have an asymmetric Internet bandwidth with 4Mbit/s for downstream and 2Mbit/s for upstream and assign to the QoS classes the parameters reported in Table 1


QoS ClassProtocolsPriorityGuaranteedMaximum
VOIPSIP, H323, Skype, MSN MessengerHigh1Mbit/s 
P2PeMule, EDonkey, KaZaA, Gnutella, BitTorrent, Direct ConnectLow 256Kbit/s
SHELLssh, telnetHigh  
BULKftp, smtpLow  
DEFAULTUnclassifiedMedium  
Tab.1 Parameters of the QoS classes


Before starting to configure the Zeroshell bridge to perform the QoS policies we want, you need to keep in mind the following concepts:
  • When a QoS class is applied to a network interface, the class only controls the outgoing traffic from the interface. On the incoming packets from an interface there is no control.
  • Looking at previously point, you could think that it is not possible to apply the QoS to the downstream traffic, but this is not quite true, because you can shape the incoming traffic from the interface ETH01 (looking at Figure 1) by controlling the outgoing traffic from the ETH00.
In order to simplify the treatment of the implementation of the QoS transparent bridge, it is divided into the following sections:

Making the configuration permanent

So that the ZeroShell configuration becomes permanent and so it is also reloaded after the system reboot it is necessary to create and activate a database. If you use the Live Cd version you need to have at least a read/write storage device connected to an IDE, SATA, SCSI or USB interface. If instead you use the compact flash version you can store the database directly on it. Because their highest stability due to the presence of Journaling you should use an ext3 or ReiserFS filesystem. You can create and format the partitions by using directly the ZeroShell GUI, but you should be careful when the device contains important data. The steps to be performed to create and activate the database are the following ones:
  • From the section [Setup]->[Storage] select the partition in which create the database and press the button [create DB];
  • In the window that appears (look at the figure) insert a description for the database, type in and confirm the password for the user admin, verify that the IP address 192.168.0.75 is configured on the interface network ETH00 and set the Gateway Default to 192.168.0.254.
  • Press the button [create] to proceed to the database generation;
  • Activate the database selecting it and pressing the button [Activate]. The system will be restarted with the configuration (look at the figure).
When you have finished this phase you can be sure that any next configuration will be permanently memorized.

Creating the bridge BRIDGE00(ETH00,ETH01)

Now you must create the BRIDGE00 interface and add to it the ETH00 and the ETH01 network interfaces so that the layer 2 traffic can be forwarded between the interfaces. However, keep in mind that when an interface becomes member of a bridge, it automatically loses any IP and VLAN settings. This is a problem, as in our case, if the interface to be added to the bridge is the one through which we are connected to the Zeroshell web GUI. To get round that, a function of the console of Zeroshell called "Create a Bridge" allows to automatically migrate the configuration (IPs and VLANs) of the ethernet interface that is chosen by the operator to the new bridge interface. This method, that however supposes the possibility of accessing the system through the VGA or serial console, solves the problem and the connectivity is lost just for the time the bridge takes to be in the forwarding state (about 15 seconds).

The steps needed to create the BRIDGE00(ETH00,ETH01) are the following ones:
  • Access the console menu and press the key "B" corresponding to the function "Create a Bridge". If you have not been already authenticated by the console then you will be asked for the admin password. Then press the key "y" to confirm to be aware of what you are doing. Choose the ETH00 interface pressing the key "1".
    The bridge has been now created and it has inherited the IP 192.168.0.75 from the ETH00. After a few seconds the connectivity between the browser in which you are using the web GUI and the Zeroshell box is established.
  • Now add the ETH01 interface to the BRIDGE00 bridge. For doing that, by using the web GUI, in the section [Setup]->[Network] press the button [Configure] related to the BRIDGE00 interface and move the ETH01 from the "Available Interfaces" list to the "Bridge Components" (look at the figure). Confirm by pressing the button [Confirm] and the interface ETH01 will be added to the bridge (look at the figure).

Assigning the global bandwidth to the bridged interfaces

Assigning the global bandwidth to each of the network interfaces involved in QoS is a fundamental operation for the correct work of the Quality of Service. In fact, since the system is not able to estimate dynamically the real bandwidth availability, it is necessary to indicate an estimate based on which the bandwidth will be distributed to the below QoS classes. Keep in mind that if the bandwidth actually available at a given moment is lower than the estimated one, the QoS at that moment doesn't work fine.

The steps needed to assign the global bandwidth to the interfaces ETH00 and ETH01 are the following ones:
  • From the section [QoS]->[Interface Manager] click on the button [Global Bandwidth] related to the ETH00 interface. In the form that appears (look at the figure) set the maximum and guaranteed bandwidth to 4Mbit/s and confirm by clicking on [Save] button;
  • Click on the [Global Bandwidth] related to the interface the ETH01 network interface and set the maximum and guaranteed bandwidth to 2Mbit/s.
  • To activate the global bandwidth settings click on the button [Activate last Changes].

Creating the QoS classes

Use the Class Manager from the section [QoS]->[Class Manager] (look at the figure) to create the QoS classes you need. Note that initially there is only the DEFAULT class in which unclassified traffic is sent.

The steps to be performed to create the Qos classes are the following ones:
  • Click on the [New] button of the "Class Manager" and type the string VOIP as class name. Insert the description "Voice over IP" and then set the High priority and the Guaranteed Bandwidth to 1Mbit/s. Save the class by clicking on the [Save] button;
  • Create the class P2P by using the same procedure as in the previous step, with the description "File sharing peer to peer" and then set the Low Priority and the Guaranteed Bandwidth to 256Kbit/s;
  • Create the QoS class SHELL with the description "Interactive shell traffic" and High priority;
  • Create the QoS class BULK with the description "Large data transfer" and Low priority;
You should not change the DEFAULT class's settings because we want that all the unclassified traffic has medium priority and this is already set for this class.

Adding QoS classes to the bridged interfaces

Now it is the moment to assign the QoS classes created in the previous steps to the network interfaces whose outgoing traffic you want to control.

The steps to be performed to assign the QoS classes to the interfaces are the following ones:
  • From [QoS]->[Interface Manager] click the button [Add Class] related to the ETH00 interface. From the dialog window that appears (look at the figure) click the button [Add] for the VOIP, P2P, SHELL and BULK QoS classes;
  • Add the same classes to the ETH01 interface with the same procedure of the previous step;
  • Enable the Quality of Service for ETH00 and ETH01 by clicking on the related flags "On";
  • Save the changes by clicking on the button [Activate last Changes].
Note that you have activated the QoS directly on the members (ETH00,ETH01) of the bridge and not on the BRIDGE00.

At this point the QoS is working on the bridge, but all traffic is outgoing from the DEFAULT class because you haven't classified the traffic yet. In the next steps we will do that.

Binding the services to the QoS classes

To bind a service on which you want to apply the QoS to a class you have to use the Classifier.

The steps to be performed to classify the traffic are the following ones:
  • Select the Classifier from the section [QoS]->[Classifier] (look at the figure). Press the [Add] button to insert the first rule in the classifier related to the P2P file sharing. In the dialog window which appears (look at the figure) enable all the peer-to-peer flags. Select the P2P target class and then click the button [Confirm] to confirm the rule;
  • Now is the time for the VoIP traffic to be classified. Start with the SIP protocol identifying it using the L7-filter and setting the VOIP QoS class as target (look at the figure). Using the same procedure, you should classify in the VOIP QoS class the H323, the Skype to Skype and the MSN Messenger protocols;
  • To classify the interactive traffic in the SHELL QoS class that has low latency use the characteristic of a ssh server that listens on the TCP port 22 and the telnet on the TCP port 23. You need four rules because the classifier must classify the packets with source or destination port equal to these values (22 and 23). This is an example of one of these four rules;
  • To classify the bulk traffic generated by the mail transfers use the characteristic that a smtp server listens on the port 25/TCP (look at the figure);
  • Although the FTP uses the port 21/TCP to exchange the commands, the transfers take place on random ports and therefore the easier way to classify them in the BULK class, it is by using the layer 7 filter (look at the figure).
  • Save and activate the rules that you have created by clicking on the button [Save].
Note: classifying the traffic of the several services is one of the most complex operations involved during the building of a QoS system. It is not always easy to identify the type of connection by using as filter only parameters such as the IP addresses and the TCP/UDP port numbers. In fact, we have often used the Layer 7 filters (l7-filter project) which are able to inspect the payload of the packets using the regular expressions to classify the application layer traffic. However, you should not abuse in the use of the l7-filter for two reasons. First, these types of checking, that applies regular expressions on the content of the packets, it is more CPU consuming than the filters on IP addresses and TCP/UDP ports and therefore they could not work fine on systems based on slow CPUs. The second one is that for some protocols the L7-filters have the problem of the overmatching that is when a packet that does not belong to a protocol is identified to be part of it. Generally, you should not use layer 7 filters when it is possible to identify a connection by using other types of conditions. Suppose, for example, that in your situation all the H.323 videoconferences take place by using the same MCU (Multipoint Conferencing Unit): in this case, instead to identify the H.323 connections with the L7-filter, you could classify them with the MCU's IP address.

Viewing the QoS statistics

At this point, the QoS bridge is working and the traffic should be classified in the QoS classes you created. To be sure that the QoS classification works fine you can view the statistics from the section [QoS]->[Statistics] (look at the figure). For every interface for which the QoS is enabled you can see the associated QoS classes and for every class you can see the configuration (Priority, Maximum Bandwidth and Guaranteed Bandwidth) as well as the amount of bytes which are sent out from the class and the Rate, that is the number of bits per second that are transmitted from the class. In addition, it is possible to display the graphic relating to the outgoing traffic classified by traffic type. For further details click here.



    Copyright (C) 2005-2013 by Fulvio Ricciardi