[c-nsp] Dropped packets

Thu Jun 16 13:30:13 EDT 2005

Ooo, intresting.
That would give some very intresting counter readings.

Thanks for the tip. 
I wouldnt submit it though, taking your credit. :)

Thanks
/Fredrik

-----Original Message-----
From: Rodney Dunn [mailto:rodunn at cisco.com] 
Sent: Thursday, June 16, 2005 7:15 PM
To: Fredrik.Jacobsson at enskilda.se
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Dropped packets

I've been meaning to submit this as a tech tip to the Packet
Reader magazine. You have my permission to do it if it helps. :)

Configure a policy that has policing with conform action transmit
exceed action transmit:

policy-map whydrop
 class class-default
   police 1300000 conform-action transmit  exceed-action transmit 

then apply it to the interface out and do:

100_#sh run int se 2/0
Building configuration...

Current configuration : 128 bytes
!
interface Serial2/0
 no ip address
 shutdown
 serial restart-delay 0
 no clns route-cache
 service-policy output whydrop
end

100_#sh policy-map int serial 2/0
 Serial2/0 

  Service-policy output: whydrop

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 
      police:
          cir 1300000 bps, bc 46875 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit 
        exceeded 0 packets, 0 bytes; actions:
          transmit 
        conformed 0 bps, exceed 0 bps
100_#

Watch for exceed packets.

The granularity of the policer to detect burst is much greater than
some 30 second average in 'sh int'.

Most likely it's a burst from your LAN that is short lived.

Rodney

On Thu, Jun 16, 2005 at 06:48:45PM +0200, Fredrik.Jacobsson at enskilda.se
wrote:
> Hi!
> 
> Hoping that someone can point me in the right direction...
> I have two 2811 at a site. Each has one T1-interface (WIC-1T) for leased
> line
> wan-connection to HQ. (they also have a two-port T1 MFT-card each for
phone
> services)
> 
> Lately I've gotten output drops on both routers, even when we dont have
> enough traffic to fill the buffers.
> Perhaps like 10% bandwith usage, and still drops.
> 
> >sho int ser 0/0/0
> Serial0/0/0 is up, line protocol is up 
>   Hardware is GT96K Serial
>   Description: Blablabla
>   Internet address is x.x.x.x/30
>   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, 
>      reliability 255/255, txload 14/255, rxload 1/255
>   Encapsulation PPP, LCP Open
>   Open: IPCP, loopback not set
>   Keepalive set (10 sec)
>   Last input 00:00:28, output 00:00:00, output hang never
>   Last clearing of "show interface" counters 2d03h
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
607494
>   Queueing strategy: weighted fair
>   Output queue: 0/1000/64/607494 (size/max total/threshold/drops) 
>      Conversations  0/18/256 (active/max active/max total)
>      Reserved Conversations 0/0 (allocated/max allocated)
>      Available Bandwidth 1158 kilobits/sec
>   5 minute input rate 0 bits/sec, 63 packets/sec
>   5 minute output rate 881000 bits/sec, 91 packets/sec
>      11730227 packets input, 91596 bytes, 0 no buffer
>      Received 0 broadcasts, 0 runts, 1 giants, 0 throttles
>      3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored, 3 abort
>      8842506 packets output, 3950408912 bytes, 0 underruns
>      0 output errors, 0 collisions, 3 interface resets
>      0 output buffer failures, 0 output buffers swapped out
>      0 carrier transitions
>      DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
> 
> Any suggestions for further troubleshooting is highly appreciated.
> 
> Interface configuration looks like this:
> interface Serial0/0/0
>  description Blablabla
>  bandwidth 1544
>  ip address x.x.x.x 255.255.255.252
>  encapsulation ppp
>  no cdp enable
> 
> I'm thinking the drops may have been introduces with the command:
> network-clock-select 1 T1 0/1/0
> So I'm going to revert back to the old setting tonight.
> But then we get slip-errors on the MFT-interfaces, so it's not the way to
go
> for a permanent solution.
> 
> What, other than full usage of the available bandwith, may cause drops?
> Any suggestions? cpu-usage is ok. we're (of course) using cef.
> Were encrypting all wan-traffic. Would problems there be indicated by the
> output drops counter on the interface? I think not.
> 
> We're currently using 12.3(11)T3
> 
> Thanks
> /Fredrik Jacobsson
> 
> 
> 
> 
> 
>
****************************************************************************
******************************************
> Confidentiality Notice
> 
> The content of this message, including attachments, is intended for the
confidential use of the individual(s) or entity(-ies) to whom it is
addressed only and may contain personal and/or confidential information.
Please notify the sender immediately by returning this message if you are
not the intended recipient. If you are not the intended recipient, you are
hereby notified that you have received this communication in error and that
reading, duplicating, or in any way disseminating its content to any other
person, is strictly prohibited.
> 
> If the content of this message, including attachments, includes an offer
to provide any service or product, an offer or a solicitation of an offer to
buy or sell any securities or any other investment product, please refer to
the disclaimer on www.enskilda.se, which applies also to the content of this
message. Any such transaction will also be subject to any other Terms of
Business currently in place between us.
> 
> If you are a client of Enskilda Securities with access to Enskilda
Research Online and this message contains a research report or the content
of this message, including attachments, may be regarded as an advice in
relation to companies or securities, please refer to the general and company
specific disclaimers, respectively, on Enskilda Research Online.
>
****************************************************************************
******************************************
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

**********************************************************************************************************************
Confidentiality Notice

The content of this message, including attachments, is intended for the confidential use of the individual(s) or entity(-ies) to whom it is addressed only and may contain personal and/or confidential information. Please notify the sender immediately by returning this message if you are not the intended recipient. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that reading, duplicating, or in any way disseminating its content to any other person, is strictly prohibited.

If the content of this message, including attachments, includes an offer to provide any service or product, an offer or a solicitation of an offer to buy or sell any securities or any other investment product, please refer to the disclaimer on www.enskilda.se, which applies also to the content of this message. Any such transaction will also be subject to any other Terms of Business currently in place between us.

If you are a client of Enskilda Securities with access to Enskilda Research Online and this message contains a research report or the content of this message, including attachments, may be regarded as an advice in relation to companies or securities, please refer to the general and company specific disclaimers, respectively, on Enskilda Research Online.
**********************************************************************************************************************