WFQ On High Speed Link

[svermill]

All,

Would you be so kind as to share your thoughts/experience with WFQ on high speed links? I know that Cisco generally considers it to be unnecessary on links greater than 2 Mbps.

I have a client with a 16 Mbps HSSI connection between 3640 routers. The config has been in place for a long time. However, the circuit does not seem to support the throughput that they should be getting. I finally got them to share a copy of the config file. Not only is WFQ enabled, but the congestive discard value was left at a default 64 messages.

I am wondering if this is just unnecessary or if it is/can be detrimental? As I said, there are indications that there are throughput issues.

Please note that I am just looking for comments. Unfortunately, I have never had my hands on any of their equipment (yet). Thus, I have no debug or even visual observations to offer. All of my information is third party. Just trying to understand the wisdom of using WFQ in this environment.

Many thanks,

Scott

[dbroenen]

What kinds of traffic are traversing this link? What encapsulation are they using? How are you determining that "the circuit does not seem to support the throughput they should be getting"? (Note: features enabled, CPU load, packet load, fragmentation, switching paths and other considerations could factor into this issue.) Also, please include the interface config from show run and output from show interface [number] fair-queue and show interface. Once you've posted this information, myself and others can give you a better idea where the root of the throughput problem could be. Cheers.

[svermill]

David,

Many thanks for responding. Once I get into a position of being able to access the command line, I'll probably do OK with the troubleshooting (but I'll certainly drop you a line if not). I was really just hoping for general comments on the overall wisdom of enabling what I would suspect to be processor intensive management of WFQ at such high data rates. The data flow is a reliable multicast that is managed on Onyx processors hanging off of the ethernet interface of each router (multicast is not enabled on any of the routers as this is a proprietary implementation that does not make use of the 224.0.0.0 address space but rather duplicates unicasts to geographically dispersed users with dedicated WAN connectivity for that purpose). The size of the multicast flow is user selectable in discrete ~2Mbps steps. However, again being on the outside of third party information, it isn't clear to me whether increasing the size of the multicast creates a new flow with new port numbers for each step or if the existing flow with the existing port numbers just increases. It would be, in my opinion, especially silly to be burdening the processor with WFQ for what amounts to a single flow. Even if multiple flows are generated, they would each be exactly equal in throughput (~2Mbps). So I just can't see the value in this.

The observed throughput problem is that numerous retransmissions are being logged on the processors when the user-selected multicast size exceeds a certain value. So many retransmissions, in fact, that the entire multicast is being killed (this fact further leads me to believe that WFQ is only seeing a single flow). That certain "crash" value, I'm told, is well below the 16 Mbps connection (like maybe less than 10Mbps).

This is a very simple point-to-point config. The only process that is enabled is WFQ. Here is the HSSI setup:

interface Hssi0/0

bandwidth 15000

ip address 10.0.0.4 255.0.0.0

no ip redirects

load-interval 30

no keepalive

fair-queue 64 256 281

Many thanks and best regards,

Scott

[6mmarinzulich]

Scott, regarding your original question, FQ must be disable in links greater than 2M because FQ identify all flows and assign an individual queue to each one. After that FQ assign high priority to low traffic flows.

The issue is: when you have high-speed interfaces; a lot of flows will come into the interface. So FQ will need to identify all these flows and manage their priorities. If you have too many flows, FQ will highs your CPU and will insert delay in your packets.

The immediate solution to this problem is Class Based Weighted Fair Queuing, where you’ll define statically flows. Creating statically a reduced number of flows will enable to apply FQ algorithm to high-speed interfaces.

Matias.-

[svermill]

Matias,

I will look into CBWFQ per your suggestion. Thank you very much. It isn't clear to me that there are numerous flows since there is only a single host on either side of the link, but I can't say for sure until I get my hands on the CLI. The multicast implementation isn't a standards-based one so I don't yet know how the flows are created. In any case, I'll be ready with an alternative if queuing remains as a necessesity.

Regards,

Scott