All_about_network

So after previous post the whole setup should be working. But there are some things to be done yet. The heading says that the missing part is the QoS. So let’s have a closer look.

Step one is easy – just create some ACLs to match the traffic in our case it is goes like this:

#
acl number 3001 name black
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 26
acl number 3002 name platinum
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 28
acl number 3003 name gold
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 18
acl number 3004 name silver
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq ftp-data
acl number 3005 name default
rule 5 permit tcp source 192.168.2.10 0 destination 192.168.1.10 0 destination-port eq 22
#

If we have done this our traffic can by matched according to this rules so we can process it. In this case we were using the destination port as the distinguisher but as this is done by ACLs you can use whatever option the ACL will allow.

Step No.2 is to create create traffic classifiers, name them and bind them with the previously created ACLs. In the display below  we named the classifiers the same as ACLs so it is more obvious what is going on.

#
traffic classifier PLATINUM operator or
if-match acl 3002
traffic classifier DEFAULT operator or
if-match acl 3005
traffic classifier GOLD operator or
if-match acl 3003
traffic classifier SILVER operator or
if-match acl 3004
traffic classifier BLACK operator or
if-match acl 3001
#

Notice the operator “or” in our case it has no meaning as we use only one rule/ACL but if you use more of these itwill enable you to combine multiple ACL’s in different classifiers etc. which could be very useful and makes things very flexible.

Step No. 3 is to create traffic behaviour i.e. the action made if the acl is matched.

#
traffic behavior PLATINUM
remark dscp af32
traffic behavior DEFAULT
remark dscp af23
traffic behavior GOLD
remark dscp af21
traffic behavior SILVER
remark dscp af22
traffic behavior BLACK
remark dscp af31
#

Again we used the same names as for the ACL’s and Classifiers and the action is to remark the dscp value from whatever it was previously to certain value.

Step No.4 binding the proper classifier to proper behavior in a qos policy.
Here we are telling that in this particular policy we want these combinations of classifiers and behaviours.

#
qos policy qos
classifier BLACK behavior BLACK
classifier PLATINUM behavior PLATINUM
classifier GOLD behavior GOLD
classifier SILVER behavior SILVER
classifier DEFAULT behavior DEFAULT
#

With this step we have done almost everything. The last step is to apply the policy somewhere. This somewhere is inbound interface as this whole thing is basically marking only.
So step No.5 is just this piece of code:

#
interface Ethernet0/1
.
.
qos apply policy qos inbound
#

So we are done…nope somebody should shout this is not whole and that somebody would be completely right. The operation done above would result in marked traffic flowing through the router with it’s default scheduling mechanism in place. Sounds good one might say, but unfortunately the default scheduling mechanism is FIFO alias no scheduling at all. This would result in no effect at all. If you were working on different equipment it can work (e.g. the S3900 and S5600 have in their default SP+WRR in VRP ver. 3.40 of course you would need to match the default classes/types as the voice is SP and the rest is WRR). But on AR 19-XX you have to either enable scheduling or as we did just cheat a little.
We skipped scheduling as we instead used weighted traffic shaping based on the same ACL’s which actually works almost the same as scheduling but with much better control over what,when and how is processed. I know that scheduler should be set but in this case (very small routers) it does not really matter.

So the final step is to apply qos gts (general traffic shaping) on the outbound interface.

#
interface Virtual-Ethernet0
.
.
qos gts acl 3001 cir 50 cbs 3125 ebs 0 queue-length 50
qos gts acl 3002 cir 75 cbs 4687 ebs 0 queue-length 50
qos gts acl 3003 cir 100 cbs 6250 ebs 0 queue-length 50
qos gts acl 3004 cir 100 cbs 6250 ebs 0 queue-length 50
qos gts acl 3005 cir 175 cbs 10937 ebs 0 queue-length 50
#

Ok we need to explain what we just did here.
We needed to apply the shaping on the virtual Ethernet as we are using ethernet-style qos and if we would like to do it on the atm it would be much more complicated.
The gts is abbreviation for general traffic shaping then we define how to recognize which traffic to shape. Here we can re-use our old ACLs to recognize that particular traffic. Then the magic starts cir stands for committed information rate and in a way it is the most important number here – it says how much traffic is allowed to pass before queuing/dropping. In effect our config will pass 50kbits/sec matching acl 3001, 75 kbits/sec matching acl 3002 and so on. So the sum of all these cirs should equal you available bandwidth on the egress interface (minus approximately 10% as a reserve for packet bursting and other). The remaining three parameters are good for fine-tuning. CBS is committed burst size which means how much it is allowed one queue to be overloaded. This value is computed automatically and does not have any effect if all other queues are used fully. You can change it of course and if you will not share all bandwidth among the queues you can use it for short term automatic bursting of speed of one queue without actually re-configuring anything (good for voice and video). But in most cases this will have very limited effect. The extended burst size does the same thing but it is taking it to another level. As committed burst size is necessary for the proper function at all times ebs is not. The last variable is queue length. This is kind of fun as this actually can substitute the scheduling but the situation can get really complex when playing with queue length. This option says how many packets will be held during the congestion instead of being dropped so with combination with the previous options your results can be really interesting changing delays, and such stuff.

I hope this is inspirational and again in case of any question write your comment under this article.