Cisco CCNA 200-301 – QoS Quality of Service Part 4

5. Policing and Shaping

In this lecture you’ll learn about traffic shaping and policing. When people talk about QoS in general, they’re probably talking about queuing, but there are other QoS mechanisms available like shaping and policing which are also commonly used. Traffic shaping and policing can be used to control traffic rate. Both measure the rate of traffic going through an interface and take an action if the rate is above a configured limit. If you look at a router, it knows the amount of traffic that’s going through its interfaces. You can see that if you do a show interface command.

So because it knows how much traffic is going through the interfaces, you can configure it to take an action if it goes above a certain rate. Traffic shaping and policing both work in a very similar fashion, but the action that they take is different. So it’s used for different scenarios that we’ll cover as we go through this lecture. Traffic shaping buffers any excess traffic so the overall traffic rate stays within your desired rate limit. So you can think of traffic shaping as putting the brakes on.

If the traffic is going too fast, it keeps it within the required limit and it smooths out the traffic flow. Traffic policing, on the other hand, drops or remarks SS traffic to enforce the specified rate limit. So traffic policing is much more aggressive. If traffic goes above the limit that you set, usually you’re going to just drop that excess traffic rather than buffering it so it just gets slowed down.

So you’ll see that traffic shaping is usually used at the customer side of a link and policing is used on the other side on the service provider. You can use them for different scenarios as well, but that’s most common and I’ll cover that in more detail as we go through this lecture. Classification can be used in your shaping or policing policy to configure different rates for different traffic types. For example, you could allow a different rate for traffic that is marked as Dscpef.

Then you allow for traffic that is marked as AF 31. So that is optional. You can apply the rates to the aggregate of all traffic or you can have different rates for different traffic types. So let’s look at the scenarios where this would be used. It’s the easiest way to understand it. First one is we are looking at it from the point of view of the service provider. In the example, the customer has provisioned an MPLS VPN between their headquarters and their branch offices.

The physical links from the Ce to the PE routers on both sides are 100 megabits per second fast Ethernet. But the customer has only paid for ten megabits per second in the contract with the service provider. That’s what’s agreed in their service level agreement. Traffic is going to go at the rate that the physical interface is set at, which is 100 megabits per second in this example. But a way that you can influence the rate is by using policing or shaping. So in the example here, the customer, they’ve got 100 megabits per second on both ends, but they’ve only actually paid for ten megabits per second.

So the service rider is not going to be sending traffic all the way across their core at 100 megabits per second for this customer, they’re going to limit it to ten megabits per second when it comes inbound on the PE. So that’s what the service provider is going to do.

They will configure a policing QoS policy on both PES on the interface facing the Ce router in the inbound direction. So whenever any traffic comes in, if it comes in at a rate higher than ten megabits per second, the excess traffic is just going to get dropped. So the service provider is going to limit the customer to about ten megabits per second worth of bandwidth that they’ve paid for. So you will see this being used very commonly. Another place where you can see policing being used not at service providers but within normal enterprises and common use. Case here is worm and junk traffic mitigation. What a worm is, is that’s a type of virus. Obviously you don’t want that type of traffic on your network at all, definitely not taking up your bandwidth.

So an enterprise can configure classification and marking to recognize worms and also junk traffic that they don’t want on their network, like peer to peer file sharing applications. That bad traffic is known as scavenger traffic and the recommended DSCP value to market with is DSCP Eight, which is CS One.

So once you’ve got the traffic classified and marked, you can then configure a policing policy which is going to rate limit down to a tiny amount so it can’t take up any bandwidth on your network. So this will mean that if users are trying to share files like movies and stuff like that over your wand, like that’s not a business case, you don’t want them doing it. You can police the traffic right down so it doesn’t take up any of your bandwidth for worms. Obviously you want to have antivirus on your user’s PCs so you don’t get a worm in the first place.

But if you are infected with a worm, one of the really bad things that happens is it will start sending traffic out trying to infect other PCs and when it manages to do that, they’ll do the same thing and it can quickly end up eating all of the bandwidth on your network. By using policing for worm mitigation, it doesn’t stop you getting infected, but it stops the worm from taking up all your bandwidth and grinding the network to a halt when you do get hit with one.

So it means it gives you time. You can go and clean all of those PCs. Better not to get infected in the first place. But this is good that if you do get infected, it stops it from crashing your network. Okay, back on to that first scenario again, where we’ve got the customer with her HQ and her branch office and they’ve got an MPLS VPN between the two sites. And the physical links from the Ce to the PE are 100 meg and the provider is policing at ten meg inbound on the PE routers. And the customer knows this.

So the customer knows that if they send traffic at a rate higher than ten megabits per second, that excess traffic is going to get dropped. So if they do send at a higher rate, some traffic will get to the other side, some traffic will not. In our scenario we’re using both voice and video. And you know already that voice has strict quality requirements. If a lot of the packets are getting dropped, it’s going to be a terrible quality phone call. So the customer knows they have to make sure that they don’t have any of those voice packets being dropped. And the way that they do that is by making sure that they don’t send at a rate higher than ten megabits per second. Now you know already that they can’t use the bandwidth statement on the interface to do that.

The bandwidth statement affects other software policy like your routing protocols, but it doesn’t actually affect the rate that traffic is sent at. The way that we can affect the rate that traffic is sent at is by configuring a shaping policy outbound on those Ce routers. So let’s have a look and see how we’re going to configure that. We configure a policy map here. I’ve called it One Edge, and I say class default and shape average to ten megabits per second. I didn’t need to configure any of our class maps here because the policy map, the shaper is being applied to all traffic. So class, class default makes it take effect on all traffic and I’m shaping it to ten megabits per second. Then I need to remember to apply it to the interface with my service policy.

So interface, fast Ethernet, I do that on both Ce routers on the outside interface facing towards the provider, and I say service policy out One Edge. Now all traffic is going to be shaped to ten megabits per second. It’s not going to go above that. So the provider is not going to drop any traffic. But we’ve got another problem as well now. So let’s have a look at that. Let’s see what our scenario was. So we’ve got a ten megabits per second SLA on the Wan outside interface. The physical speed of the one outside interface was 100 megabits per second. So we’ve put the shaper on there to shape all traffic to ten megabits per second to guarantee that the service provider won’t drop any of our traffic. We’ve got a 100 megabits per second fast Ethernet interface on the inside facing towards Milan as well on both CES and we have figured out how much bandwidth we need for our different traffic types. We need one megabits per second for voice, three megabits per second for video and six megabits per second for data. So that’s why we paid for a ten mega link from the provider. But data will sometimes burst above six megabits per second, creating congestion. Because we’ve got that 100 megabits per second interface on the inside, we’re shaping to ten megabits per second on the outside. So if we have traffic coming in at a rate more than ten megabits per second, we’re going to get congestion there. And let’s say that data has burst above six megabits per second.

We’ve now got twelve megabits per second’s worth of traffic coming in, but we’re trying to squeeze that twelve meg into a ten meg pipe. It’s not going to go. So we’ve got congestion there, it’s going to affect the quality for all of our traffic. And again, we’re going to have bad quality voice and video, cogs if that happens, so we don’t just have the shape or shape traffic to ten megabits per second, we also need to have an LLQ policy here as well. So let’s have a look at the config for that same policy that you saw before for LLQ. But there’s going to be a twist here. So we’ve got the classmaps to specify the traffic we’re interested in. Class map, voice match IP Dscpef classmap video match Ipdscp AF four A one, and classmap signaling match Ipdscp CS three. Then we’ve got the policy map to see what we’re going to do with it. Policy map, I’ve called it Nested. You’ll see why in a second for class voice, which was the Dscpef of the Voice Traffic Prorata 124.

So we’re guaranteeing it that one megabits per second worth of bandwidth required and we’re putting it into product EQ class video priority 372. It’s getting its three megabits per second class signaling bandwidth one to eight and then class class default for everything else. Fair Q. Now, you can only apply one policy map, one service policy to the interface. So what we do is this LLQ policy that we’ve just created to prioritize the voice in the video traffic, we nest that inside the shaper policy. So underneath policy map one edge, we say service policy nested in there and it’s the PolicyMap one edge that is applied at the interface level. So at the interface level, we’re shaping all traffic to ten megabits per second. If we need to try to send more than ten megabits per second through there, though, our voice and our video traffic is going to go straight to the front of a queue.

So this guarantees that no traffic is going to get dropped because we don’t send more than what we’ve paid for a service provider. And when we are trying to send more voice and video goes straight to the front of the queue, so voice and video still gets the service it requires. Okay, that was it. That was everything for QoS. Again, don’t worry about memorizing these configurations. You don’t need to know the configuration for the exam. I’m just showing it here so you get a full understanding of how QoS works. Okay, QoS. Done. See you in the next.

• Category: Uncategorized