Aaron’s Worthless Words

We just talked about tagging traffic and policing traffic, but we haven’t talked about prioritizing traffic. Tagging just sets a value in the header. Policing sets a “bandwidth ceiling” that can’t be crossed. Prioritization guarantees a certain amount of bandwidth for a flow/app/etc. no matter what’s going on.

Prioritization offers you a certain amount of bandwidth; it doesn’t carve it out and hand it over. If you’re using less than the priority value, you only get as much as you need and the rest of the reserved bandwidth goes into the pot for everyone to use. As priority traffic grows, though, you’re given as much as you need up to the configured value. When you go over that, your extra traffic just goes into the best-effort queue with everything else (Note: Don’t go over the limit with VOIP traffic. Echoes and artifacts suck). For example, if you give your VOIP traffic 70% of the bandwidth of an interface but are only using 40%, the other 30% can be used by the other apps on the line. If you’re using 80%, that 10% over is competing with everything else for bandwidth.

Let’s get on with it, shall we? To configure prioritization, you go through the same steps as we did with policing, but, instead of setting the policy-map for police, you set it up for…wait…wait…priority. Here’s the scenario, then. You have a router that has a VOIP system behind it. That router tags all VOIP packets as AF41, so we want to give any AF41 packets 70% of the bandwidth on the interface. The tagging router is directly attached to your F0/0 network, and your users are out F0/1.

We don’t use an access list this time since we’re looking for DSCP values in the packets. We’ll start with the class-map.

class-map VOIP
match dscp af41

Remember that class-maps define what traffic you’re interested in, so this line says that we want to do something with any packet that’s tagged AF41. Let’s tell the router what we want to do with it, then.

policy-map PMAP
class VOIP
priority percent 70

With this configuration, any packet with a DSCP value of AF41 is given priority and is guaranteed up to 70% of the total bandwidth available. So, what is 70% of the total bandwidth available? That depends on where we apply the policy-map. If it’s on a T1, that’s 1.08Mbps. On our FastEthernet, that’s 70Mbps.

Let’s apply it to the interface to finish up.

interface F0/1
policy-map output PMAP

Since we’re worried about squashing VOIP traffic on F0/1, we apply it outbound there (towards the users). We could apply it inbound on F0/0, right? Not really. Once the packets hit the interface, it’s too late to do any prioritization on them; they’re already on the router in the order that the switch is delivering them to us. Prioritization really only works outbound.

So, if nothing’s going on, VOIP can use up to 100Mbps, but, if the link is saturated, it’s guaranteed 70% of the bandwidth or 70Mbps. Of course these numbers should be tweaked to suit your needs, but you can see how useful prioritizing is.

• Leave a comment... (0)

We covered QoS tagging the other day, but that just marks packets. I think you’re old enough now that we should actually do some policing. Policing is where you restrict the amount of bandwidth that a flow or set of flows can use. For example, say you have a site that serves webpages to the rest of the network. HTTP is the primary function, but the SysAdmins also have to maintain the boxes via SSH, right? To make sure that their SSH sessions don’t squash the bandwidth that your HTTP servers need, you can police the SSH sessions by giving the a bandwidth ceiling that they can’t cross.

Let’s set up a scenario. You have a router with two Ethernet ports. E0/0 goes to your webservers on 192.168.1.0/24, while E0/1 goes to SysAdmins’ PCs on 192.168.2.0/24. We want to restrict all SSH access from 192.168.2.0/24 to 192.168.1.0/24 to 8k of bandwidth. That’s right, you don’t like your admins and want them to struggle with their daily tasks. Let’s set it up.

Remember the steps? ACL, class-map, policy-map, interface. First, create an ACL that matches the traffic you want to police.

ip access-list extended SQUASHSSH
permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 22

Next, create a class-map that matches that traffic.

class-map SQUASHSSH-CMAP
match access-group name SQUASHSSH

Create your policy-map. This is where you actually set the bandwidth restrictions.

policy-map SQUASHSSH-PMAP
class SQUASHSSH-CMAP
police 8000 conform-action transmit exceed-action drop

Last time, we just did a set dscp af43, but this time we actually take action on a packet instead of just marking it. The long lines does three things — it sets the ceiling to 8000 bits per second, transmits if the rate is below that number, and drops if its exceeded. So, if one of the admins tries to SCP a file over, he’s gonna be in for a surprise with only an 8k window to use. If he goes over 8k, the packets are just dropped, and it’s up to TCP to retransmit. It’ll take a while. Remember, too, that this policy applies to anything matching the ACL, so, if two admins are SCPing files at the same time, they have to share that 8k. Wow, you’re mean!

Setting it up on the interface is pretty straightforward. It’s just like we did before.

interface E0/0
service-policy output SQUASHSSH-PMAP

I set this up in a dynagen lab to test it, but, instead of SSH traffic, I policed ICMP. If I did a normal, 5-packet ping, it worked great. If I sent a 100-packet set, drop, drop, drop. Or if I increased the size of the packets. Just to be sure it was the service-policy doing the dropping, I sent a 100-packet set and removed the policy from the interface; it missed a few at first, but, when the policy was removed, it zoomed right along without a single miss or hesitation.

NOTE: I do not condone policing traffic from your coworkers machines to 8k, but it would be funny.

• Leave a comment... (4)

I’ve been trying to get some experience on Cisco VOIP, and, as you probably know, Quality of Service (QoS) is quite important in that realm. Since VOIP is very time-sensitive, you have to be sure your gear delivers the voice packets first. A packet in an HTTP transaction can wait another 200ms without any problems. A voice packet with another 200ms on it means static and digital artifact on the line. Not good. There are lots of things you can do in the world of QoS, but I’ll talk about tagging this time (I may get to some of the other topics later, though).

What is tagging, though? There is a header in an IP packet that, paraphrased from the standard, set the importance and drop-sensitivity of the packet in regard to the flow/application/data stream. A ping packet is quite unimportant in the grand scheme of things, and dropping the packet will have very little impact on the stuff going on in the network. Voice, however, needs every packet to arrive in order, so each packet’s importance is high and a drop hurts. To differentiate between these two, we set the Differentiated Service Code Point (DSCP) value in the pakcet. This is just the packet header thing I was talking about earlier.

Let me pause for a second to discuss something, though. Just tagging the packet does nothing to prioritize the packet. I can tag a packet with whatever I want, but, if a router or switch isn’t configured to use the tag, my packet just goes into the FIFO queue like everything else. Actually doing something different to a tagged packet is one of the many other parts of QoS that I may get to later.

Time to configure? Of course. Like everything in the Cisco world, it always usually starts with an access-list to define interesting traffic. You then create a class-map that defines what traffic you want to tag (usually with the ACL you created), then you create a policy-map that defines what to do with that traffic. Finally, you apply the policy-map to the interface.

Let’s try one. Let’s say we just put in a new VOIP system and want to tag the packets appropriately. The IP of the system is 10.0.0.10, and you want the gateway on that network to tag the packets as AF41 as they come into it (Google up DSCP if you want to learn about the AF41 thing). What comes first? The ACL…duh!. I like named ACLs, so we’ll create one called VOIP.

ip access-list extended VOIP
permit ip host 10.0.0.10 any

Time for the class-map. All that a class-map is used for is to create a list of values that are interesting to you, but a list can have an or or an and associated it. Basically, do you want to match all the items or just any of them. In our case, we just want to match the ACL we created (a single item), so it’s no big deal, but keep in mind that you can use the match-all or match-any keywords if you want. Here’s the class-map to match our ACL.

class-map match-any MYCLASSMAP
match access-group name VOIP

Next is what we want to do to the traffic, which is tag it to AF41. In the policy-map, you actually reference the class-map you made, so keep that in mind when you’re configuring.

policy-map MYPOLMAP
class MYCLASSMAP
set dscp af41

That says that anything that matches the class-map MYCLASSMAP gets tagged to AF41. Now we have to apply it to the gateway. Assuming that’s F0/0 of your router, give this a shot.

interface F0/0
service-policy input MYPOLMAP

That’s pretty much it. Now, when a packet lands on F0/0 that matches the ACL, it will be tagged as AF41 and sent on. I say again that this just tags packets. If you want to actually prioritize those packets, you have to do more, but I’m too sleepy to get into that right now.

• Leave a comment... (5)