02-22-2010 02:03 AM - edited 03-06-2019 09:49 AM
Hey,
I wan't to configure my Catalyst 3750.
I have two networks
192.168.1.0 /24
192.168.2.0 /24
the packets from the 192.168.1.0 network must become 70% of the Bandwidth.
the packets from the 192.168.2.0 network must become 30% of the Bandwidth.
I make 2 ACL's
acces-list 1 permit 192.168.1.0 0.0.0.255
acces-list 2 permit 192.168.2.0 0.0.0.255
then two class maps
class-map net1
match access-group 1
class-map net2
match access-group2
Now I think I must create a policy map....
policy-map limiter
class net1
?
QoS policy-map class configuration commands:
exit Exit from QoS class action configuration mode
no Negate or set default values of a command
police Police
service-policy Configure QoS Service Policy
set Set QoS values
trust Set trust value for the class
class net2
and after the policy map
interface vlan 1
service-policy input limiter
I don't know what I have to configure in the policy map..... please help me...
regards
Solved! Go to Solution.
02-25-2010 09:23 AM
Hi Emmo,
That picture definitely help!
So let me explain it; the queuing algorithm, share queue or shape queue are used for egress traffic queuing; ingress queuing is different, very limited, and normally we don’t use ingress queue. That is because congestion usually happens on uplink egress direction.
Now, let's look your testing. FTP traffic is more like unidirectional traffic, from FTP server towards clients. When FTP traffic coming in g1/0/17 interface, it get congested and be queued by the interface input queue. The switch will serve incoming traffic as FIFO fashion; it will check the mac-address-table and switch the FTP traffic to its output interfaces, which are g1/0/18 and g1/0/20. On the output interface, because no congestion happen, all traffic can be sent without be queued. As you can see, egress queuing is not be used in the whole process. So it is expected to see the 50/50 split.
In order to test the egress queue, you can put one FTP server at g1/0/18 and g1/0/20, put client on g1/0/17 and get same file from 2 FTP servers. That way, you can verify whether the egress queue working or not.
HTH,
Lei Tian
02-25-2010 12:21 PM
Hey,
So let me explain it; the queuing algorithm, share queue or shape queue are used for egress traffic queuing; ingress queuing is different, very limited, and normally we don’t use ingress queue. That is because congestion usually happens on uplink egress direction.
Now, let's look your testing. FTP traffic is more like unidirectional traffic, from FTP server towards clients. When FTP traffic coming in g1/0/17 interface, it get congested and be queued by the interface input queue. The switch will serve incoming traffic as FIFO fashion; it will check the mac-address-table and switch the FTP traffic to its output interfaces, which are g1/0/18 and g1/0/20. On the output interface, because no congestion happen, all traffic can be sent without be queued. As you can see, egress queuing is not be used in the whole process. So it is expected to see the 50/50 split.
nice explain! thanks But is doesnt match on my Switch I think It does not matter whether I do an upload or download, transfer rates are always the same (50/50).
In order to test the egress queue, you can put one FTP server at g1/0/18 and g1/0/20, put client on g1/0/17 and get same file from 2 FTP servers. That way, you can verify whether the egress queue working or not.
I tested a download and a upload from the client's... It is the same as I would change the interfaces. When you look at the picture.... The command ncftpput is a upload tool for FTP.
WTF!!!
emmo
02-25-2010 01:40 PM
Ok.
Can you clear the counter use "clear mls qos interface statistics", and do the test. After the test, can you capture the output of "show mls qos int g1/0/17 stat" , ""show mls qos int g1/0/18 stat" , "show mls qos int g1/0/20 stat" and post it.
Thanks
02-26-2010 01:49 AM
Good morning,
I have reset the counter and start the test. Here the posts
testswitch#show mls qos int g1/0/17 stat
GigabitEthernet1/0/17
dscp: incoming
-------------------------------
0 - 4 : 119 0 1723750 0 11
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 70 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 8589944 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 8076183 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 1723981 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------
0 - 4 : 87 8589944 8076183 0 0
5 - 7 : 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
testswitch#show mls qos int g1/0/18 stat
GigabitEthernet1/0/18
dscp: incoming
-------------------------------
0 - 4 : 32 0 8589894 0 392
5 - 9 : 0 0 0 0 0
10 - 14 : 2 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 405 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 782007 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 8590343 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------
0 - 4 : 536 782007 0 0 0
5 - 7 : 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
testswitch#show mls qos int g1/0/20 stat
GigabitEthernet1/0/20
dscp: incoming
-------------------------------
0 - 4 : 32 0 8076134 0 394
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 1 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 412 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 941862 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 8076583 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------
0 - 4 : 543 0 941862 0 0
5 - 7 : 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
The funny thing is, at the beginning of the transfer the rates I wish are present
The Client 1 has 80MB and Client 2 30MB, but when Client 1 goes under 75M and he do it after 20sec, than Client 2 have a higher Rate like 50M and Client's 1 rate fall down to 50M too.
STILL WTF!
emmo
02-26-2010 05:39 AM
Hi Emmo,
Thanks for the beautiful rating!
Let's take a look the statistics.
GigabitEthernet1/0/18 (will be marked to dscp 10 and put in queue 2 with 30% bandwidth)
dscp: incoming
-------------------------------
0 - 4 : 32 0 8589894 0 392
GigabitEthernet1/0/20 (will be marked to dscp 20 and put in queue 3 with 70% bandwidth)
dscp: incoming
-------------------------------
0 - 4 : 32 0 8076134 0 394
GigabitEthernet1/0/17
dscp: outgoing
-------------------------------
0 - 4 : 70 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 8589944 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 8076183 0 0 0 0
From the output, it doesnt look like there is congestion on the interface g1/0/17; I donot see any packet been dropped. As we already explained, when there is no congestion on interface, each queue can use available bandwidth beyond its assigned.
Another thing, is your FTP application TCP based? Can you find something UDP based application to test? As TCP has build in congestion control, it can reduce window size when congestion detected.
HTH,
Lei Tian
02-26-2010 06:34 AM
Thanks for the beautiful rating!
np youre the one and only!
GigabitEthernet1/0/18 (will be marked to dscp 10 and put in queue 2 with 30% bandwidth)
No, Packets with dscp 10 marks, will be put in Queue 3 with 70% bandwidth..
Well, look at these Command
mls qos srr-queue output dscp-map queue 3 threshold 1 10
dscp: incoming
-------------------------------0 - 4 : 32 0 8589894 0 392
GigabitEthernet1/0/20 (will be marked to dscp 20 and put in queue 3 with 70% bandwidth)
Also no The packets will be marked with 20 an put in queue 2 with 30% !!!
The Command:
mls qos srr-queue output dscp-map queue 2 threshold 1 20
dscp: incoming
-------------------------------0 - 4 : 32 0 8076134 0 394
GigabitEthernet1/0/17
dscp: outgoing
-------------------------------0 - 4 : 70 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 8589944 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 8076183 0 0 0 0From the output, it doesnt look like there is congestion on the interface g1/0/17; I donot see any packet been dropped. As we already explained, when there is no congestion on interface, each queue can use available bandwidth beyond its assigned.
Oh oh!
Did you mean when I copy Files without a collison or a congestion or what ever.... That the Rates are always be split 50/50 or in the relationship how many clients produce traffic.
And ONLY when a congestion is present, the "outsourcing" will be active?
I thought I can be guaranteed the bandwidth for a specific Ip Area and when the area is do not use the traffic, than other Areas can be used the traffic from the area. Without congestion and all other network errors! "Like Soft Shaping"
My Dream is broken!
Another thing, is your FTP application TCP based? Can you find something UDP based application to test? As TCP has build in congestion control, it can reduce window size when congestion detected.
TCP based, yes... I will be look for something udp based....
can you say me the time at your position?
Here is is it 15:34
Emmo
02-26-2010 08:20 AM
Hi Emmo,
Congestion means when you put data more than the interface can handle; if there is no congestion, the SRR will send packet in queue 2 and queue 3 in round robin fashion. For example you have 3 packets in queue 2 and 7 packets in queue 3; we say packets in queue 2 are RED and packets in queue 3 are BLUE. The switch will send traffic as RED BLUE RED BLUE RED BLUE; now more packets coming in queue 2 and queue 3 switch will continue send as round robin until congestion happen on the interface.
Yes, let me know the result for UDP traffic. My time is 11:20 now.
HTH,
Lei Tian
03-11-2010 04:56 AM
Hey Lei,
I am sorry, but I stood under pressure because the deadline always got closer.
So the configuration get worked nice. It was real in such a way, that to treat FTP his clients tried fair and would like to protect every 50% of range. Then I have tried out the test not with FTP, but with netcat and NFS and it worked with no problems.
If you want a few more test results or configurations I can send them to you with pleasure.
Many thanks you have supported me so. If I have a problem once again I turn with pleasure again to you.
kind regards
Emmo
PS:
For the fuc*** English.... thay thanks to abacho
03-11-2010 10:16 AM
Hi Emmo,
Glad to help. Come back when you have question.
Thanks,
Lei Tian
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: