From: Richard Dumoulin (Richard.Dumoulin@vanco.fr)
Date: Fri Feb 11 2005 - 14:12:40 GMT-3
Actually when I type the command
35550LabCons8#sh mls qos int fa 0/14 statistics
FastEthernet0/14
Ingress
dscp: incoming no_change classified policed dropped (in bytes)
0 : 643615174 643615174 0 0 640592964
Others: 2086369444 2086369444 0 0 1761236966
Egress
dscp: incoming no_change classified policed dropped (in bytes)
0 : 3016266 n/a n/a 0 0
Others: 258929999 n/a n/a 0 0
It is really showing input drops !
Siva, it is really policing. When I issue no service output test, see the
result,
35550LabCons8#sh int fa 0/14
FastEthernet0/14 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000f.3459.e800 (bia 000f.3459.e800)
Internet address is 1.1.1.2/30
MTU 1504 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 6/255, rxload 22/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:17, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 8868000 bits/sec, 730 packets/sec
30 second output rate 2586000 bits/sec, 214 packets/sec
2058405 packets input, 3123912335 bytes, 0 no buffer
Received 82 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 82 multicast, 0 pause input
0 input packets with dribble condition detected
183842 packets output, 278338022 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
-- Richard
-----Original Message-----
From: Balaji Siva [mailto:bsivasub@gmail.com]
Sent: Friday, February 11, 2005 6:03 PM
To: Richard Dumoulin
Cc: ccielab@groupstudy.com
Subject: Re: 3550 Policing
can you remove that policy and do a show int again (after 30 seconds)
? I just want to make sure it is really policed. You can also show
policy int <id> to see if it is really policed.
anyway, if it is really doing that way, it is probably a bug ..you can
just reload it to see if it fixes it or upgrade to latest version or
open a TAC case for capturing anything needed to fix the problem.
But please do a sanity check as I stated above.
Thanks
Balaji
On Fri, 11 Feb 2005 16:38:50 -0000, Richard Dumoulin
<Richard.Dumoulin@vanco.fr> wrote:
> Hi group,
>
> Anyone could please tell me what is going wrong here? (me or the switch?)
> I apply a policy in the input direction of the interface of my 3550 but
> actually it is the output traffic that is policed !!!
>
> 35550LabCons8# sh run int fa 0/14
> Building configuration...
>
> Current configuration : 187 bytes
> !
> interface FastEthernet0/14
> no switchport
> ip address 1.1.1.2 255.255.255.252
> load-interval 30
> service-policy input test
> end
>
> 35550LabCons8#sh mls qo
> 35550LabCons8#sh mls qos int fa 0/14
> FastEthernet0/14
> Attached policy-map for Ingress: test
> trust state: not trusted
> trust mode: not trusted
> COS override: dis
> default COS: 0
> DSCP Mutation Map: Default DSCP Mutation Map
> trust device: none
>
> 35550LabCons8#sh poli
> 35550LabCons8#sh policy-map test
> Policy Map test
> class test
> police 48000 8000 exceed-action drop
>
> 35550LabCons8#sh int fa 0/14 | in second
> 30 second input rate 10333000 bits/sec, 851 packets/sec
> 30 second output rate 48000 bits/sec, 4 packets/sec
>
> Thanks
>
> -- Richard
>
> **********************************************************************
> Any opinions expressed in the email are those of the individual and not
necessarily the company. This email and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are
not the intended recipient or the person responsible for delivering it to
the intended recipient, be advised that you have received this email in
error and that any dissemination, distribution, copying or use is strictly
prohibited.
>
> If you have received this email in error, or if you are concerned with the
content of this email please e-mail to: e-security.support@vanco.info
>
> The contents of an attachment to this e-mail may contain software viruses
which could damage your own computer system. While the sender has taken
every reasonable precaution to minimise this risk, we cannot accept
liability for any damage which you sustain as a result of software viruses.
You should carry out your own virus checks before opening any attachments to
this e-mail.
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Thu Mar 03 2005 - 08:51:19 GMT-3