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 (weighted fair queuing), but it's making certain assumptions as to what 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 QoS 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 larger link between the buildings, or stop sending so much data.

What we can use QoS to do is determine more specifically what packets should and should not be dropped. (See Chapter 29 and Chapter 30 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 larger 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 ...

Get Network Warrior now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.