Quality of Service (QoS) on our LAN switches is often misunderstood. Every now and then people ask me why we need it since we have more than enough bandwidth. If we don’t have enough bandwidth it’s easier to add bandwidth than on our WAN links. If you use any real-time applications like Voice over IP on your networks then you should think about implementing QoS on your switches. Let me show you what could go wrong with our switches. Here’s an example:
Above you see a computer connected to a switch with a gigabit interface. Between SW1 and SW2 there’s also a gigabit interface. Between SW2 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:
In the example above we have 3 computers connected to SW1, SW2 and SW3. These switches are connected to SW4. 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 SW4 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.
No comments:
Post a Comment