|
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. |
|
| 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: |
| |
|
|
| |
| |
| 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: |
| |
|
|
| |
| 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: |
|
| 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 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 |
| 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 x-DSCP values presented
in the next table, that we have stolen from our previous work
Differentiated Service on Linux HOWTO. |
| |
|
|
| |
| |
| 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: |
|
|
|
|
|
|
| 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
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: |
- aarp—AppleTalk Address Resolution Protocol
- apollo—Apollo Domain
- arp—IP Address Resolution Protocol (ARP)
- bridge—bridging
- bstun—Block Serial Tunneling
- cdp—Cisco Discovery Protocol
- clns—ISO Connectionless Network Service
- clns_es—ISO CLNS End System
- clns_is—ISO CLNS Intermediate System
- cmns—ISO Connection-Mode Network Service
- compressedtcp—compressed TCP
- decnet—DECnet
- decnet_node—DECnet Node
- decnet_router-I1—DECnet Router L1
- decnet_router-I2—DECnet Router L2
- dlsw—data-link switching
- ip—IP
- ipx—Novell IPX
- llc2—llc2
- pad—packet assembler/disassembler links
- qllc—Qualified Logical Link Control protocol
- rsrb—remote source-route bridging
- snapshot—snapshot routing support
- stun—serial tunnel
- vines—Banyan VINES
- xns—Xerox 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
|
