12-16-2008 03:54 AM - edited 03-06-2019 02:59 AM
LinuxS----(F1/0)3640(F0/0)---LinuxC
Cisco IOS 3640 is running IOS version c3640-a3jk9s-mz.123-18.bin
I use QoS to limit both http and SSH traffics between LinuxS and linuxC both ways.
Here is my configuration:
ip access-list extended http
permit tcp any any eq www
permit tcp any eq www any
ip access-list extended ssh
permit tcp any any eq 22
permit tcp any eq 22 any
class-map match-any http
match access-group name http
class-map match-any SSH
match access-group name ssh
!
policy-map test
class http
police cir 1000000 pir 1100000
conform-action set-dscp-transmit af11
exceed-action set-dscp-transmit cs1
violate-action drop
class SSH
police cir 1000000 pir 1100000
conform-action set-dscp-transmit af11
exceed-action set-dscp-transmit cs1
violate-action drop
interface FastEthernet1/0
description INTERNAL
ip address 1.2.3.4 255.255.255.0
load-interval 30
duplex full
speed 100
service-policy input test
With this cofiguration, LinuxC can only get about 15KB/s using http and SSH.
However, if I change "pir 1100000" to "pir 1200000", then LinuxC can get
all the way to 1.1Mbps download with http and SSH.
Can QoS gurus tell me why it behaves this way? Thanks
12-16-2008 06:05 AM
I would suspect increasing the pir from 1100000 to 1200000 increases the burst window enough that there's a huge reduction in drops. Both HTTP and SSH use TCP, and TCP's performance is very much involved with drop rates. You could confirm this if you check the policer stats; compare ratios of the packets seen by the policer to how many it drops.
12-16-2008 06:11 AM
Additional information:
After changing "pir 1200000" to "pir 1500000",
both ssh and http go right back to 15KB/seconds.
How do you explain that?
12-16-2008 06:41 AM
I'm unable to easily explain that since I don't see your stats, and even if I did, many other variables can be involved. That's why I suspect what was happening, I don't know what is happening.
What do the different drop ratios look like at the pir 1100000, 1200000 and 1500000 settings? What do the other policer stats look like at those settings?
12-16-2008 07:26 AM
THERE ARE NO OTHER TRAFFICS GOING ACROSS THE 3640 BUT http and ssh traffics.
AT PIR=1200000, I see this:
C3640#sh policy-map interface f1/0
FastEthernet1/0
Service-policy input: test
Class-map: http (match-any)
10390 packets, 15723225 bytes
30 second offered rate 1323000 bps, drop rate 239000 bps
Match: access-group name http
police:
cir 1000000 bps, bc 31250 bytes
pir 1200000 bps, be 37500 bytes
conformed 7082 packets, 10714913 bytes; actions:
set-dscp-transmit af11
exceeded 1416 packets, 2143824 bytes; actions:
set-dscp-transmit cs1
violated 1892 packets, 2864488 bytes; actions:
drop
conformed 909000 bps, exceed 184000 bps, violate 239000 bps
Class-map: SSH (match-any)
26737 packets, 40387871 bytes
30 second offered rate 1449000 bps, drop rate 251000 bps
Match: access-group name ssh
police:
cir 1000000 bps, bc 31250 bytes
pir 1200000 bps, be 37500 bytes
conformed 18400 packets, 27767101 bytes; actions:
set-dscp-transmit af11
exceeded 3666 packets, 5548876 bytes; actions:
set-dscp-transmit cs1
violated 4671 packets, 7071894 bytes; actions:
drop
conformed 999000 bps, exceed 199000 bps, violate 251000 bps
Class-map: class-default (match-any)
1340 packets, 105849 bytes
30 second offered rate 3000 bps, drop rate 0 bps
Match: any
C3640#
------------
AT PIR=1500000, I get this:
C3640#sh policy-map interface f1/0
FastEthernet1/0
Service-policy input: test
Class-map: http (match-any)
2493 packets, 3771514 bytes
30 second offered rate 274000 bps, drop rate 154000 bps
Match: access-group name http
police:
cir 1000000 bps, bc 31250 bytes
pir 1500000 bps, be 2929 bytes
conformed 1025 packets, 1548962 bytes; actions:
set-dscp-transmit af11
exceeded 0 packets, 0 bytes; actions:
set-dscp-transmit cs1
violated 1468 packets, 2222552 bytes; actions:
drop
conformed 105000 bps, exceed 0 bps, violate 151000 bps
Class-map: SSH (match-any)
2853 packets, 4263659 bytes
30 second offered rate 302000 bps, drop rate 163000 bps
Match: access-group name ssh
police:
cir 1000000 bps, bc 31250 bytes
pir 1500000 bps, be 2929 bytes
conformed 1249 packets, 1835203 bytes; actions:
set-dscp-transmit af11
exceeded 0 packets, 0 bytes; actions:
set-dscp-transmit cs1
violated 1604 packets, 2428456 bytes; actions:
drop
conformed 123000 bps, exceed 0 bps, violate 163000 bps
Class-map: class-default (match-any)
659 packets, 52063 bytes
30 second offered rate 3000 bps, drop rate 0 bps
Match: any
C3640#
Any insights to this?
12-16-2008 11:43 AM
"Any insights to this?"
Insights, yes. In my first post, I mentioned the possibility of the burst window changing as the PIR changes, that's what I see here. I noted if it increases in size, I would expect drops to decrease and the rate allowed to increase. Of course, the converse would be true too. I.e., if Be size decreases, as it appears to have done moving from 1200000 to 1500000, this likely accounts for the much slower transfer rate.
cir 1000000 bps, bc 31250 bytes
pir 1200000 bps, be 37500 bytes
vs.
cir 1000000 bps, bc 31250 bytes
pir 1500000 bps, be 2929 bytes
The differences between the "exceeded" counters is important too.
Why there's such a large difference in Be, and why it decreased when you increased PIR, isn't clear to me. What version of code are you running?
BTW: Often you can manually adjust Bc and Be, if you can get the 1500000 Be to be sized like 1200000 Be, you should see the transfer rate jump up.
12-16-2008 12:08 PM
"Why there's such a large difference in Be, and why it decreased when you increased PIR, isn't clear to me. What version of code are you running?"
That's a 64k question. I am trying to find
out why it behaves this way.
BTW, Cisco IOS 3640 is running IOS version c3640-a3jk9s-mz.123-18.bin
12-16-2008 12:20 PM
"That's a 64k question. I am trying to find out why it behaves this way. "
Only Cisco could answer that, since you're allowing the router to default its Be values. It might be a "defect" since the default normally uses, I thought, the same default Tc for various rates. If you have a contract, update to later code, such as 12.3(26) and see if it behaves the same.
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: