Did you try "no fair queue"?
show int s1/3 switching will give more info about drops
a possibility is that this is still related to arp -
arp's are throttled if they come in too heavy, which might
cause a drop, and if you're trying to send IP to an address
where there's no arp, eventually packets will have to be
dropped...
there are a few show commands related to bridging, pick your
debugs.
Is this "bridging irb" or something else?
Of course there's also the "try again with a more recent IOS"...
George
> From cisco-nsp-request@puck.nether.net Thu Mar 22 22:52:46 2001
> Return-Path: <cisco-nsp-request@puck.nether.net>
> Received: from puck.nether.net (root@puck.nether.net [204.42.254.5])
> by mail.netaxs.com (8.8.7/8.8.5) with ESMTP id WAA29539;
> Thu, 22 Mar 2001 22:52:36 -0500 (EST)
> Received: (from slist@localhost)
> by puck.nether.net (8.11.1/8.9.3) id f2N3qau04161;
> Thu, 22 Mar 2001 22:52:36 -0500
> (envelope-from cisco-nsp-request@puck.nether.net)
> Resent-Date: Thu, 22 Mar 2001 22:52:36 -0500
> Received-Date: Thu, 22 Mar 2001 22:50:28 -0500
> Date: Thu, 22 Mar 2001 19:50:26 -0800 (PST)
> From: Joe Pruett <joey@q7.com>
> To: cisco-nsp@puck.nether.net
> Message-ID: <Pine.GSO.4.10.10103221940430.12538-100000@q7.q7.com>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Subject: [nsp] any way to track down output drops?
> Resent-Message-ID: <O0-at.A.m4.Jgsu6@puck.nether.net>
> Resent-From: cisco-nsp@puck.nether.net
> X-Mailing-List: <cisco-nsp@puck.nether.net> archive/latest/5832
> X-Loop: cisco-nsp@puck.nether.net
> Precedence: list
> Resent-Sender: cisco-nsp-request@puck.nether.net
> Status: R
>
> i'm dealing with a t1 frame connection that is doing both straight point
> to point frame, plus bridging for dsl connections. performance is not
> what it should be and i'm trying to get to the bottom of it. the first
> thing i did was crank up the broadcast queue size since arps were getting
> lost. that helped a lot, but now we still see huge numbers of output
> drops even though the circuit isn't saturated. i'm guessing it has
> something to do with bridging, but i haven't found a way to log the
> dropped packets or anything of that sort. any ideas? here are some
> examples of the issue (these were done seconds apart):
>
> Serial1/3 is up, line protocol is up
> Hardware is M4T
> Description: Verizon FR
> MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
> reliability 255/255, txload 84/255, rxload 57/255
> Encapsulation FRAME-RELAY IETF, crc 16, loopback not set
> Keepalive set (10 sec)
> LMI enq sent 18954, LMI stat recvd 18954, LMI upd recvd 0, DTE LMI up
> LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
> LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
> Broadcast queue 0/2048, broadcasts sent/dropped 39587160/105879, interface broadcasts 39693039
> Last input 00:00:00, output 00:00:00, output hang never
> Last clearing of "show interface" counters 2d04h
> Input queue: 0/75/0 (size/max/drops); Total output drops: 8323008
> Queueing strategy: weighted fair
> Output queue: 0/1000/64/8323008 (size/max total/threshold/drops)
> Conversations 0/107/256 (active/max active/max total)
> Reserved Conversations 0/0 (allocated/max allocated)
> 5 minute input rate 345000 bits/sec, 133 packets/sec
> 5 minute output rate 511000 bits/sec, 246 packets/sec
> 17577521 packets input, 388935297 bytes, 369 no buffer
> Received 447523 broadcasts, 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 50441549 packets output, 322006586 bytes, 0 underruns
> 0 output errors, 0 collisions, 1 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 1 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
>
> Serial1/3 is up, line protocol is up
> Hardware is M4T
> Description: Verizon FR
> MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
> reliability 255/255, txload 85/255, rxload 57/255
> Encapsulation FRAME-RELAY IETF, crc 16, loopback not set
> Keepalive set (10 sec)
> LMI enq sent 18954, LMI stat recvd 18954, LMI upd recvd 0, DTE LMI up
> LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
> LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
> Broadcast queue 0/2048, broadcasts sent/dropped 39587259/105879, interface broadcasts 39693138
> Last input 00:00:00, output 00:00:00, output hang never
> Last clearing of "show interface" counters 2d04h
> Input queue: 0/75/0 (size/max/drops); Total output drops: 8323040
> Queueing strategy: weighted fair
> Output queue: 0/1000/64/8323040 (size/max total/threshold/drops)
> Conversations 0/107/256 (active/max active/max total)
> Reserved Conversations 0/0 (allocated/max allocated)
> 5 minute input rate 349000 bits/sec, 134 packets/sec
> 5 minute output rate 515000 bits/sec, 247 packets/sec
> 17577668 packets input, 389013925 bytes, 369 no buffer
> Received 447523 broadcasts, 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 50441809 packets output, 322068311 bytes, 0 underruns
> 0 output errors, 0 collisions, 1 interface resets
> 0 output buffer failures, 0 output buffers swapped out
> 1 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
>
> so 32 drops in a few seconds, but the output queue is empty, and the
> txload is less than 50%. the broadcast drops used to be much worse. at
> this level things seem ok for arp, at least. the config info i'm using
> is:
>
> interface Serial1/3
> description Verizon FR
> bandwidth 1536
> no ip address
> no ip directed-broadcast
> encapsulation frame-relay IETF
> logging event subif-link-status
> logging event dlci-status-change
> frame-relay lmi-type ansi
> frame-relay broadcast-queue 2048 256000 1024
> end
>
> and a sample bridge interface:
>
> interface Serial1/3.100 point-to-point
> no ip directed-broadcast
> no cdp enable
> frame-relay interface-dlci 100 IETF
> bridge-group 1
> bridge-group 1 spanning-disabled
> end
>
> and bridge group 1:
>
> bridge 1 protocol ieee
> bridge 1 subscriber-policy 1
> bridge 1 route ip
> bridge 1 aging-time 3600
>
> and the subscriber-policy:
>
> subscriber-policy 1
> multicast deny
>
> oh, here is the version info:
>
> Cisco Internetwork Operating System Software
> IOS (tm) 7200 Software (C7200-IS-M), Version 12.0(7)XE1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
> TAC:Home:SW:IOS:Specials for info
> Copyright (c) 1986-2000 by cisco Systems, Inc.
> Compiled Fri 04-Feb-00 21:31 by lstringr
> Image text-base: 0x60008900, data-base: 0x60FF4000
>
> ROM: System Bootstrap, Version 12.0(19991120:010612) [nlaw-conn_4xe_ECC 112], DEVELOPMENT SOFTWARE
> BOOTFLASH: 7200 Software (C7200-BOOT-M), Version 12.0(4)XE, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
>
> ipns_core uptime is 2 weeks, 1 day, 2 hours, 19 minutes
> System returned to ROM by reload at 17:27:11 PST Wed Mar 7 2001
> System restarted at 17:28:43 PST Wed Mar 7 2001
> System image file is "slot0:c7200-is-mz.120-7.XE1"
>
> cisco 7206VXR (NPE225) processor with 57344K/8192K bytes of memory.
> R527x CPU at 262Mhz, Implementation 40, Rev 10.0, 2048KB L2 Cache
> 6 slot VXR midplane, Version 2.0
>
> Last reset from power-on
> Bridging software.
> X.25 software, Version 3.0.0.
> 1 FastEthernet/IEEE 802.3 interface(s)
> 4 Serial network interface(s)
> 8 ATM network interface(s)
> 125K bytes of non-volatile configuration memory.
>
> 20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
> 4096K bytes of Flash internal SIMM (Sector size 256K).
> Configuration register is 0x2102
>
> any clues or pointers would be great. i am hoping it is something simple
> i've overlooked.
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:33 EDT