Qos Tagging

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.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages.

More Posts

Follow Me:
Twitter

10 comments for “Qos Tagging

  1. Clint Young
    April 6, 2008 at 12:58 pm

    So on an ASA5505 (lets say), it mentions that it is possible to perform QoS on VPN tunnels, but do you know if it is possible to perform QoS on regular LAN –> INET traffice as well? If it is possible, I would assume that you would create your Policy/Class-MAP and apply it to say E0/1 (LAN) for inbound traffic. Eagerly awaiting the rest of the info for the QoS outbound on the WAN (E0.0) side. 🙂

  2. April 6, 2008 at 7:10 pm

    Hey, Clint.

    I’ve never really tried QoS on an ASA 5505, but I took a quick glance at the docs, and it looks like you’re right. Just configure the maps and apply the policy map to the right interface.

    Of course, how to prioritize our interesting traffic is another article, so look out for that.

  3. Clint Young
    April 6, 2008 at 7:24 pm

    Well, I still need to finish the visio of the proposed network design, but as soon as I move the ASA into production and start tagging my VoIP Traffic, I will report back! 🙂

  4. Sam
    April 22, 2009 at 12:00 pm

    Thanks Aaron,

    Good Stuff…Sometimes just seeing common sense examples make learning tech stuff so much more enjoyable. I’ve spent the past 3 days on Cisco.com trying to confirm what you just layed out above; Tagging on a switch. Or is this example for a router as well? Our intent is to tag on the closet switches and priortize on the WAN interfaces.

  5. April 22, 2009 at 2:05 pm

    Thanks for the comment, Sam. I’m glad someone’s reading! Heh. I learn better if someone explains a concept and then shows me an example; the usual Cisco docs just don’t do that very well.

    The example above is configured on a router. In most of the situations that I’ve seen, one either has the router tag the packets on the way across the WAN or the device generating the packet tags it before sending it out to the LAN. You may, however, be able to use the same or similar config on switch ports to tag as necessary.

  6. Sam
    April 23, 2009 at 2:40 pm

    Aaron I read more than you think (maybe I should comment more often) And we were all set to do the marking and shaping on the router but a “paid” resource from Cisco suggested that we tag packets on the closet switches. The current router is a 3845; running BGP, EIGRP, Netflow and IP WCCP for WAAS redirects. Less for the router to do was his position.

  7. April 23, 2009 at 8:34 pm

    Hey, again, Sam.

    It does make sense to have the switch do some work for you if the router is overburdened. The one big advantage I see with doing it on the router, though, is configuration simplicity. On the switch, you would have to set up tagging on each port (or maybe set the default for the whole switch), but, on the router, you set it up on one interface to cover whole networks.

    Good luck.

Leave a Reply

Your email address will not be published. Required fields are marked *