Network Warrior, 2nd Edition

Resolving the Problem

So, what do we do? Can QoS save the day? Well, yes and no. QoS is, in fact, already running on the link (WFQ), but it’s making certain assumptions as to which traffic should be prioritized. WFQ is also only running in one direction (luckily, the direction in which we need it to be running, which is the direction that most of the data is flowing).

We’ve already talked about what QoS cannot do. One of the big things that it cannot do is resolve a need for more bandwidth. This link is clearly in need of a larger pipe, because we’re dropping more than 10 percent of all packets sent from Building A to Building B. In this case, the only ways to prevent these packets from being dropped is to install a faster link between the buildings or stop sending so much data.

What we can use QoS to do is determine more specifically which packets should and should not be dropped. (See Chapters 31 and 32 for more information on designing a QoS scheme.)

Let’s clear those counters now, so that the next time we look we’ll have some fresh data:

Bldg-A-Rtr#clear counters s0/0
Clear "show interface" counters on this interface [confirm]

And on the other side as well:

Bldg-B-Rtr#clear counters s0/0
Clear "show interface" counters on this interface [confirm]

If you think you need a faster link, you will need to collect some real data to support your case. When you approach management with your concerns, having information similar to what I’ve shown you in this chapter will help justify the expense ...