1 of 1 people found this helpful
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 for the example. I have the following sections already configured:
qos map eth0/0QosWizard 20
match dscp 46
qos map eth0/0QosWizard 21
match ip list acleth0/0QosWizSignal21
set dscp 26
interface eth 0/0
ip address 220.127.116.11 255.255.255.0
ip access-policy Public
media-gateway ip primary
traffic-shape rate 10000000
qos-policy out eth0/0QosWizard
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"
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?
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.
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.
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.