From: Richard Dumoulin (Richard.Dumoulin@vanco.fr)
Date: Fri Feb 11 2005 - 14:31:11 GMT-3
Oh, I have got it. It is not a bug, I knew QOS on the 3550 was strange ...
Actually, when you apply "service-policy input test" on the interface, the
traffic will get policed only when it reaches the outgoing interface !!!!!
I had it configured on Int fas0/13 that's why int fa0/14 had 48K of
utilization :)
I should have known this for the exam though, lol.
-- Richard
CCIE #13891
-----Original Message-----
From: Balaji Siva [mailto:bsivasub@gmail.com]
Sent: Friday, February 11, 2005 6:23 PM
To: Richard Dumoulin
Cc: ccielab@groupstudy.com
Subject: Re: 3550 Policing
Thanks. your config is good.. This is a bug. (you can try shut/no
shut, remove and reapply policy, reload or try another version/ open
up a TAC case )
On Fri, 11 Feb 2005 17:12:40 -0000, Richard Dumoulin
<Richard.Dumoulin@vanco.fr> wrote:
>
>
> 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