Is this the only traffic going through this 7200? How is your scheduler allocate set on the 7200, have you tried a new cable and cleaning the optics?
Kind regards, Sibbi On 23.5.2012 19:33, "[email protected]" <[email protected]> wrote: >Hi, > >thanks all for the input. > >Increasing the hold-queue (from default to 100) doesn't seem to help at >all: > >GigabitEthernet0/1 is up, line protocol is up > Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81b (bia >0006.52f4.d81b) > Internet address is x.x.x.x/28 > MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, > reliability 255/255, txload 1/255, rxload 2/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX > output flow-control is XON, input flow-control is XON > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters 02:17:11 > Input queue: 0/100/742/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 10536000 bits/sec, 1824 packets/sec > 5 minute output rate 6813000 bits/sec, 2121 packets/sec > 11770910 packets input, 2922271410 bytes, 0 no buffer > Received 215 broadcasts, 0 runts, 0 giants, 0 throttles > 341 input errors, 0 CRC, 0 frame, 341 overrun, 0 ignored > 0 watchdog, 4242 multicast, 0 pause input > 0 input packets with dribble condition detected > 14975201 packets output, 1820911878 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 137 unknown protocol drops > 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 > >Will go from 100 to 150 and see whats happen. > > > >On Wed, May 23, 2012 at 9:27 PM, Phil Mayers <[email protected]> >wrote: >> On 05/23/2012 08:18 PM, Chris Gotstein wrote: >>> >>> %Warning: portfast should only be enabled on ports connected to a >>>single >>> host. Connecting hubs, concentrators, switches, bridges, etcŠ to this >>> interface when portfast is enabled, can cause temporary bridging loops. >>> >>> My understanding of this was a router would be included as well since >>> it's used to connect multiple hosts. >> >> >> If you don't enable portfast, you have to suffer the STP state >>transitions, >> which lead to delays in traffic forwarding after link-up. >> >> Portfast basically means: "This port is unlikely to be connected to >>another >> bridge or hub, so skip the LISTENING/LEARNING transitions and jump >>straight >> to forwarding; if it goes wrong, STP will close the loop shortly." >> >> It's not magic; and it should be enabled on all host ports. Routers are >> hosts, at layer2. >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > >_______________________________________________ >cisco-nsp mailing list [email protected] >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
