cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
551
Views
0
Helpful
7
Replies

rate-limiting explaination needed

cisco24x7
Level 6
Level 6

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

7 Replies 7

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

Additional information:

After changing "pir 1200000" to "pir 1500000",

both ssh and http go right back to 15KB/seconds.

How do you explain that?

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?

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?

"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.

"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

"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.

Getting Started

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: