From: Pierre-Alex (paguanel@hotmail.com)
Date: Fri Jun 02 2006 - 07:25:04 ART
I have the following problem: when applying a policy inbound on a trunk port I
have a discrepency of 40 K. See Verification section.
I do not have the problem when I am classifying via IP addresses. Has anyone
of you observed this? Any fix appart from changing the policing values?
Diagram:
Diagram :
r2 ------trunk -----Switch 1 -----R3
|
R6
r6 is in vlan 26
r3 is in vlan 23
-----------
Task:
R2 is pinging r6 and r3 at line rate with respective precedence of 1 and 5.
Limit traffic to r6 to 500Kb/s and
limit traffic to R3 at 1 Megabit/s. Drop the excess.
----------------
Configuration
mls qos
!
interface FastEthernet0/2
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
service-policy input police-in
mls qos monitor dscp 8 40
class-map match-all cs1
match ip dscp cs1
class-map match-all cs5
match ip dscp cs5
policy-map police-in
class cs1
police 500000 93750 exceed-action drop
class cs5
police 1000000 187500 exceed-action drop
FastEthernet0/2
Ingress
dscp: incoming no_change classified policed dropped (in bytes)
8 : 262354422 51393408 0 0 0
40: 102161400 0 0 0 0
Others: 494922022 445330872 362713564 0 294402306
--------------
Verification
r3#sh policy-map interface
Ethernet0/0
Service-policy input: inbound_measure
Class-map: all_traffic (match-all)
557654 packets, 363809819 bytes
30 second offered rate 1046000 bps
Match: access-group 1
Class-map: class-default (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
r6#sh policy-map interface
Ethernet0/0
Service-policy input: inbound_measure
Class-map: all_traffic (match-all)
878931 packets, 449601296 bytes
30 second offered rate 540000 bps
Match: access-group 1
Class-map: class-default (match-any)
32687 packets, 2457912 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
!NB the policy-map on r3 and r6 do not do any actions. They are there only to
measure incoming traffic.
You can see that the 30 seconds rate is of by about 40K in both cases.
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:31 ART