原帖地址：http://www.networking-forum.com/viewtopic.php?f=24&t=3203

 I originally posted this over in the IP Communications forum. However, I think it has value here as well, so I'm going to repost it here (and rework is a bit) for those who may not have seen it. The was originally written to provide QoS for Vonage, but the concepts here apply to any type of traffic.

To configure the QoS for Vonage you don't have to do a whole lot. Here's the configuration you need:

Code:
!
class-map match-any voice-traffic
match  dscp ef 
class-map match-any voice-signal
match  dscp af31 
!
policy-map voice-policy
class voice-traffic
  priority 200
class voice-signal
  bandwidth 8
class class-default
  fair-queue
!
policy-map shaper
class class-default
  shape average 350000 3500 0
  service-policy voice-policy
!
interface FastEthernet4
service-policy output shaper
!


The above configuration was taken directly from my router (which is a Cisco 871 running, currently, IOS release 12.4(11)T3). I'll explain each portion of the above config so you know what it's doing.

a. The class maps defines what type of packets you want to specify for quality of service. In this case the class-maps are specifying two types of traffic, the actual voice data packets, which Vonage marks with a DSCP value of ef (on my RTP300 device), and the voice signaling packets (SIP packets) with DSCP af31. You could also use an ACL here to specify a particular IP/port combination if you so desire.

b. The policy-map voice-policy is how you define how much bandwidth each class gets. In this case the voice-traffic class (the one I defined in the class-map) is getting 200kbps of bandwidth. This is more than enough for a single Vonage phone call (using G711ulaw codec, no VAD). Specifying more than necessary doesn't hurt anything as it will only reserve the bandwidth if needed. The priority command here ensures that this traffic leaves the router before anything else.

Next, I specified 8kbps of bandwidth for the signaling packets. These will be sent after the voice traffic. This guarantees that there will be 8kbps available to get my signaling (SIP) packets through.

Class-default is all your other traffic. Here we aren't specifying any bandwidth to be reserved, as such it will be handled in a standard fair-queueing type fashion where each traffic flow will be given an equal portion of the remaining bandwidth.

c. The policy-map shaper is VERY important. This slows down your interface to the speed of your upload stream. In most cases, your cable modem will have an Ethernet or Fast Ethernet connection to your router. Quality of service only kicks in when a link is congested. If you don't slow down the connection to the cable modem itself the congestion will happen on the cable modem instead of the router. You don't control the cable modem, so you need to handle the congestion on the router. I hope that made sense. Basically this shifts the congestion from the cable modem, where you can't deal with it, to the router, where you can prioritize traffic.

The shape average command is how you define how much you want to limit the interface. In this case I've specified 350kbps, 350000. The next value should always be a 100th of the first, hence the 3500. The last value should ALWAYS be 0. So, for example, if your upload speed was, 230kbps, the command would be "shape average 230000 2300 0". The service-policy voice-policy hooks the bandwidth settings you've configure for your voice traffic to the policy-map you are using to shape the interface down.

d. Lastly, you need to apply all this to an interface. On the 871 the WAN interface is FastEthernet 4. As such, I've applied the service-policy, shaper, in the outbound direction on this interface.

What will all this stuff do? Well, assuming your upload speed is sufficient, you can do whatever you want on your connection, from an upstream perspective, while talking on the phone and the person you are talking to will never notice. Slowing the interface down will also decrease your overall upload speed (I slowed mine from the advertised 384kbps to 350kbps). This is a small price to pay to ensure good, consistent voice quality to the people you call.

How do you tell whether or not the QoS is actually working? Simply enter the command "show policy-map interface" from enable mode on the router. You will see output like this. I'll explain each section:

Bunson#sho policy-map interface
FastEthernet4

Code:
  Service-policy output: shaper

    Class-map: class-default (match-any)
      167867 packets, 85376235 bytes
      30 second offered rate 10000 bps, drop rate 0 bps
      Match: any 
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)  
           768000/768000    960    7680      0         10        960      

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         167829    85346737  53371     47440952  no


The above output tells you whether or not shaping is currently active. When you don't come near the levels you set, it will show as not active. When it is active it will let you know how many packets and how many bytes were delayed by the shaping. This is good because it indicates that you are handling the congestion on the router instead of letting packets pile up on the cable modem.

Code:
      Service-policy : voice-policy

        Class-map: voice-traffic (match-any)
          100580 packets, 21524120 bytes


The above line tells you how many voice packets you've matched. This is important because it tells you that the quality of service is working. When you are on a call this will increment. Since the last time I reloaded the 871 it matched 340 thousand voice packets.

Code:
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            100580 packets, 21524120 bytes
            30 second rate 0 bps
          Queueing
            Strict Priority
            Output Queue: Conversation 72 
            Bandwidth 90 (kbps) Burst 2250 (Bytes)
            (pkts matched/bytes matched) 23947/5124658
            (total drops/bytes drops) 0/0


You should check the above "total drops" value. For the voice-policy it should always be 0. If it isn't you need to increase the amount you specified in the "priority" statement under the voice-traffic section of the policy-map.

Code:
        Class-map: class-default (match-any)
          65926 packets, 63283640 bytes
          30 second offered rate 10000 bps, drop rate 0 bps
          Match: any 
          Queueing
            Flow Based Fair Queueing
            Maximum Number of Hashed Queues 64 
          (total queued/total drops/no-buffer drops) 0/11961/0


class-default is the rest of your traffic. You should see drops (total drops) here. This is exactly what it sounds like, dropped packets. This is ok because if you drop a data packet you can always send it again. Resending a voice packet is worthless because you can't rewind a conversation, it would sound bizarre.

Note, none of this applies to the packets coming inbound to your phone. You have no control over that.