Re: Question about problem with FireQos

Hi Man,

From:
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/12027-53.html

Deferred Frames (Out-Lost or Out-Discard)

If you have a large number of deferred frames, or Out-Discard (also
referred to as Out-Lost on some platforms), it means that the switch's
output buffers have filled up and the switch had to drop these packets.
This can be a sign that this segment is run at an inferior speed and/or
duplex, or there is too much traffic that goes through this port.

*Inferior Speed/Duplex for the Amount of Traffic*

Your network can send too many packets through this port for the port to
handle at its current speed/duplex setting. This can happen where you have
multiple high-speed ports flowing to a single (usually slower) port. You
can move the device that hangs off this port to faster media. For example,
if the port is 10 Mbps, move this device to a 100 Mbps or Gigabit port. You
can change the topology to route frames differently.

*Congestion Issues: Segment Too Busy*

If the segment is shared, other devices on this segment can transmit so
much that the switch has no opportunity to transmit. Avoid daisy-chained
hubs whenever possible. Congestion can lead to packet loss. Packet loss
causes retransmissions at the transport layer which in turn causes users to
experience latency at the application level. You can upgrade10Mbps links to
100Mbps or Gigabit Ethernet links when possible. You can remove some
devices from crowded segments to other less populated segments. Make
congestion avoidance a priority on your network.

*Applications*

At times the traffic transmission characteristics of the applications used
can lead to output buffer problems. NFS file transfers that come from a
Gigabit attached server that uses user datagram protocol (UDP) with a 32K
window size is one example of an application setting that can bring out
this type of problem. If you have checked or tried the other suggestions in
this document (checked speed/duplex, no physical errors on the link, all
the traffic is normal valid traffic, and so on), then reducing the unit
size that is sent by the application can help alleviate this problem.


To my understanding (given that I am not a layer 2 expert), Linux QoS
should not trigger drops at a switch. It might fill the buffers of a router
in your path, but should not have any effect at a switch.

Have you tried disabling QoS to check if the discards still appear?

If this happens only when QoS is enabled, I'll need some more info:


1. The link speed of the interface

2. fireqos.conf for the inbound traffic of the wan interface


Costa



On Sat, Mar 5, 2016 at 12:03 AM, mbaldov <[email protected]> wrote:

> HI Costa and all other guys!
>
> I'm using FireQos for my infrastructure from 1 year. It's great tool for
> traffic shaping but I have found a serious problem that I will try to
> describe.
>
> I've the following scenario:
>
>
> INTERNET....ROUTERS----SWITCH---(wan)---FIREQOS---(lan)---SWITCH---FIREWALL----LAN
>
> In case of elevated traffic in incoming (from wan to lan) towards a series
> of IP/PORTS intended for the default class, the switch (pair of  Cisco
> WS-C3750G-24TS-S1U in stack) produces OUTDISCARDS errors on the "lan" port
> of the switch where it is linked fireqos, starting to lose packets to all
> destinations that pass through that port also of other classes and
> directions, even if the available bandwidth input is much higher than that of
> the packets that you are receiving.
>
> Any suggestion regards this behavior?
>
> Waiting for a kind reply.
>
> Regards,
> Man
>
>
>
>
_______________________________________________
Firehol-support mailing list
[email protected]
http://lists.firehol.org/mailman/listinfo/firehol-support