[c-nsp] QoS on a 6509/720

John Kristoff jtk at northwestern.edu
Wed Sep 21 17:07:17 EDT 2005


I have a mandate (so don't try to stop me :-) to implement QoS knobs
on a network motivated by a VoIP deployment.  I've been reading my fair
share of Cisco doc, RFCs, research/workshop papers and others'
implementation reports and now my brain is really starting to hurt.

I feel like I've gotten to a place where I'm pretty familiar with a lot
of the terminology and vendor implementation nuances on the 6509/720
(3BXL) running 12.2(18)SXE2 native, but I've come to a point where I
could use some help putting a lot of this together as I'm not sure I'm
there yet.  I'll post some of my refs below for those who may come after
me that want to try to fill their head with the QoS kool-aid.

First, according to this post from Ian a couple of years ago:

  <http://puck.nether.net/lists/cisco-nsp/8646.html>

under hybrid and an older version of code, if 'mls qos' is applied
globally and a port's QoS state is untrusted, packets entering that
port will have their ToS (DiffServ codepoint) rewritten to the port's
default (which should typically be CS0 - best effort).  Is that still
the case with the box I'm running?  I've got a port on a WS-X6724-SFP
that is configured as a simple /31 LAN port.  Doing a 'show queueing
interface' on that port indicates that Port QoS is enabled and it is
in the untrusted state.  The default CoS is shown as 0.  However, I
send a probe packet with a codepoint that is not equal to zero and
I can see it come out the other side with the same codepoint.

Second, since in this network there is never any congestion I don't
want to get too "cute" with all the QoS knobs, so instead I'm opting
to make it as simple as possible so that we can say it is turned on
and prove under stress tests, but otherwise it shouldn't really do
anything (because there isn't any congestion) - including breaking
existing apps.  From what I've been able to uncover thus far I thought
I could do something like:

  mls qos
  !
  class-map match-all dscp-ef
    match dscp ef
  !
  policy-map edge-ingress
    class dscp-ef
      police flow mask src-only 128000 4000 conform-action transmit exceed-action drop
  !

where the edge-ingress policy-map gets applied as follows:

  service-policy input edge-ingress

on all the edge (end hosts only) networks (VLAN interfaces actually)
where there may be VoIP software clients on hosts.  The reason for
the policer is to simply limit how much expedited forwarding (EF)
traffic I'm willing to accept from any one source host.  I don't like
having to just drop the excess, but remarking doesn't seem like a good
option since it'll probably end up in another egress queue and may
result in out-of-order packets, which isn't anymore useful.

On inter-router ports (except for any facing the outside world) set
the following since I'll have some relative trust of EF packets and
I don't think I really care about the rest (for now):

  mls qos trust dscp

There will be some VoIP "server" or trusted networks where that is
applied as well.

Note, I've mostly got interfaces that are of the 1p2q2t and 1p3q8t
variety.  While it might be nice to tweak the use of them, possibly
even remarking some excessive packets based on a src-only microflow
(nothing to do with VoIP, but for handling at the external border)
the defaults seem good enough for now.

Will this basic setup "do the right thing", in that EF packets go
via the priority queue on any port's egress when possible and the
other packets go into their default queues and drop policies?  Am I
missing something in the input policy?  Do I even need an output
policy if I want to use the defaults as specified above?

Thanks for any clue.

References I've found helpful:

  RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
  RFC 2475 - An Architecture for Differentiated Services
  RFC 2597 - Assured Forwarding PHB Group
  RFC 3246 - An Expedited Forwarding PHB (Per-Hop Behavior)
  DiffServ - The Scalable End-to-end Quality of Service Model 
    Cisco whitepaper http://www.cisco.com/en/US/tech/tk543/tk766/technologies_white_paper09186a00800a3e2f.shtml
  Cisco's Quality of Service for Voice over IP whitepaper
    http://www.cisco.com/en/US/tech/tk652/tk698/technologies_white_paper09186a00800d6b73.shtml
  Cisco 6500 Series Cisco IOS Software Configuration Guide, 12.2SX - Configuring PFC QoS
    http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a00801679f8.html
  Cisco - QoS Classification and Marking on Catalyst Family 6000 Switches Running in Cisco Integrated IOS (Native Mode)
    http://www.cisco.com/en/US/partner/products/hw/switches/ps700/products_tech_note09186a008014a29f.shtml
  QoS Policing on the Catalyst 6500/6000 Series Switches
    http://www.cisco.com/warp/public/473/102.html
  QoS Output Scheduling on Catalyst 6500/6000 Series Switches Running Cisco IOS System Software
    http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bf98.shtml
  QoS Output Scheduling on Catalyst 6500/6000 Series Switches Running CatOS System Software
    http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801091a5.shtml - has additional WRED, WRR and tail drop details
  ACM 2003 Workshop on Revisiting IP QoS: Why do we care, what have we learned? (RIPQOS)
    http://www.acm.org/sigs/sigcomm/sigcomm2003/workshop/ripqos/ripqos.html
  Failure to thrive: QoS and the Culture of Operational Networking
    http://portal.acm.org/citation.cfm?id=944592.944595
  ESnet Project Close Out Report - Testbed deployment of QoS
    http://www.es.net/hypertext/welcome/pr/DOE_NGI_TESTBED_REPORT3_Dec01.pdf
  MOREnet Bandwidth Management/Quality of Service - Implementation and Overview documentation
    http://www.more.net/services/bandwidth/documentation/

John


More information about the cisco-nsp mailing list