With the addition of Virtualbox to GNS3, you can do all sorts of simulations (except full switching) involving routers, firewalls, servers (windows or linux), applications, etc. It used to bother me a lot to run a network topology and rely on ping and tftp as test traffic for QOS. Now you do not have to rely on boring traffic to test QOS. You can use actual user traffic and classify and mark it on your routers to give it preferential treatment. You can set bandwidth caps on certain protocols, you can prioritise certain protocols, you can remark certain protocols, etc. The options for QOS testing are limited by your imagination.

In this blog, we will cover basic user traffic like web, ftp and windows sharing and classifying them to mark for QOS treatment. We will rate limit some, prioritise some and remark some on our network and see its effects on the destination end. We can also use the relevant show commands to verify proper operations.

We must note here that although there are options for Gigabit interfaces and Fast Ethernet interfaces on GNS3 yet these are in reality simulated interfaces and thus do not give us the theoretical throughput. In GNS3, we get throughput of 1Mbps on all the links and thus we will configure our QOS policies below this value to test it properly.

Minimum Requirements

• PC with i7 processor and sufficient ram to run 6 routers and 2 Virtualbox guests.
• Virtualbox with 2 graphical OSes. I have used Win XP and Ubuntu Studio
• GNS3 Virtualbox Edition

The Setup

The topology consists of 6 7200s as represented in the diagram. The ip addressing of the links is 1.1.x.x/24 where the 3rd octet is the router number combination of the link and the 4th octet is the router number. The Loopbacks have been numbered as 1.1.x.1/32 where the 3rd octet is the router number. OSPF is run on all links of all routers using network 0.0.0.0 255.255.255.255 area 0 command. I am using only one interface on the virtualbox host for connecting it with the GNS3. If you are using a NAT interface simultaneously, the reachability will not be complete as then both interfaces will have default route, so shutdown the NAT interface. I am using Ubuntu Studio as content source and it is connected to R1. Windows XP is used as user and is connected to R5. You might need the help of a Linux admin if you intend to run this lab as you have to enable Web server, FTP server and Samba on the Linux machine.

Configuration

The configuration will be divided in 3 sections according to how QoS is implemented. The first section will deal with traffic classification. The second section will deal with Traffic marking. The third section will deal with QoS policy settings. The configuration of all 3 sections are spread out over different routers to expand the scope of the Lab. If you wish, you can do classification, marking and policy setting on a single router itself.

Section 1 Classification

Since we can easily make a Linux machine a web and ftp server, the first 2 traffic will be http and ftp. Also, an easy source of volume based traffic is file sharing, we have enabled file sharing on Linux via work groups and that will form the third traffic type. I have downloaded large video files from the Internet to transfer from Linux to windows to test QoS. The traffic will be classified as below on router R1

Web (HTTP) via NBAR

FTP via NBAR

Work group based file sharing via extended Access list

The configuration of classification is as follows

#FTP
class-map match-all FTP
match protocol ftp
#Web
class-map match-all WEB
match protocol http
#File Sharing
ip access-list extended SMB
permit tcp any eq 445 any
class-map match-all SMB
match access-group name SMB

Section 2 Marking

It would have been perfectly possible to implement QOS policies without any marking had we done policy implementation on R1 itself. Since we want to spread out the configuration over multiple routers for Lab sake, we need to mark the packets such that the other routers in the network can use the marking and implement policies based on it. We will be marking the traffic using DSCP values as mentioned below

FTP as CS4

Web as CS3

File Sharing as CS2

The configuration of marking is as follows

policy-map MARK
class FTP
set dscp cs4
class WEB
set dscp cs3
class SMB
set dscp cs2

interface FastEthernet1/0
service-policy input MARK

If any time you are having difficulty in understanding DSCP, IP Precedence values, etc, you can refer to the table below which is a good source for co relating all the values. The Table has been taken from

http://www.netcontractor.pl/download/QoS%20Values%20Calculator%20v2.pdf

Section 3 QOS Policy Implementation

Now that we are ready with marked packets coming to the other routers, we can set the policies. We will choose the router R3 for initial policy setting. The policy will be set as follows noting we have just 1 Mbps overall bandwidth over simulated GNS3 interfaces

FTP will be given Priority bandwidth of 256 Kbps

Web Traffic will be given 512 Kbps

File sharing traffic will be policed at 128 Kbps and the exceeded traffic will not be dropped. Instead it will be remarked with DSCP value CS1 and we will use the new marking later on. Also, a guaranteed bandwidth of 128 Kbps is assigned to this class without which this class will not get any bandwidth.

The QOS policy configuration is as follows on R3

#File Sharing
class-map match-all CS2
match dscp cs2
#Web
class-map match-all CS3
match dscp cs3
#FTP
class-map match-all CS4
match dscp cs4

policy-map QOS
class CS2
bandwidth 128
police 128000 16000 16000 conform-action transmit exceed-action set-dscp-transmit cs1
class CS3
bandwidth 512
class CS4
priority 256 32000              #Burst has been configured as default burst was very low

interface FastEthernet2/0
bandwidth 1024         #It is important to put b/w as qos parameters will depend on it
load-interval 30                                                               #To refresh qos statistics faster
max-reserved-bandwidth 90  #reserves 10% b/w for routing protocol, default is 25%
service-policy output QOS

Now that we have implemented the QOS policies on R3, we can move further. We had kept room for improvement by remarking the file sharing traffic with DSCP value CS1. If I leave CS1 unchecked, file sharing traffic will have unlimited bandwidth as it is not rate-limited on R3. I want to ensure that it gets just 32 Kbps more than already assigned 128 Kbps. I can now police the CS1 marked traffic with 32 Kbps on R5.

The configuration on R5 is as follows

class-map match-all CS1
match dscp cs1
class-map match-all CS2
match dscp cs2
class-map match-all CS3
match dscp cs3
class-map match-all CS4
match dscp cs4

policy-map POLICE
class CS4
class CS2
class CS1
police 32000 4000 4000 conform-action transmit exceed-action drop
class CS3

interface FastEthernet2/0
bandwidth 1024
max-reserved-bandwidth 90
load-interval 30
service-policy output POLICE

I have used Classes for CS2, CS3 and CS4 for verification purpose only and it does not serve any QOS purpose. This is a good method to verify in real life whether packet is coming marked or not and what is the bandwidth being utilized

QOS Testing

We will transfer files via single protocols to check the bandwidth utilized in Non Congested Network. A congested network is one in which multiple protocols are striving for bandwidth at the same time and the Tx Ring of the interface is full or the ISP bandwidth cap is reached.

I have started an FTP transfer via Filezilla and below is the transfer rate

The show policy-map interface shows the current settings and statistics on the router for FTP (other classes have been removed for brevity)

Class-map: CS4 (match-all)
15889 packets, 23957722 bytes
30 second offered rate 966000 bps, drop rate 34000 bps
Match: dscp cs4 (32)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 256 (kbps) Burst 32000 (Bytes)
(pkts matched/bytes matched) 4587/6943258
(total drops/bytes drops) 497/752458

As can be verified above, the FTP transfer is utilizing full bandwidth when run alone

I have stopped FTP and started file download via web. Below is the transfer on Win XP

The transfer can also be verified via Show commands. This time I am going to use show command on R5. Although there is no policy for Web on R5 but still I had put classes. You can use the classes for verifying whether traffic is coming marked and what is the utilized bandwidth.

Class-map: CS3 (match-all)
7901 packets, 11958218 bytes
30 second offered rate 1108000 bps
Match: dscp cs3 (24)

As can be verified above, the web file download is utilizing full bandwidth when run alone

I have stopped file download via web and started file transfer via windows file sharing. Since Windows XP does not show file transfer speed, you can see the transfer rate via Task manager

In order to understand the transfer rate, we will utilize show outputs from both R3 and R5

R3

Class-map: CS2 (match-all)
2804 packets, 4010116 bytes
30 second offered rate 198000 bps, drop rate 0 bps
Match: dscp cs2 (16)
Queueing
Output Queue: Conversation 265
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 467/691146
(depth/total drops/no-buffer drops) 0/0/0
police:
cir 128000 bps, bc 16000 bytes
conformed 1868 packets, 2595440 bytes; actions:
transmit
exceeded 936 packets, 1414676 bytes; actions:
set-dscp-transmit cs1
conformed 126000 bps, exceed 72000 bps

As can be seen, the traffic is guaranteed 128 Kbps as well as policed to not exceed 128 Kbps. The excess traffic is remarked CS1

R5

Class-map: CS1 (match-all)
790 packets, 1193813 bytes
30 second offered rate 70000 bps, drop rate 40000 bps
Match: dscp cs1 (8)
police:
cir 32000 bps, bc 4000 bytes
conformed 334 packets, 504927 bytes; actions:transmit
exceeded 456 packets, 688886 bytes; actions:drop
conformed 30000 bps, exceed 40000 bps

The remarked packet from R3 is matched in R5 and policed at 32 Kbps. The bandwidth of Windows file transfer is as below

File sharing traffic marked with CS2 gets 128 Kbps
File sharing traffic remarked as CS1 gets 32 Kbps

So the total bandwidth is 160 Kbps as seen from the Task manager graph.

We will now run all transfers together to see per class bandwidth utilized

As can be verified below on R5, every traffic type is getting its share of bandwidth

Class-map: CS4 (match-all)
41149 packets, 62174062 bytes
30 second offered rate 278000 bps                  #Priority bandwidth of 256 Kbps for FTP
Match: dscp cs4 (32)

Class-map: CS2 (match-all)
5872 packets, 8344318 bytes
30 second offered rate 118000 bps              #guaranteed and policed b/w of 128 Kbps

Match: dscp cs2 (16)

Class-map: CS1 (match-all)
1968 packets, 2974848 bytes
30 second offered rate 18000 bps, drop rate 4000 bps               #policed b/w of 32Kbps 
Match: dscp cs1 (8)
police:
cir 32000 bps, bc 4000 bytes
conformed 901 packets, 1360908 bytes; actions:transmit
exceeded 1067 packets, 1613940 bytes; actions:drop
conformed 11000 bps, exceed 4000 bps

Class-map: CS3 (match-all)
65663 packets, 99395571 bytes
30 second offered rate 769000 bps         #guaranteed bandwidth of 512 Kbps for Web
Match: dscp cs3 (24)

The reason why remarked traffic of File sharing is getting less than 32 Kbps on R5 is because we have just policed the traffic and not given any bandwidth guarantee.