From: Richard Dumoulin (Richard.Dumoulin@vanco.fr)
Date: Fri Feb 11 2005 - 17:42:09 GMT-3
Well, it is ingress policing but you see the bandwidth it takes in the
output interfaces, when the traffic goes out (show interface fast0/13).
You also can see what happens in the ingress with the other command (show
mls qos int fast0/14 statistics). Make sense? It is a bit different from a
router though,
-- Richard
-----Original Message-----
From: boby2kusa [mailto:boby2kusa@hotmail.com]
Sent: Friday, February 11, 2005 7:13 PM
To: Richard Dumoulin
Cc: ccielab@groupstudy.com
Subject: Re: 3550 Policing
I have to disagree. It does not make sense that an ingress policing will
police it on egress. There is something wrong, I am not sure what though.
----- Original Message -----
From: "Richard Dumoulin" <Richard.Dumoulin@vanco.fr>
To: "Balaji Siva" <bsivasub@gmail.com>
Cc: <ccielab@groupstudy.com>
Sent: Friday, February 11, 2005 9:31 AM
Subject: RE: 3550 Policing
> 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