CompTIA Network+ N10-008 – Network Availability

1. High Availability Networks

High Availability. So when we talked about the CIA Triad, we talked about confidentiality, integrity, and availability. And at that time, I said we would spend a lot of time on availability. Well, this entire section is going to cover availability. Now, when we talk about high availability, we’re talking about making sure that our systems are up. Availability is measured by what we call “up time,” or how many minutes or hours you are up. And often, this will be shown as a percentage. How many minutes were you up, divided by the total minutes available in that period? Now, we try to maintain what’s called the “five nines” of availability on most commercial networks. And this is really hard because this is 99.99% or a maximum of 5 minutes of downtime per year, which is not a whole lot of downtime.

Now, as you can imagine, I need more than 5 minutes of downtime to be able to patch my servers, install a new hard drive, or put in a new router or switch. So how can I maintain that high level of availability? Well, I’m going to do that by designing my networks to be highly available. We’ll talk about that in this lecture. Now, I want you to be familiar with two terms: availability and reliability. When I talk about availability, I mean being up and operational. When I talk about network reliability, I’m concerned about not dropping packets. So if your network is highly available but not reliable, that’s not a very good network. But conversely, if you have a highly reliable network but not a highly available one, it may be the most reliable network in the world, but if it’s only up for 20 minutes a year, that’s not very good either. So we need to balance these two and aim for good in both areas. Now, when we talk about high availability, there are two big terms that you want to consider. And when you start buying components, you want to think about these two terms. It’s MTTR and MTBF.

MTTR stands for “mean time to repair.” This measures the average time it takes to repair a network device when it breaks, because everything breaks eventually. Now, how long does it take, and how long are you going to be down for? That’s really the concern here. The second is known as the “mean time between failures,” or “MTBF.” This is going to measure your average time between failures on a device. So now that may sound a little confusing. So I have a diagram here to show you. If you have a system failure, the time between stopping and restarting normal operations is the time to repair. If I average what that time to repair is over the entire year, that would give me my mean time to repair. Now, the time between one failure and then fixing it and then the next failure becomes my time between failures, or my mean time between failures. When I average that over all of the cases, You can see how there’s this difference here. When it comes time to repair, you want a lower figure. The better the network, the shorter the mean time to repair. Now, when you talk about “the meantime” between failures, you want that to be really long. And so the longer you wait between failures, the better your network.

Now, how do we design these networks to be highly reliable, highly redundant, and highly available? Well, we add redundancy. Now, redundant networks can be done with single points of failure or with no common points of failure. Now, in this diagram, you can see the single point of failure. What is it? It’s the router. That’s right. So in this case, I have two switches and two connections. So I have some link redundancy there. I also may have internal hardware redundancy, like two power supplies and two network cards. But I still only have one router. And so if that router goes down, this entire network is going to stop. That’s a single point of failure. Instead, I could design it this way. I have two PCs that want to talk to each other. Each of them has dual network interface cards talking to two different switches. Each of those switches talks to two different routers, so everything is connected to everything else. That gives me multiple connections between each device and gives me link redundancy and component redundancy between switches and routers. And even inside those, I may have two network cards, two network cards, and two power supplies. And you can see how this rebuilds a very redundant and high-availability network. Now, if one of those routers needs to be upgraded, I can take one offline while the other one holds the load, then put the second one back in and upgrade the other one. And we can do this active standby thing where one takes the load while the other rests.

Now, when we talk about that, that brings us to hardware redundancy. Inside these devices, we can have hardware redundancy, or the devices themselves can be hardware redundant. In the last diagram, I had two routers serving the same function; that’s hardware redundancy. But I could also have hardware redundancy in components by having two network cards, two hard drives, or two internal power supplies. If one fails, the other can take over. This is often found in strategic network devices like switches, routers, servers, and firewalls because you can’t afford a failure on one device to take down your whole network. But if I’m talking about your laptop, I may only have one hard drive. If your laptop goes down, I would just have to deal with that downtime, get you a new laptop, and bring you back up. So when we deal with clients, we often don’t deal with redundancy, but when you get to servers and the routers and switches above them, you’re going to start having hardware and component redundancy. Now, when we deal with this redundancy, we usually have to put it in what’s called an “active,” “active,” or “active standby” configuration. Let’s assume I have this one computer down here at the bottom, and I have two network interface cards on it.

Do I talk to both routers at the same time? Well, if I’m active, both Nicks and both NetworkInterface cards are active at the same time. They each have their own Mac address, and they’re both talking out at the same time to either of those routers. Now, with active standby, I have a primary and a backup network interface card, so only one of them would be active at a time. So I’ll talk to the router on the left, and if that card fails, I’ll switch to the one on the right. Both cards work together and have a single Mac address that they display to the network so that they look like a single device that’s in active standby. Now, when we get into layer three and we start dealing with routers, we start having to deal with redundancy there as well. Our clients are configured with a default gateway, which is our router by default. If the default gateway went down, we couldn’t leave the subnet, and so we’re stuck on the internal network. We don’t want that. And so we use a thing called layer three redundancy with a virtual gateway. To create that, we use one of these protocols, which we’ve mentioned before when we were talking about routers earlier in this class. Layer three redundancy can occur with the hot standby router protocol, or HSRP, the common address resolution protocol, or CARP, the virtual router redundancy protocol, or VRRP, the gateway load balancing protocol, or GLBP, and the link aggregation control protocol, or LACP. Now, let’s talk about each of these just for a couple of seconds.

The Hot Standby Router Protocol, or HSRP, is a proprietary first-hop redundancy protocol by Cisco, and it is very, very popular. We walked through this one earlier in the course as well. This allows for an active and a standby router, and it creates a virtual router as the default gateway. So my PC at the bottom is set to use the virtual router as its gateway. 192, 168, and one. The virtual router then determines who is active and who is in standby and sends the traffic there appropriately. Now, if the active router goes down, the standby router would pick up the load until the active router comes back. Now, common address redundancy protocol, or Carp, is the open-standard variant of HSRP. Remember, HSRP is Cisco-specific. This is still going to allow you to have that active standby router, and you’re still going to use the virtual router in the middle as your default gateway if you’re configuring your client. Next we have the virtual router redundancy protocol, or VRRP. Now, this is the Ietp’s open-standard variant of HSRP, or the hot standby router protocol. Again, this is another open standard that we can use just like the other ones. It allows for active and standby, and it allows you to create a virtual router as the default gateway just as the other two did. The next one we have is the Gateway load balancing protocol, or GLBP.

This is a Cisco protocol, and it is proprietary as a first-hop redundancy. It is going to focus on load balancing here, over redundancy. So we’re more concerned here, not with redundancy and reliability, but with getting better speeds in our network. Now, this is also going to allow for an active and standby router, but the default virtual router here will decide who the traffic goes to based on current loading conditions. Preference is given to the active router, but traffic can still be sent out the standby router because this load balancing is all about trying to get you more speed. Now, the last one we have is the link aggregation control protocol, or LACP. And we talked about this one all the way back when we were talking about layer-two switches. This achieves redundancy with your switches by having multiple links between the devices, but you can still do this with routing as well. Now this is going to give you load balancing over multiple links, and you’re going to be able to make all those links appear as a single logical link, giving you additional bandwidth. So if each of those cables was 100 megabits per second on these switches, I now have 400 megabits per second of continuous bandwidth by binding those four connections together using LACP.

Now, there are two more devices I want to mention before we finish up this lecture, the first of which is the content engine. Now, a content engine is a dedicated appliance that’s going to perform the caching functions of a proxy server. This is going to speed up our networks by not relying on the external network connection as often. By caching that stuff in this caching engine or content engine, we’re going to be able to hold data locally in the branch office. And when computers in the branch office want to access it, they’ll go locally to that device as opposed to going over our wide area network link. By doing this, we’re freeing up additional bandwidth for other devices in the network that need to go out over that wireless link. And so that’s one of the reasons why we cover it here in availability and redundancy. The last one is a content switch, and this one is really focused a lot on redundancy and availability because it’s going to distribute all of the incoming requests across various servers in a server farm. As you can see here, if a request comes in over the Internet, it’s going to hit the router and then go to the content switch. From there, it will decide which of those five servers will serve that request. This is also known as “load balancing.” So if you hear the terms “content switch” or “load balancer,” they are equivalent in network parlance.

2. Designing Redundant Networks

Designing redundant networks. So we showed you what those look like in the diagrams. But what are some considerations you need to make when you design these redundant networks? Well, first you need to decide where redundancy will be used. Are you going to do it from a module or from parts with redundancy such as power supplies, network interface cards, or hard drives? Or are you going to look more for chassis redundancy? And C is where you have an extra router or switch. Now, which one you’re going to use is going to affect the cost of your decisions. And so you have to make a good business case for which one you’re going to use. If you can get away with just having a second hard drive or power supply, that’s going to save you a lot of money as opposed to buying another entire switch or router, which could cost you three, four, or $5,000. The next thing we have to think about is what software redundancy features are appropriate.

Sometimes you can solve a lot of these redundancy problems by using software instead of hardware. For example, if you’re using a virtual network setup, you can just put another virtual switch or virtual router in there as opposed to bringing in a real router or switch. and that can save you a lot of money. There might be other software solutions, such as a software raid, that will give you additional redundancy as opposed to having to put in an extra hard drive array or another storage area network. Now, what protocol characteristics are going to affect your design requirements? This is important as well. If you’re designing things and you’re using something like TCP versus UDP in your design, that makes a difference for redundancy because TCP is reliable and UDP isn’t. And so as you design these things, all of these factors are going to work together just like gears, each one turning the other and each one feeding into the other to give you more reliability and availability in your networks. Now, there are other design considerations we have to think about as well, like what redundancy features should be used to power an infrastructure device? Is that going to be internal power supplies and having two of them?

Is that going to be battery backups, UPS, or generators? All of these things are things you have to think about. And I don’t have the right answer for you because it comes down to case by case. Every network is different, and every need is different. The network I had at former employers that served hundreds of thousands of clients is vastly different from the network I have at my training company, which has just a handful of employees. Each one is going to be different. Based on your needs and your considerations, what redundancy features should be used to maintain the environmental conditions? So if you have power, space, and cooling issues, you have to think about whether you need one air conditioning unit or two. What if one goes down? Sometimes these are things that, if you’re in a server farm, you really do need two units because if one goes down, the other one’s going to pick it up. In my office, we’ve made the decision that one air conditioning unit is enough. If it goes down, we just won’t work today. We’ll work tomorrow, and we can get by with that. However, because of the cloud infrastructure that we’ve implemented, our server farms are housed in cooled spaces with additional power space and cooling that are fully redundant. Now, when you look at the best practices,I want you to examine your technical goals.

And what I mean by that is, what is the function of this network? What are you trying to accomplish? Am I trying to get 90% uptime? How about 95? What about 99? Or are you trying to go for the gold standard of five nines of availability? Each one is a different technical goal and will determine the design of your network. You also need to identify your budget because funding these high-availability features is expensive. Like I said, if I wanted to put a second router in there, that might cost me $3,000; In my own personal network, we had a file server that was a small Nas device. We were not comfortable with just having all of our devices on us. We decided we weren’t comfortable having all of our file storage on a single hard drive. So we swapped it out for a Nasenclosure with a Raid Five. It has four hard drives working together, giving us full redundancy, full uptime, and full backup. That was a decision we made, but it cost us a lot more money. That device cost between $1000 and $1500. The earlier device I had with a single hard drive on the network was only about $200. and they have about equivalent storage space. So it wasn’t a storage function; it was a reliability function that we decided on that. And your company is going to make those types of decisions about what they’re going to fund and what they’re not going to fund based on your technical goals.

Now, you also need to categorise all your business applications into profiles. And this will really help as we start looking at quality of service. So, if I say web is category one and email is category two, category two, and streaming video is category three. These can then be applied to profiles where I can give certain levels of service to each of those categories. We’ll talk about how that works specifically when we get to quality of service in a future lesson. Now, another thing we want to do is establish performance standards for high-availability sources. So what are the standards that we’re going to have? These standards are going to determine how success is measured. So, in the case of my file server, we define success as it being up and running when our editors need it and not losing data, because losing all of our files would be disastrous. And so those are our two metrics, and we have numbers that are associated with those in other organizations. We measure it based on the uptime of the entire end-to-end service. So if a client can’t get out to the Internet through an ISP, that would be a bad thing, right? And that’s one of their measurements—what is their uptime? All of these performance standards are developed in metrics and through the ITIL or IT infrastructure library process or your other IT service management standards, depending on what your organisation is using. Finally, we will define how we will manage and measure the high availability solution. Metrics are very useful for quantifying success if they are developed correctly. Metrics are highly valued by decision makers and leaders. They love the charts and saying, “Oh look, our performance is going up, our availability is going up, our costs are going down.” Those are all good things. But if you don’t know what you’re measuring or why you’re measuring it, which again goes back to your performance standards, then you’re kind of wasting your time with metrics.

So I want you to make sure you think through how you decide on what metrics you’re going to use. So we’ve covered a lot of design considerations, but here’s the biggest takeaway I want you to think about: If you have an existing network, you can add availability and redundancy to it. You can retrofit this stuff in, but it’s going to cost you a lot more money. It is much cheaper to design this stuff early on in the process. So when you’re designing a network and you’re asked early on what kind of things you need, I want you to think about all of these things in your initial design, because adding them in early is going to save you a lot of money. Every project has three main factors: time, cost, and quality. And usually one of these is going to suffer at the expense of the other two. For example, if I asked you to build me a network and I wanted it fully redundant and available by tomorrow, could you do it? Maybe. But it’s going to cost me a lot of money. And because I’ve given you very little time, it’s going to cost even more money or the quality is going to suffer. So you can do it well, you can do it quickly, or you can do it cheaply. You can’t do all three. And so it’s always going to be a trade-off between those three. And I want you to remember that as you’re considering designing your network.

3. Recovery Sites

Recovery. So we talked about the importance of trying to keep our availability up, and we also talked about the fact that things are going to break. It’s just a fact of life. So what are you going to do when it comes time for recovery? Well, that’s what we’re going to discuss in this lecture: being prepared for the recovery.

Now, when it comes to recovery, you have three choices. You can have all this software and hardware redundancy, but at the end of the day, sometimes you’re going to need site recovery too. What if you have a fire break out in your building, or a hurricane, or an earthquake? This might cause you to have to relocate. And if so, you have three choices. You can have a cold site, a warm site, or a hot site. Now, when we deal with “cold sites,” this means that you have a building that’s available, but you may not have any hardware or software in place or even configured. So you may have to go to the store and buy routers and switches and laptops and servers and all of this stuff and bring it in and configure it, and then restore the network. This means recovery is possible, but it’s going to be slow and time-consuming. If I have to build you a cold site, that means that I’m bringing everything in after the fact. And so this can take me weeks or even months to get you back up and running. The next one we have is what’s called a warm site. This means you have the building available, and equipment is available. Now, you may not have the software installed on these servers or the latest data available or the backups with you, but you do have the hardware ready to go.

And that means that we can load our configuration, install the operating systems, bring in the files, and usually within a couple of days we can get back up and running. usually somewhere between 24 hours and seven days. Now the recovery is fairly quick, but not everything from the original site is going to be there and ready for the employees at all times. And so it’s more of a modification of the next one, which we call a “hot site.” Now, a hot site is great. You have the building, you have the equipment, and you have the data. The software is there, the hardware is there, it’s all configured, and it’s ready to go at any time. Basically, your people walk out of their old site, get in the car, drive to the new site, log in, and they’re back to work as if nothing ever happened. Now, this is great because it has very minimal downtime with nearly identical levels of service. But as you can imagine, this costs a lot of money because I have to pay for a building, equipment, software, and people to run all this stuff. As a result, you’re basically running two sites at the same time. So a hot site is very critical if you’re in a very high availability situation where you need to have availability up all of the time. But if you can get away from that, which most organisations do, they end up settling on something like a warm site. Now, when you deal with recovering and backing up, you have different types of backups and recovery. You have full backups, incremental backups, differential backups, and snapshots.

Now, if you’ve taken the A+ exam or studied the A+ material, you’re already familiar with these concepts because this is a carryover from those days. A full backup is just what it sounds like. It is a complete backup of every single file on a machine. It is the safest and most comprehensive, but it’s also the most time-consuming and costly. It’s going to take up the most space and time to run. Now, on the other hand, an incremental backup is going to backup data that has changed since the last backup. So if I did a full backup on Sunday, when I go to back up this incremental on Monday, I’m only going to back up the things that have changed since Sunday. The next one I have is what’s called a differential backup, and it’s only going to backup data since the last full backup. So if I go back to my example of Sunday being a full backup with incremental backups, if I do an incremental backup on Monday, it’s going to copy everything since Sunday. When I do it on Tuesday, it’s only going to do the increment, which is from Monday to Tuesday. When I go to Wednesday’s class It only does so from Tuesday to Wednesday.

Now, differential means something different. Differential is going to compute the difference between the last full backup. So if I do a full backup on Sunday and then do a differential on Monday, the incremental and differential look exactly the same. However, on Tuesday, the incremental only includes changes since Monday. But the differential will include everything that has changed since Sunday, which includes all of Monday and Tuesday’s changes. And you can see that this differential will grow throughout the week, despite the fact that incrementalis still only that 24 hour period. And lastly, we have what’s called a snapshot. If you’re using virtualization and you’re using VMs, this is a read-only copy of frozen in time. So, for example, I use snapshots a lot when I’m using virtual machines. When I’m doing malware analysis, I can take a snapshot of my machine, which is a frozen screenshot in time. Then I can load the malware, have it do all the bad things, and then restore to that snapshot. So if you have a very large storage area network, taking snapshots of your servers and your virtual machines is a very quick and easy way to really be able to restore everything exactly to the way it was at that moment in time. whereas when we use full incremental and differential, this is most commonly used with tape backups and offsite storage.

4. Quality of Service (QoS)

Quality of service, or Qu’s Now, why do we need quality of service, or Qu’s? Well, we now operate with converged networks, which means our networks carry voice, data, and video content. We don’t have them all separated like we used to. We used to have phones for voice, networks for data, and cable TV for video. But now everything’s running over the same IP networks. And so this convergence of the media on our network is requiring a high level of availability to ensure proper delivery. And by using QoS, we can optimize our network to efficiently utilise all of the bandwidth at the right time to deliver the right service to our users, giving us success and cost savings. And we want to provide excellent quality and service to our customers. And that’s why we start using QoS.

Now, what exactly is QoS exactly? Well, it enables us to strategically optimize our network performance based on different types of traffic. Previously, we talked about how we want to categorise our traffic types. So I might have web traffic, voice traffic, video traffic, and email traffic. And by categorizing it and identifying the types of traffic, I can then priorities that traffic. I can determine how much bandwidth is required for each of those types of traffic. And I can efficiently use my wide-area network link and its bandwidth for maximum utilization, saving me bandwidth costs. This will help me identify the types of traffic that I should drop whenever there’s congestion. Because if you look at the average load, there are peaks and valleys. Look at this chart.

There are high peaks and low peaks. There are peaks over time. And we need to be able to categorise things to fit within our bandwidth limitations. Examples of this would be voice-over-IP (VoIP) or VoIP solutions and video. They need to have higher priority levels because I don’t want a high latency when I’m talking to you on the phone, but I can deal with waiting half a second when I’m checking my bank balance. But if I’m listening to you talk, that half a second starts sounding like an echo, and it gives me horrible service. As a result, we want to be able to solve this problem by providing high-quality service. Now, there are different categories of quality of service. Three big ones are delay, jitter, and drops. Delay is what happens when you look at the time a packet travels from the source to the destination. Now, this is measured in milliseconds, and it’s not a big deal for data traffic, but it becomes a very big deal with voice and video traffic, especially when you’re doing something like live streaming or something like VoIP, where we’re making a phone call. Jitter is the uneven arrival of packets. And this is especially bad in VoIP when you’re using something like UDP, because if I were to say something to you like, “My name is Jason,” and you got Jason, “My name is,” it would sound kind of weird. Usually, it’s not big chunks like that, but just little bits, and so you’ll hear it like that, and it just sounds awful. And that becomes a bad service issue for VoIP.

So jitter is a bad thing for VoIP. The last thing we have are drops. And drops are going to occur during network congestion. When the network becomes too congested, the routers simply cannot keep up, and the queue overflows and begins dropping packets, resulting in packet loss. So again, if I’m dealing with a VoIP call and we’re talking, and then all of a sudden my voice cuts out like that, that would be bad, right? We want to make sure that doesn’t happen. And those network drops are something that we can avoid by providing proper service. Now, what is the effective bandwidth? This is a really important concept. So let’s look at this client and this server. Now, there’s probably a lot more to this network than what I’m showing you on the screen, but I’ve simplified it down. So I have my client on the left who wants to talk to the server. He goes up through the switch, which uses a 100 megabit per second Cat-5 cable. Then it goes through the Wan link, which is 256 KB because he’s using an old DSL line. Then that connects from that ISP over a T1 connection, over to another router, which connects to an E1 connection to another router, and then down to a WAN link of 512, then down to a gigabit per second to the switch, which gets to the server. What’s my effective bandwidth? Well, it’s 256 KB because, no matter how fast all these other links are, whatever the lowest link is, that’s the effective bandwidth. So, when we talk about the quality of service categories, we’ll talk about how we can alleviate this problem of effective bandwidth and get more out of it in our next lesson because we need to be able to increase our available bandwidth. But right now we are limited to 256 kbps, which is pretty slow. I like to think about water flowing through pipes. I can have big pipes or little pipes. And if I have small pipes, I’ll be getting less water per second. And so if I have a big pipe that goes into a little pipe like a funnel, it starts backing up on us, right? And this is a concept that we can effectively address by improving service quality.

5. QoS Categorization

Quality of service categorization Now, when we deal with quality of service categorization, we first have to ask, “What is the purpose of quality of service?” Well, the purpose of quality of service is all about categorising your traffic. We want to put it into buckets, apply a policy to those certain buckets or traffic categories, and then prioritise them based on that. Now, I like to use analogies to emphasise important points. Now, I live in the Baltimore, Washington, and DC areas. This area is known for having some really bad traffic. And to alleviate that, they’ve implemented a quality-of-service system. They have three different categories of cars. They have the first car, which is the general public—anybody who gets on the road and just starts driving. They also have a high occupancy vehicle category. This is if I’m driving my car and I have at least two other passengers with me. And if I have that, I can get into special HOV-only lanes, which is going to speed up my commute. And the third bucket they have is for toll roads or pay roads. And you can pay to get on those roads. And based on the time of day and the amount of traffic there is, they will increase or decrease the price. So if it’s during rush hour, you might pay $5 or $10 to get in those special lanes, but they’re going to travel a whole lot faster than the general commuters or even the HOV lanes.

Now, what does this mean for the quality of service? Well, it’s the same thing. We take our traffic and go. This is web traffic; this is email traffic; this is voice or video traffic. And based on the buckets, we assign a priority and let certain traffic go first, getting there faster. Now, when we categorise our traffic, we’re determining our network performance, and we’re going to figure out those requirements based on the different traffic types, whether it’s voice, video, or data. Now, voice and video, because they’re streaming media, especially in real time, like if I’m using Skype or a VoIP service, I want to have low delay and high priority. This way I can do this for streaming media and voice services to prevent those jitters, drops, and things like that from happening. Now, if I have something that’s low priority, that might be something like web browsing or non-mission-critical data; for example, email is very low priority when it comes to quality of service.

Now why is that? Because most email is a store-and-forward method of communication, I send the email, and it can sit on my server for five or ten minutes before it’s sent out, and the end user is never going to realise it. That’s okay. But if I did the same thing with VoIP traffic, even if I delayed it by half a second or a second, you’re going to hear those jitters, bumps, and echoes, and that would be really bad. And so you want to make sure that whatever your quality of service policy is, you understand it and your users understand it. And the best way to do that is by documenting it. So you want to make sure your users understand it by putting it out there. This may be posting it on your website, posting it as part of your indoctrination paperwork, or whatever method you want. But make sure your users understand that if they’re going to be surfing Facebook, that’s a low priority. If they’re going to be surfing something that is mission critical, that’s a higher priority and is going to get preferential treatment with your quality of service. Now, what ways are there to categorise our traffic? We have three different mechanisms. We have best efforts, integrated services, and differentiated services.

The best effort is when we don’t provide any quality of service to the traffic at all. Whatever comes in first, we’re going to do our best to get it out there. There’s no reordering of packets; there’s no shaping of the packets. It’s almost entirely devoid of Qu’s. The second is integrated services, or INs. Serve or sacrifice QoS. These are different names for it. This is going to require strict bandwidth reservations. And so we might say all web traffic is going to take up 50% of our bandwidth, VoIP service is going to take up 25%, and video service is going to take up 25%. By reserving bandwidth for each of these signaling devices, we have decided how much is going to be there. Now, with differentiated services, which is called Differ or soft QoS, those percentages become more of a suggestion. There’s going to be differentiation between the different data flow types, but each of these packets is going to be marked in its own way, and the routers and switches can make decisions based on those markings and fluctuate that traffic a little bit as needed. This is what we refer to as “soft QoS,” because even though web is set up at 50%, if there’s not as much web browsing going on right now, we can allow some of that to be given over to VoIP.

But when somebody wants to browse the web, we then take it back and give it to the web based on those markings and based on those categories. With hard QoS or integrated services, even if we have allocated 50% for web browsing, if only 20% of it is being used, the other 30% is being wasted. Now, when we look at this, I like to use simple charts, and this is a great example of it. You do not have strict policies despite your best efforts. Disserve provides a less strict and softer Qu’s, or soft quality of service. with a server-integrated service. We have a strict hard Qu’s limit. And this is the way we start looking at them as we look at these bundles. Now, which one’s best? That is dependent on your network, but it is unlikely to be your best effort. That’s not usually a good choice because it gives you almost no quality of service protection here. Now, when we start categorising our traffic, there are different mechanisms for doing that. We can do it by classification and marking. We can do it through congestion management, congestion-avoidance policing, shaping, and link efficiency. Now, in the next lecture, we’ll go over each of those in detail. So stick with me. I’ll.

6. QoS Mechanisms

quality of service mechanisms So we have different ways of categorising our traffic. We can do it through classification, marking, utilising congestion management, congestion avoidance policing, and shaping or linking efficiency. All of these are methods for implementing our service quality. And take us from the diagram you see on the bottom of the screen to the nice diagram we have up on the top of the screen, where we start shaping out those peaks and valleys using these different mechanisms. Now, when we look at the classification of traffic, traffic is going to be placed into different categories, and this is going to be done based on the type of traffic it is. So there is email, but even inside of email we have many different classes of information inside of email.

If you think about email, we have POP3 traffic, IMAP traffic, SMTP traffic, and exchange traffic, and we can look at the headers and the packet type information we’re using or the ports that are being used and determine which of these services needs higher priority. And we can do this not just across email, but across all of our traffic. And in this classification, it does not alter any bits in the frame or packet. There is no marking here. It’s all based on an analysis of the packetitself, the ports and the protocols used, and our switches and routers implement QoS based on that information. The other option is to apply traffic marking. And with this, we’re going to actually alter bits within the frame, cell, or packet to indicate how to handle this piece of traffic.

So our network tools are going to make decisions based on those markings. If you look at the type of service header, it’s actually going to be a byte of information, or eight bits. The first three of those are the IP presence. The next six of those are going to be the Differential Control Protocol, or DSP. Now, you don’t need to memorise how this type of service is done inside the header, but I want you to remember that one of the ways we can provide quality service is by marking and altering the traffic. Next, we have congestion management. When a device receives traffic faster than it can be transmitted, it buffers that extra traffic until the bandwidth becomes available. This is known as queuing. The queuing algorithm is going to empty the packets in a specified sequence and amount. And these algorithms are going to use one of three mechanisms. Weighted fair queuing, low-latency queuing, and weighted round robin are all options.

Now let’s look at the example I have on the board. I have four categories of traffic. traffic ones, two, three, and four. It doesn’t really matter what kind of traffic is there for our example right now. Now, if we’re going to be using weighted fair cueing, how are we going to start emptying these piles of traffic? Well, I’m going to take one from one, one from two, one from three, and one from four. And then I’m going to go back to one, then back to two, then back to three, then back to four. We just take turns. Now, is that a good mechanism? Well, maybe it depends on what your traffic is. If, for example, column number one represented VoIP traffic, that’s actually not very good because it has to keep waiting for its turn. Now, let’s look at this in terms of low-latency queuing. Based on our categories 1, 2, 3, and 4, we would assign priorities.

And if one was a higher priority than two, then all of one will get emptied, then all of two will get emptied, then all of three, and then all of four. This works really well to priorities things like voice and video, but if you’re sitting in category three or four, you might start receiving a lot of timeouts and drop packets because it’s never going to be your turn. The following one on the list is the weighted round robin. This is kind of a hybrid between the other two.

So with the weighted round robin, we might say that category one is VoIP, category two is streaming video, category three is web, and category four is email. And those would be in that order of priority, with one being the highest. Well, with a weighted round robin, we might say we’re going to take three out of category 1, two out of category 2, one out of category 3, and one out of category 4, and keep going around that way. So we take three, then two, then one, then three, then two, then one, then one. And that way, the VoIP traffic is getting a lot of priority. The video is the second-highest priority. Then we get to the bottom of the barrel and look at web and email. But they’re still getting a turn every time we go around the robin, which is why we call it a “weighted round robin.” This is the QoS mechanism that I prefer to use in my networks. Next, we have congestion avoidance.

Now, as new packets keep arriving, they could actually be discarded if the output queue is already filled up. And I like to think of this like a bucket. So you see my cylinder on the bottom there; it has a minimum and a maximum. If it’s already at its maximum and you try to put more into the bucket, it just overflows out the top. And so we have what’s called random early detection, or “red,” and this is used to prevent this overflow from happening. As the queue starts approaching that maximum and we have this possibility that discard is going to happen, what we start doing is dropping traffic. Now, instead of just dropping traffic at random, we want to drop it based on priority, lowest priority first. So Red is going to drop packets from the selected queues based on their defined limits. And so I might start dropping TCP traffic first because I know it’ll retransmit, whereas UDP traffic, like VoIP and video streaming, might get priority to stay in the queue so that it doesn’t get dropped because it won’t retransmit. And so with TCP traffic, it’s going to get that retransmission.

With UDP, it’s just going to be dropped, and you’re never going to know about it. So with congestion avoidance, we’re trying to use the buffer to our advantage. Now, when we start putting all of these things together, we start getting into the two concepts of policing and shaping. Now, policing is going to discard packets that exceed the configured rate limit, which we like to refer to as the speed limit. So just like if you’re driving down the highway too fast, you’re going to get pulled over by a cop, and you’re going to get a ticket. Well, with our policing, we’re just going to drop you off the network. Now, dropped packets are going to result in retransmissions, which then create more bandwidth, right? So therefore, policing is only good for very high-speed interfaces. If you’re using a dial-up modem, an ISDN connection, or a T one, you probably don’t want to use policing; you’re better off using shaping. Now, what shaping is going to do is allow the buffer to delay traffic from exceeding the configured rate. So instead of dropping those packets, we just hold them in our buffer. And then, when there’s this empty space, we start pushing it over the empty space, and that starts shaping out the packets, right? That’s why we call it shaping. As you can see on the screen, this is how it looks. I have the traffic at the top, and you’ll see those jagged lines going up and down, and that’s what really happens in your network. There are high and low activity periods. If we do policing, all we’ve done is cut off the tops, which has resulted in more retransmissions. With shaping, we start filling in the bottoms, and so it keeps going up there, right towards the speed limit.

And it does a better job of maximising your bandwidth, especially on slower interfaces such as T1 connections, dial-up satellite connections, and ISDN. Now, the last thing here I want to talk about is link efficiency. And there are a couple of things we need to mention with regard to link efficiency, the first of which is compression. Now, to get the most out of your link and make it more efficient, we can compress our packets. And so if we take our payloads and compress them down, that’s going to conserve bandwidth because it’s lessons and zeros that need to go across the line. VoIP is a great thing that you can compress because there’s so much extra wasted space inside voice traffic. So VoIP payloads can actually be reduced by about 50%. And we can take it from 40 bytes to 20 bytes by using compression. Now, if you think that’s good, take a look at the VoIP header. I can compress the VoIP header down to 90% to 95% of its original value. This can take it from 40 bytes down to just two to four bytes. To do this, we use something called compressed RTP, or CRTP. Now that I have the original VoIP payload, as you can see here, I have an IP address. I have UDP as my packet type. I have RTP for its header, and I have a voice payload.

I can compress all of that down into just a CRTP, which consolidates the IP, the UDP, and the RTP together. The voice payload can also be squeezed down to about half its original size. You won’t notice a significant difference in audio quality either. This can be utilized on slower-speed links to make the most of your limited bandwidth. And it’s not just for VoIP. You can do this with data too. So compression is a great thing to use. Wan accelerators are devices that focus specifically on compressing your data before sending it out the Wan link. Now, the last thing I want to talk about here is what we call LFI, which is another method to make more efficient use of your links. This is called link fragmentation and interleaving. Now, what this does is, if you have big packets, it will start chopping those big data packets up and fragmenting them, then interleaving smaller packets in between them. This is going to be utilised again on slower speed links to make the most of your limited bandwidth. Notice here I have three voice packets and one big hunk of data. The router will cut that up and place one small voice piece, one small data piece, one small voice piece, and one small data piece. That way, the voice doesn’t suffer from huge latency. By doing this fragmentation and interleaving, it allows you to get some of that high-priority traffic in between these larger data structures.