I have read this many times before but it doesn't reflect reality.
Priorty only matter onces the interface has hit congestion, just like
bandwidth
Using IOS Version 12.4(16)
Router2 serial config
interface Serial0/1
bandwidth 64000
ip address 164.1.13.1 255.255.255.0
ip nbar protocol-discovery
serial restart-delay 0
end
Router 2 interface bandwidth
Router2#show int s0/1
Serial0/1 is up, line protocol is up
Hardware is M4T
Internet address is 164.1.13.1/24
MTU 1500 bytes, BW 64000 Kbit, DLY 20000 usec,
host connected to Router2 ethernet
Switch(config)#do ping 164.1.13.1 size 1500 repeat 100
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 164.1.13.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 8/33/144 ms
So we can see no tail drops without any QOS configuration
So now lets put on a very low priority statement
class-map match-all ICMP
match protocol icmp
!
!
policy-map ICMP
class ICMP
priority 8
interface Serial0/1
bandwidth 64000
ip address 164.1.13.1 255.255.255.0
ip nbar protocol-discovery
serial restart-delay 0
service-policy output ICMP
end
Now the ping form the ethernet host
Switch(config)#do ping 164.1.13.3 size 1500 repeat 100
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 164.1.13.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 28/50/128 ms
As we can see no interface drops
Rack1R1#show policy-map interface s0/1
Serial0/1
Service-policy output: ICMP
Class-map: ICMP (match-all)
119 packets, 178976 bytes
5 minute offered rate 2000 bps, drop rate 0 bps
Match: protocol icmp
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 8 (kbps) Burst 200 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
40 packets, 2542 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
So packets are matched but they aree not dropped because there is no
congestion
So now lets add a police statement to the same value as the priority
statement plus the 1.5times fudge factor
class-map match-all ICMP
match protocol icmp
!
!
policy-map ICMP
class ICMP
priority 8
police cir 12000
exceed-action drop
ping from ethernet host
Switch#ping 164.1.13.3 size 1500 repeat 100
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 164.1.13.3, timeout is 2 seconds:
.................
Success rate is 0 percent (0/17)
As we can see all traffic is dropped, this is because a 1500 byte ICMP
packet is 12000 bits and the fudge factor is an aproximation over time, if I
allowed Be some icmp would get though
Service-policy output: ICMP
Class-map: ICMP (match-all)
136 packets, 204544 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 8 (kbps) Burst 200 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
police:
cir 12000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 17 packets, 25568 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: class-default (match-any)
133 packets, 8151 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
As we can see the police action takes effect all the time, so all the
priority command does is give first preference out of the software que into
the TX ring.
I hope this has been informative and I thank you for viewing :P
cheers
_____
From: S Malik [mailto:ccie.09_at_gmail.com]
Sent: Saturday, July 04, 2009 3:03 AM
To: andrew
Cc: Tortle Tang; ccielab_at_groupstudy.com
Subject: Re: bandwidth and shape/police in MQC
Correction please'
I think, priority is maximum guaranteed bandwidth and any class assigned to
it is always given priority to the configured # regardless of congestion.
During congestion, extra traffic in the class will be dropped else extra
traffic will be dealt as default class.
On Fri, Jul 3, 2009 at 1:01 PM, S Malik <ccie.09_at_gmail.com> wrote:
Bandwidth/priority statement only matters during congestion,
shaping/policing happens all the time.,,,,
I think, priority is minimum guaranteed bandwidth and any class assigned to
it is always given priority to the configured # regardless of congestion.
During congestion, extra traffic in the class will be dropped else extra
traffic will be dealt as default class.
bandwidth is the minimum guarnateed BW all the times.
Most welcome to correct if wrong.
On Fri, Jul 3, 2009 at 10:51 AM, andrew <andrew.coates_at_internode.on.net>
wrote:
While its for a cisco 10000 router here is a good example of how
parent/child policy maps work compared to the policy map below:
http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/3levelsch.html#wp10
77234
look at the buckets picture. From my perspective the implemenation of the
child/parent policies is the opposite to the way its configured, ie from
configuration it looks like the traffic should be tested against the parent
then flow to the child, but it isn't its the opposite way around.
cheers
-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
andrew
Sent: Saturday, July 04, 2009 12:37 AM
To: 'S Malik'; 'Tortle Tang'
Cc: ccielab_at_groupstudy.com
Subject: RE: bandwidth and shape/police in MQC
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/white_pape
<http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/white_pap
er_c11-481499.html>
r_c11-481499.html
Priority with Explicit Policing Rate
When a priority class is configured with an explicit policer, traffic is
limited to the policer rate regardless of congestion conditions. In other
words, even if bandwidth is available the priority traffic will not be able
to exceed the rate specified with the explicit policer.
policy-map p1
class c1
priority
police cir 1000000 conform-action transmit exceed-action drop
im making the assumption that it is the same with shape/bandwidth ( I see no
reason why not)
cheers
-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of S
Malik
Sent: Saturday, July 04, 2009 12:20 AM
To: Tortle Tang
Cc: andrew.coates_at_internode.on.net; ccielab_at_groupstudy.com
Subject: Re: bandwidth and shape/police in MQC
I think BW is the minimum BW guaranteed for the class of traffic in this
case and shaping would be based on interface BW not BW# defined under
policy-map. Please correct if wrong.
On Fri, Jul 3, 2009 at 8:48 AM, Tortle Tang <tortletang_at_hotmail.com> wrote:
> Good explaination.
>
> Thanks your help. Now I am clear.
>
>
>
> Tortle
>
>
>
>
>
> > Wrom:
>
>
AALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCA
X
>
>
ZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGG
M
>
>
EPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCM
H
>
>
VIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYX
O
>
>
EAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZU
N
>
>
NYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNK
M
>
>
BIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZ
R
>
>
CLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZU
I
>
>
VOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKB
R
>
>
NVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHA
A
>
>
LPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZ
O
>
>
WCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGME
P
>
>
YOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHV
I
>
>
BGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOE
A
>
>
IJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNN
Y
>
>
CGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMB
I
>
>
PBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRC
L
>
>
BDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIV
O
>
>
TQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRN
V
>
>
WWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAAL
P
>
>
TCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOW
C
>
>
ONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPY
O
>
>
QKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIB
G
>
>
DADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAI
J
>
>
JPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYC
G
>
>
PKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIP
B
>
>
ARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLB
D
>
>
XRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOT
Q
>
>
NQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVW
W
>
>
CUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPT
C
>
>
XLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCO
N
>
>
EUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQ
K
>
>
EDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGD
A
>
>
DRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJ
P
>
>
HSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGP
K
>
>
YLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBA
R
>
>
HDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDX
R
>
>
QBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQN
Q
>
>
EMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWC
U
>
>
FPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCX
L
>
>
YRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONE
U
>
>
QZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKE
D
>
>
OTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDAD
R
>
>
ZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPH
S
>
>
CRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKY
L
>
>
EJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARH
D
> MNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIG//
> www.ccie.net <http://www.ccie.net/>
> > >
> > >
Received on Sat Jul 04 2009 - 12:58:55 ART
This archive was generated by hypermail 2.2.0 : Sat Aug 01 2009 - 13:10:22 ART