[c-nsp] Pause Output on interface...

[Jonathan Charles]

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 <ikiris at gmail.com> 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 <jonvoip at gmail.com>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  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>