QoS on LAN switches
In a LAN enviroment the links has high bandwidth at no extra cost, everything is running at 1Gb or 10Gb. It is normal to think QoS configuration is not necessary. If real-time applications such as Voice over IP on your networks then it is necessary to implementi QoS on the switches. Let me show you what could go wrong with our switches.
Above you see a computer connected to Switch with a Gigabit interface. Between Switch A and Switch B there’s also a gigabit interface. Between Switch B and the server there’s only a FastEthernet link. In the picture above the computer is sending 400 Mbps of traffic towards the server. Of course the FastEthernet link only has a bandwidth of 100 Mbps so traffic will be dropped. Another example of traffic drops on our switches is something that might occur on monday morning when all your users are logging in at the same time. Let me show you a picture:
qos3
In the example above we have 3 computers connected to Switch A, B and C. These switches are connected to Switch D. It’s monday morning and all users are connecting to the server to log in. The traffic rate for each computer is about 70 Mbps. 3x 70 Mbps = an aggregated traffic rate of 210 Mbps which is more than the Fa0/0 interface of Switch D can handle. As a result the buffer will be full and traffic is dropped. Is this a big problem that our traffic is dropped?
If this is a pure data network it wouldn’t be much of a problem because most traffic is TCP based. We can do retransmissions and besides that things are a bit slower it will work. If we use real-time applications like voice over IP or a video conference stream we want to avoid this as it will directly impact the quality of our voice conversation or video stream.
In the Voice over IP world we use a DSP (Digital Signal Processor) to convert analog audio to digital and vice versa. These DSPs are able to rebuild about 30ms of audio without noticing it. Normally we will use about 20ms of audio in a single packet which means that only a single packet can be dropped or our voice quality will be degraded.
It’s impossible to fix these problems just by adding more bandwidth. By adding more bandwidth you can reduce how often congestion happens but you can’t prevent it completely. A lot of data applications will try to consume as much bandwidth as possible so if the aggregated traffic rate exceeds one of your uplink ports you will see congestion.
By configuring QoS we can tell our switches what traffic to prioritize in case of congestion. When congestion occurs the switch will keep forwarding voice over IP traffic (up to a certain level that we configure) while our data traffic will be dropped.
In short, bandwidth is not a replacement for QoS. Using QoS we can ensure that real-time applications keep working despite (temporarily) congestions.