SPAN - Total output drops

[gsancassano]

Hi,

In a SPAN port the “Total output drops:” increases and the output rate of the interface is about 50% of the capacity of the interface.

In this sapn port I have connected a Cisco IPS 4260

Which can be the reason of this drops?

Here is the output of the show int gi1/16 taken in an interval of 5 minutes aprox.

GigabitEthernet1/16 is up, line protocol is down (monitoring)

  Hardware is C6k 1000Mb 802.3, address is 000d.659b.d9af (bia 000d.659b.d9af)

  Description: SPAN

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

     reliability 255/255, txload 127/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, media type is SX

  input flow-control is off, output flow-control is on

  Clock mode is auto

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input never, output never, output hang never

  Last clearing of "show interface" counters 45w2d

  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 377759771

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  30 second input rate 0 bits/sec, 0 packets/sec

  30 second output rate 499595000 bits/sec, 102516 packets/sec

     93 packets input, 10087 bytes, 0 no buffer

     Received 2 broadcasts (0 multicasts)

     49 runts, 0 giants, 0 throttles

     49 input errors, 49 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 0 multicast, 0 pause input

     0 input packets with dribble condition detected

     2088884366664 packets output, 1299326687351291 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     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

GigabitEthernet1/16 is up, line protocol is down (monitoring)

  Hardware is C6k 1000Mb 802.3, address is 000d.659b.d9af (bia 000d.659b.d9af)

  Description: SPAN

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

     reliability 255/255, txload 153/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, media type is SX

  input flow-control is off, output flow-control is on

  Clock mode is auto

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input never, output never, output hang never

  Last clearing of "show interface" counters 45w2d

  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 378103638

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  30 second input rate 0 bits/sec, 0 packets/sec

  30 second output rate 603711000 bits/sec, 111390 packets/sec

     93 packets input, 10087 bytes, 0 no buffer

     Received 2 broadcasts (0 multicasts)

     49 runts, 0 giants, 0 throttles

     49 input errors, 49 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 0 multicast, 0 pause input

     0 input packets with dribble condition detected

     2088967996703 packets output, 1299379856156896 bytes, 0 underruns

     0 output errors, 0 collisions, 2 interface resets

     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

Thanks in advance.

[rakhande]

Hi,

Total output drops would not just depend upon the bandwidth and traffic rate on this interface. Look at what cisco says about these drops -

Total output drops - The number of packets dropped because the output          queue is full. A common cause of this might be traffic from a high bandwidth          link being switched to a lower bandwidth link or traffic from multiple inbound          links being switched to a single outbound link. For example, if a large amount          of bursty traffic comes in on a gigabit interface and is switched out to a          100Mbps interface, this might cause output drops to increment on the 100Mbps          interface. This is because the output queue on that interface is overwhelmed by          the excess traffic due to the speed mismatch between the inbound and outbound          bandwidths.

So, you would need to update what are the incoming interfaces, configurations of all interfaces including gig1/16.

How is the stats on the other end of gig1/16 and what is the config there?

- Rahul

[gsancassano]

Rahul,

Thank for the reply.

I think that may problem is that I have large amount of bursty traffic going out the sapn port because I have configure the monitoring of 8 vlan aprox, and the buffer is so little that can’t handle all the bursty traffic.

There is a way to see or monitor de bursty traffic?

Thanks again.

[Edison Ortiz]

The aggregate bandwidth from all source SPAN ports can't be greater than the destination SPAN port - if that's the case - oversubscription will occur.

Depend on the hardware in question, you may be facing oversubscription in the Fabric Channel, Replication Engine or Forwarding Engine as well.

You need to modify the list of the source SPAN ports to meet the bandwidth available on the destination SPAN port.

Regards,

Edison