How do you disable flow control? Everything I have seen sayd it is impossible.
On Fri, Oct 12, 2012 at 2:26 PM, Blake Dunlap <[email protected]> wrote: > This is flow control. It is a signaling method of an upstream device to > indicate that it cannot service more input data because it's ability to > drain it's input queue is temporarily congested. Generally this is due to > an oversubscribed backplane being full, either the primary backplane of the > device, or the uplink to the backplane that the port shares with other > ports in an oversubscribed manner. > > If you are seeing inputs, it means the device is recieving the pauses, if > you are seeing outputs, it means the device is generating them. > > One of the main downsides of flow control is that it is for the entire > port, which can cause issues for other traffic unrelated to congested > networks. > > Most people disable flow control the first time there is an issue, unless > they specifically want it and understand its issues with it, and suffer the > dropped packets on input, as opposed to stopping all output traffic on the > previous device, which could cause a cascade backwards on the network. That > being said, you still want to fix the underlying issue, which is causing > the pauses to be sent in the first place. > > -Blake > > On Fri, Oct 12, 2012 at 2:05 PM, Jonathan Charles <[email protected]>wrote: > >> We have a Cisco 2921 running 15.2(3T); >> >> We are seeing PAUSE OUTPUT incrementing on the device, and every time it >> does, our users experience pretty nasty jitter and silence on VOIP calls. >> >> The link is 1000BaseLX with a 100MB committed rate; we rarely see more >> than >> 10-15MB of output or input traffic on the interface. >> >> Two questions: >> >> 1 - Who is originating the Pause Outputs? Cisco documentation is silent on >> the subject and TAC has given us conflicting answers. >> 2 - If generated locally, how can we stop them from doing so? The provider >> is saying these are causing the issues we are experiencing. >> >> >> ROUTER#sh int gi0/1 >> GigabitEthernet0/1 is up, line protocol is up >> Hardware is CN Gigabit Ethernet, address is 2894.0fbd.0091 (bia >> 2894.0fbd.0091) >> MTU 1500 bytes, BW 100000 Kbit/sec, DLY 10 usec, >> reliability 255/255, txload 13/255, rxload 17/255 >> Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set >> Keepalive set (10 sec) >> Full Duplex, 1Gbps, media type is LX >> 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 16:53:34 >> Input queue: 1/4096/0/1204 (size/max/drops/flushes); Total output >> drops: 0 >> Queueing strategy: Class-based queueing >> Output queue: 0/1000/0 (size/max total/drops) >> 30 second input rate 6684000 bits/sec, 3871 packets/sec >> 30 second output rate 5105000 bits/sec, 2906 packets/sec >> 87183773 packets input, 3179860385 bytes, 0 no buffer >> Received 0 broadcasts (0 IP multicasts) >> 0 runts, 0 giants, 0 throttles >> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored >> 0 watchdog, 0 multicast, 0 pause input >> 60076680 packets output, 4290590647 bytes, 0 underruns >> 0 output errors, 0 collisions, 0 interface resets >> 0 unknown protocol drops >> 0 babbles, 0 late collision, 0 deferred >> 0 lost carrier, 0 no carrier, 1252219 pause output >> 0 output buffer failures, 0 output buffers swapped out >> ROUTER# >> >> Thanks! >> >> >> >> Jonathan >> _______________________________________________ >> 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/
