7100 QoS marking

[Anonymous]

What is the best to mark the SIP traffic to our upstream SIP provider?  I tried going through the QoS wizard, but it would not let me select the SIP port (udp 5060) or the SIP providers IP as the match to then mark the packets.nv7100.  Our Internet circuit was recently upgraded and now has provisions for QoS.  The ISP and the SIP provider are the same company, so one would hope they honor the QoS tags through their network.  I have tried marking them at the Internet router (outside the firewall), but I am still getting complaints of poor voice quality.

Thanks

[Anonymous]

The NetVanta will preserve DSCP and IP Precedence values when they are routed out. Assuming you are using Polycom or ADTRAN IP 700 phones with a NetVanta 7100 you should be fine matching on DSCP 46 for RTP.  Here is an example of how to setup QoS using an Ethernet WAN.  I would suggest finding out from the provider what DSCP values they prioritize to make sure they will be honored.  Generally speaking, QoS cannot be guaranteed on the Internet, but as you implied maybe since the ISP is also the SIP provider they have more control than a typical setup.

Thanks,

Matt

[Anonymous]

Matt,

Thanks for the example.  I have the following sections already configured:

qos map eth0/0QosWizard 20
  match dscp 46
  priority 2048
qos map eth0/0QosWizard 21
  match ip list acleth0/0QosWizSignal21
  set dscp 26

interface eth 0/0

  description WAN

  ip address  64.8.57.21  255.255.255.0

  ip access-policy Public

  media-gateway ip primary

  traffic-shape rate 10000000

  qos-policy out eth0/0QosWizard

  no shutdown

  no lldp send-and-receive

ip access-list extended acleth0/0QosWizSignal21

  permit udp any  any eq 5060

  permit tcp any  any eq 5060

Do I need to modify any of these?  From the example that only thing I think should be modified is:

qos map eth0/0QosWizard 20

  match dscp 46 26  <-- Add the "26"

  priority 2048

Since the eth0/0 port is not used for general WAN Traffic (that goes through a separate firewall) should I remove the "traffic-shape rate 10000000" from the eth 0/0 interface?

[Anonymous · Accepted solution]

If you can confirm with the ISP/SIP provider they prioritize DSCP 46 for RTP and 26 for SIP (call control signaling) then you don't need to use the second qos map entry to set a DSCP value.  I would recommend removing it, especially since it is remarking RTP from 46 down to 26. It is also a good idea to add 26 to the match criteria like you suggested from the example.

At the 10,000 foot level QoS works by pushing important traffic tagged in a special manner that makes it identifiable ahead of other traffic in a low latency queue (LLQ).  If there is not enough traffic to saturate the egress interface, the router does not think it needs to prioritize anything since there appears to be enough bandwidth for everyone to enjoy.  On many interface types the available bandwidth that is calculated and reported to QoS can be trusted (T1, DDS, ISDN), but that is not always the case with an Ethernet interface.  For example the interface may negotiate at 100 Mbps, but your guaranteed throughput to the ISP is likely not 100 Mbps.  This is where the traffic-shape rate command comes in.  It is used to set the bandwidth threshold so QoS knows when to engage.  This should be set to the upload speed of the circuit.  To build on our example, if you have a 5 Mbps upload, you can use the traffic-shape rate command on the Ethernet interface to have it believe there is really only 5 Mbps instead of the 100 Mbps that is reported by default when it comes up.  One gotcha, is this can be tricky unless you have an absolute guaranteed and stable upload speed, which you would normally get with a private dedicated circuit.  For example, I have a cable modem from my ISP and the upload speed can fluctuate drastically from one minute to the next depending on the load of their network from other subscribers.  If this is the case with your Internet connection it may be best to shape down to a level that you are confident will be available most of the time, unless you can get a guarantee from your ISP.

Thanks,

Matt

[Anonymous]

Matt,

I have adjusted the QoS maps, so we will see what happens.  The problem with the traffic shape rate is that the 7100 WAN port is connected to a switch that also has several other devices (some ours, some not) that then feeds into a main router that is connected to the 30Meg Up - 30Meg Down fiber connection from the upstream provider.  I have verified that the main router has a 512K priority queue that will match the af31 and ef marking.  The SIP trunk is setup for 6 call paths, so 512K should be a big enough queue.   Since the phone tend to ring off the hook, I'll know pretty quick if things are working.

[Anonymous]

Matt,

I have setup a monitor port on the switch that the 7100 is plugged into and I was able to confirm that the SIP traffic is marked with af31 and the RTP traffic is marked with ef.  Thanks for your advice.