From: Balaji Siva (bsivasub@gmail.com)
Date: Fri Feb 11 2005 - 17:45:28 GMT-3
From your initial output, you had it applied it on fas0/14 and so your
output was incorrect like we commented.
Ofcourse if you are saying now you applied on fas0/13, then the output
is correct on fas 0/14 as the traffic egress is the rate-limited
traffic.
On Fri, 11 Feb 2005 20:42:09 -0000, Richard Dumoulin
<Richard.Dumoulin@vanco.fr> wrote:
> 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