IEEE 802.3x FlowControl between Cat3750E and Cat2960

René Jorissen on October 23, 2008 1 Comment • Tags: #2960 #3750 #3750e #8023x #catalyst #cisco #congested #control #flow #flowcontrol

I have a network with two Catalyst 3750E switch stacks, which are connected with a 2 x 10Gbps Etherchannel. Every stack facilitates a ring topology of approximately 10 to 15 Catalyst 2960 switches. Two of the 2960 are connected with 1Gbps links to a switch stack to create the ring topology. So lets say that 7 24-ports Catalyst 2960 switch share a 1 Gbps link to the switch stack. With this customer, this won’t be any problem, because there are no heavy users and/or applications.

But let’s imagine that a link between a Catalyst 3750E and Catalyst 2960 switch or between two Catalyst 2960 switches is giving problems and the Catalyst 2960 cannot handle the receiving traffic. You need to find some way to slow done the traffic. I normally start thinking about the usage of IEEE 802.3x FlowControl.

Flow control enables connected Ethernet ports to control traffic rates during congestion by allowing congested nodes to pause link operation at the other end. If one port experiences congestion and cannot receive any more traffic, it notifies the other port by sending a pause frame to stop sending until the condition clears. Upon receipt of a pause frame, the sending device stops sending any data packets, which prevents any loss of data packets during the congestion period.

But after reading some documentation, FlowControl isn’t an option. When a link between both switches gets congested the Catalyst 2960 would have to send a pause frame to the Catalyst 3750E and that’s the problem.

Both, Catalyst 3750E and Catalyst 2960, can only receive, but not send, pause frames. So configuring FlowControl between Catalyst 3750E and Catalyst 2960 is useless, because no switch can inform the counterpart about the congested link.

The following two tabs change content below.

René Jorissen

Co-owner and Solution Specialist at 4IP Solutions
René Jorissen works as Solution Specialist for 4IP in the Netherlands. Network Infrastructures are the primary focus. René works with equipment of multiple vendors, like Cisco, Aruba Networks, FortiNet, HP Networking, Juniper Networks, RSA SecurID, AeroHive, Microsoft and many more. René is Aruba Certified Edge Expert (ACEX #26), Aruba Certified Mobility Expert (ACMX #438), Aruba Certified ClearPass Expert (ACCX #725), Aruba Certified Design Expert (ACDX #760), CCNP R&S, FCNSP and Certified Ethical Hacker (CEF) certified. You can follow René on Twitter and LinkedIn.

Latest posts by René Jorissen (see all)

  1. I think the point is that a 2960 never has to send a pause frame bacause its ingress queue never fills. It can ship the received traffic across its switching fabric at line rate.

    The problem with these switches, and also the 3750, is not the ingress queue, but the egress queues. You can have one or many ingress ports, all sending received traffic across the switching fabric at line rate to the egress port, which queues the traffic for transmission. It is there that the congestion occurs, which is why you often see output discards on these switches.

    Unfortunately, the egress port has no way to signal to the ingress ports that it is congested. If it did, it would have to pause all the ingress ports, so you would have head-of-line blocking. So that is why the ingress port would never have to send a pause frame, even if it could. The only option the egress port has is to discard.

    The Nexus, on the other hand, does the opposite: it has its congestion queue on the ingress port, and holds from shipping the frame across the switching fabric until the egress port is able to handle it.

    Kevin Dorrell
    CCIE #20765

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.