Previous

Content

Next

2.1.- Creating a Traffic Class

The very first step to implement a Differentiated Service Domain using Cisco (after having read the theoretical part beginning with Differentiated Service Theory, of course) is to learn what Traffic Classes are, and how to create them using the router. A Traffic Class specifies a mechanism which we can use to match incoming and/or outgoing packets on a router's interface. To simplify the explanation we are not going to advance much more trying to understand why we do need this; instead let's understand first how to define and configure a class, and later on, how to use it.

Traffic Safety Facility

Traffic Safety Facility, Competiti -ve Price. With EU CE certificate!
www.HnR oad.com

Safety Cabinet
Class I,Class II, laminar flow Service and sales 01275 793000
www.puricore .com

As all things in this world, to define a new Traffic Class we start our work by naming it; the name you like (of course, some name being intelligible and having some relation with the object we are trying to represent). Because I don't like abstractions and I hope neither you, let's try with an example. Have a look to the figure below:

GREENGUARD Certification
Find Third-Party Certified Products For Greener, Healthier Projects.
GR EENGUAR D.org/third-p

Windows Network Analyzer

Network Analyzer &Protocol Analyzer Monitor Your Network. Free Trial!
www.colasoft.com

Network Ynetim zmleri

Our router is having a traffic interchange with the depicted domain. We are not interested yet in knowing how this traffic interchange is done; this means, using which links or paths and which router's interfaces, etc. We are only interested in characterize the class of traffic we are having. We could start being a little lazy, and because we don't want to think too much, we are going to create a single class to represent this domain. Having our router in global configuration mode, we type:

A analizi, arza bulma, IP SLA, AD LAN, WAN, Netflow, VoIP, WiFi, CMDB
www.vite l.com .tr

In this HOWTO, Cisco commands will be presented using bold. User's supplied names will be

In this HOWTO, Cisco commands will be presented using bold. User's supplied names will be presented using cursive. With the Cisco command class-map we create the class domain. This class is going to represent (in our router) the entire domain, at least, in our initial (and lazy) intention to characterize traffic between the router and the domain.

But defining this name doesn't permit us to match packets going to or coming from the domain. It is just a name; then we have to add some additional definitions to reach the goal we want. Having executed the command above the Cisco router will enter in class-map configuration mode; this way:

Let's suppose that we, previously, defined an access control list (ACL) named as 101 to identify some or all packets going to/coming from the domain. Then, to match these packets we just type:

This way the class domain will match those packets being matched by the access control list #101. When you define a new Traffic Class you have two possible options to match packets; these are: match-all match-any The option match-all is the default option; this means that typing "class-map match-all domain" is exactly the same as typing "class-map domain". The class-map match-all command is used when all of the match criteria in the traffic class must be met in order for a packet to match the specified traffic class. The class-map match-any command is used when only one of the match criterion in the traffic class must be met in order to match the specified traffic class. The options match-all and match-any indicate to us that we can assign many criteria to the same traffic class. If the class is defined with match-all, then all these match criteria must be met by the packets to be considered to belong to this traffic class. If the class is defined with match-any, then is good enough than one of the match criterion is met by the packets to be considered to belong to this traffic class. We can add match criteria until we finish by typing exit (see command cm-003 above) to abandon the traffic class definition. When we type exit the router comes back from the class-map configuration mode to the global configuration

definition. When we type exit the router comes back from the class-map configuration mode to the global configuration mode. Cisco has a lot of criteria to match packets using a traffic class definition. But we are going to study only those that are interesting to be applied to implement a Differentiated Service Domain. The match criteria we will study will be: match access-group match input-interface match ip dscp match ip rtp match mpls experimental match not match protocol match access-group This criterion must be used to refer to a previously created access control list (standard or extended). If you have worked with Cisco access control list (ACL) you know this is a very powerful mechanism to define criteria for selecting packets. It is something similar to using iptables in Linux. In this site, at Network QoS using Cisco HOWTO there are some examples about how to use this powerful mechanism. Using a practical example, let's suppose that the domain being considered has three networks: 212.29.13/24, 201.30.16/24 and 204.30.21/24. We are interested in creating just one traffic class in our router for the all domain. Then, being in global configuration mode, we should type as follows:

After finishing, the traffic class "domain" will be match all packets from the three network belonging to this domain. There are different paths to get the same result; for example, we could have typed:

In this case we use match-any instead of match-all to get the same packets matching. Given the powerful facilities offered by Cisco ACL, we really wouldn't require any more to match what we want. For example, let's suppose we would like to segregate, from this domain, the TCP traffic from the UDP traffic. This type of traffic should always be segregated because they are so different that having a different scheduling mechanism for each of them is the best that you can do. Advantage of using ACLs is that we can concentrate our efforts in typing the required access control list and after that, applying the rule is really very simple. For our case, we could type:

Here we have created two traffic classes: "domain_tcp" matches all tcp protocol packets coming from or going to the domain, and "domain_udp" matches just the udp protocol packets. Being proficient with Cisco ACL, it's just a matter to think a little and to make later the home work of preparing the required scripts to convert yourself in some sort of packet hunter. We have to be good packet hunters to segregate packets to implement differentiated services; the name "differentiated" is clear: it is of capital importance to differentiate (segregate) packets to have success differentiating services. However, some situations require that we would have more specialized weapons to reach some goals. Cisco has these weapons; let's continue with our explanation. match input-interface This criterion is used to match packets (any kind) entering the router for one of its interfaces. I'm not very sure whether the criterion is applied to packets just entering the selected interface or also for outgoing packets. I haven't had the opportunity to check this with one 7500's series router to verify this carefully. If you have access to one of this marvel and you can make the test for me, I would be very grateful if you make me to know your conclusions. The criterion's name suggest that the matching is done on packets just entering the interface. The implementation of this criterion is very easy:

The traffic class "domain_tcp_e1" matches tcp protocol packets coming from the domain and belonging to the three indicated networks, but entering the router through the ethernet interface e1/1. match ip dscp This criterion is very tie with the Differentiated Service architecture. It is used to match DS packets, this means, those marked with a DSCP value in their IP header DS field. The value of each service code point is from 0 to 63. Let's have an example taken from the Cisco documentation to explain this kind of matching. Again, being in global configuration mode, we are going to create five classes to represent the following DS-classes:

In this example, we are assuming that our studied domain is a differentiated service domain, and packets coming from it are previously marked before leaving the domain. Networks from the domain to be matched are the same from previous examples. The decimal DS-codepoints are obtained by converting from hexadecimal to decimal the xDSCP values presented in the next table, that we have stolen from our previous work Differentiated Service on Linux HOWTO.

RTP/RTCP Developer Tools

RTP/RTCP Application Tool kit Slash Development Time!
www.RADvision.com

Complete CCNA Training

Best-effort DSCP is just zero (the packet header DS field is not marked). Then, we should begin to talk with our Cisco router, just typing:

Instant access to 900+ hours of Cisco training videos. Only $159/mo

www.INE.com /C C NA

Network Monitoring
See More of Your Network with Existing Network Security Tools
www.gigam on.com

samwin attendant console

New professional SIP console innovativ and vendor independent.
www.te le com so ftware .com

WS-C2960-24PC-S $1,002
Genuine Cisco. New in sealed box 1 year warranty. Ship to worldwide
www.ne twork se lle rs.com /

The traffic classes premium, gold, silver, bronze and best-effort matches DS-field marked packets coming from the domain and belonging to the three indicated networks, where: premium class matches packets marked with DSCP 46 (EF). gold class matches packets marked with DSCP 10, 12, or 14 (AF11, AF12, or AF13). silver class matches packets marked with DSCP 18, 22, or 24 (AF21, AF22, or AF23). bronze class matches packets marked with DSCP 26, 28, or 30 (AF31, AF32, or AF33). best-effort class matches non-marked packets, this means, those having DSCP 0 (BE). Having these classes defined we are almost ready to apply conditioning at the boundary of our network, where our friendly

router is just an edge router. match ip rtp This criterion is really a very, very nice gift for us, the network management people, directly from Cisco. Linux doesn't have yet something as this, or being more fair because Linux has a lot of resources to do many things, it doesn't have something as simply and directly as this beautiful feature to segregate real-time protocol traffic (RTP traffic). RTP traffic is really a headache. Basically because it runs over UDP that is a TCP-unfriendly protocol, this means, a bad citizen and unresponsive protocol, very hungry and rude, not having any kind of congestion control and being one of its properties its ability to starve well-designed TCP based applications. Then, it is better to keep this guy under strict control (like Hannibal Lester happens to be) and the first step to reach this goal is trying to segregate its traffic. Then, this criterion comes to us like ring to the finger to advance the work we are intended to do, i.e., to protect the health and sanity of our networks. Nevertheless, over RTP runs all those real-time applications like VoIP, multimedia, video, and of course, the famous interactive Internet games (i.e., counter-strike, end-of-empire, etc). Our goal is then to segregate this type of traffic creating a class to easily identify their flows, and later on, assigning the resources we considere fair to be shared with the rest of the network applications. Note: searching on Internet I discovered later that, really, this criterion just match UDP packets having some range of configured ports; this means, the criterion doesn't have any form to know if the underlying traffic is really RTP traffic, or just plain UDP. Cisco shouldn't sell this criterion as a trully RTP packet matching machine (as its name suspiciously imply) because some of us could be tricked. I had read somewhere that RTP protocol don't have any way to be recognized; have a look here http://www.cs.columbia.edu/~hgs/rtp/faq.html#detect, but I thought, well, perhaps Cisco found some way to identify this protocol implementing some kind of NBAR, but it wasn't. Comercial interest defeat the technical honesty. Well, it's a pitty, really I love Cisco products... This comment is based in the following information taken from the Cisco's site at
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a0080087f42.html#1069826

Well, after this annoyance, let's go to work with our router; we are going to create a class named real-time to identify any kind of traffic crossing our router and being RTP traffic (well, don't trust me, fo.. th.., man..):

match ip rtp has two parameters: the first one is the port number where to start; the next is the range of ports to be covered. Then our class covers all UDP ports from number 5001 up to 5001+16383. Why 5001? Well, I'm using the RTP FAQ's recommendations. Have a look to http://www.cs.columbia.edu/~hgs/rtp/faq.html#ports for more information. 16383 is the maximun range available from this command following Cisco documentation. Some comments: well, I understand that protocols can't be limited to only some ports, but designers of any of them should design their "monsters" having some "protocol payload identification" as IP has. Searching in the IP header you can verify whether you are transporting UDP or TCP or whatever (having an IANA number, of course). But TCP and UDP were not designed with this necessity (very important, indeed) in mind. It would be a dream. Okay, you are an UDP packet, but, what's in your bag, please? The answer should be: no, just DNS, or, i'm carrying here RTP; then we could ask to RTP: what's in you bag? And it could answer: sorry, i'm carrying here counter-strike traffic; do you want it? Following this simple rule life would be a lot easier for people in charging to manage network. Isn't it? And we shouldn't have to buy something as expensive as NBAR from Cisco is. Should we? match mpls experimental This match can be applied only when MPLS is in use. Any people knowing a little about MPLS knows that in the MPLS header exists a 3-bit field called EXP for experimental functions. This field is used to map DS code-point values into EXP values to distribute Diffserv information using MPLS. Being a 3-bit field, the EXP field can have a value from 0 to 7. The mapping is really not easy because DSCP is a 6-bit value, but something can be done. Let's suppose you have a DS domain where you would like to implement five DS classes, i.e., EF, AF11, AF12, AF13 and BE. As long as the classes are less or

where you would like to implement five DS classes, i.e., EF, AF11, AF12, AF13 and BE. As long as the classes are less or equal than seven we could use the MPLS EXP field to distribute our DS classes to our neighbor domains using MPLS tunnels. Let's have a dream that we have implemented this network and let's suppose too that our mapping was decided to be this:

Because we are going to connect the DS domains using MPLS tunnels we are not interested in distributing DS packets through the tunnels, but instead using the MPLS EXP field. This way we need to implement classes in our DS domain ingress routers to identify the five different DS classes. Okay, sitting in front of our care router we type:

Fine!! Now the classes ef, af11, af12, af13 and be of our router should match packets coming from our neighbor domains belonging to these DS classes. Of course, it is required that neighbors make the mapping from DSCP to MPLS EXP before packets are forwarded out of the domains. How to do this will be a theme for an upcoming document in this work, but let's go little by little. match not

Well, match not is not really an additional featuring to match packets, but exactly the contrary, i.e., it is a way to say: I like exactly the contrary that I typed in my command. Continuing with the previous example (mpls experimental), let's suppose we want to create a class that match any packet not belonging to the DS EF class; then, we type in our router:

Really very, very easy. I love Cisco because if you get along with their way to implement configurations, command structure is really very intuitive. match protocol Our next and last matching feature permits us to match a packet based in the protocol the packet carry over. With this feature Cisco made a great job because the list of matching protocols is really impresive. The matching configuration is also very simple. Let's try with an example because I hate too much theory without practical examples. Let's suppose that we are interchanging IPX traffic with another DS neighbor domain. IPX traffic is not a pear in sweet; it plays hard and should be controlled to avoid starvation over TCP traffic that is a good citizen protocol. Have a look here to a sample of what I'm saying. BTW, the document Flows: how they compete for network resources that I'm writing is a very good place to understand how the life of protocols is like our, just a constant fight for the survival. Well, we would like to identify IPX traffic entering to our DS domain and placing it in an special class called ipx-proto. Let's see how to create this class using our Cisco router. Just we type:

Ready... the class ipx-proto now match all packets entering our domain being ipx protocol. What type of protocols can we match? According to Cisco the list is as follows: aarpAppleTalk Address Resolution Protocol apolloApollo Domain arpIP Address Resolution Protocol (ARP) bridgebridging bstunBlock Serial Tunneling cdpCisco Discovery Protocol clnsISO Connectionless Network Service clns_esISO CLNS End System clns_isISO CLNS Intermediate System cmnsISO Connection-Mode Network Service compressedtcpcompressed TCP decnetDECnet decnet_nodeDECnet Node decnet_router-I1DECnet Router L1 decnet_router-I2DECnet Router L2 dlswdata-link switching ipIP ipxNovell IPX llc2llc2 padpacket assembler/disassembler links qllcQualified Logical Link Control protocol

qllcQualified Logical Link Control protocol rsrbremote source-route bridging snapshotsnapshot routing support stunserial tunnel vinesBanyan VINES xnsXerox Network Services

Well, nice. Some well known protocols, some not too much. Still waiting for some mechanism to match RTP protocol packets. Okay, dear fellows, with this explanation we have finished the theme about how to create traffic classes using Cisco. Our next step in our study of Differentiated Service on Cisco will be to study how to create traffic policies. Traffic classes are used to match packets. On the contrary traffic policies are used to implement some control mechanisms over packets. Then, let's go on.

Previous

Content

Next