Traffic shaping, also known as Quality of Service (QoS), is a means of prioritizing network traffic which meets certain criteria. Without traffic shaping, network traffic is processed on a first-in, first-out (FIFO) basis. While in many cases, processing network traffic in such a way may be adequate, in other cases, it may lead to links becoming saturated, which in turn can lead to buffering and increased latency. Traffic shaping provides us with a means of prioritizing certain network traffic, which guarantees that it will receive available bandwidth before lesser priority traffic.
pfSense has its own traffic shaper which is not only useful, but is also extremely easy to use. The pfSense traffic shaper wizard is easy and quick to configure, and the process of setting up traffic shaping can be done in a matter of minutes. In this chapter, however, it is our objective to provide a basic understanding of traffic shaping before delving into the specifics of how to implement traffic shaping in pfSense. The topics covered in this chapter are as follows:
- Traffic shaping essentials, including a summary of different queuing disciplines
- Configuring traffic shaping in pfSense, including using the pfSense traffic shaping wizard, as well as manual queue and rule configuration
- Some real-world traffic shaping examples
- Troubleshooting traffic shaping
To illustrate how traffic shaping might be implemented on a network, we will again revisit our hypothetical network, which again is divided into several subnets: DEVELOPERS, ENGINEERING, SALES, and DMZ. The company's main Internet connection provides 150 Mbps of bandwidth for downloading and 50 Mbps of bandwidth for uploading. The company also has a backup DSL connection with 7 Mbps down/1 Mbps up. The network has some requirements that require implementing traffic shaping, including the following:
- DEVELOPERS and ENGINEERING should have 100 Mbps of guaranteed download bandwidth, with 60 Mbps of download bandwidth going to DEVELOPERS. For upload bandwidth, 25 Mbps will go to DEVELOPERS and ENGINEERING, with 15 Mbps going to DEVELOPERS. As with download bandwidth, excess will go first to ENGINEERING and then to SALES and DMZ.
- All subnets use Skype for videoconferencing, which requires a low-latency connection. The SALES subnet utilizes videoconferencing the most, so we need to take that into account.
- If possible, all peer-to-peer traffic should be eliminated; if it cannot be eliminated entirely, it should not use more than 5% of the total bandwidth.
We have now outlined some fairly specific requirements for our network. We will implement some of these measures with the pfSense traffic shaper later on in this chapter.
Diagram of our example network showing bandwidth and other requirements.