Cisco has implemented a number of features that allow us control over packet prioritization, which allows us to give priority treatment to specific applications. One of these features is the command
ip rtp priority starting-rtp-port-number port-number-range bandwidth
(There’s a related Frame Relay version of the command.) RTP is encapsulated in UDP packets and the port numbers are what are used to determine packets for the priority queue. This is a good control and is easily understood.
There is a problem with this command. It prioritizes any packets that fall into the specified UDP port range. What’s to keep other applications (Skype comes to mind) from gaining access to higher priority for its packets by finding and using these UDP ports? Unlike the CBWFQ configurations, there is no access list or NBAR-based filter to identify which packets should receive high priority treatment.
Cisco’s documentation also notes that we must monitor the amount of bandwidth being used by the priority packets because no admission control filtering is specified. (Question that I don’t yet have answered: Does call admission and RSVP know the bandwidth configured for priority queues and do the right thing?) Monitoring queue utilization and queue drops seems like the appropriate way to anticipate unplanned congestion and the resulting packet loss on interfaces configured with RTP priority queueing.
-Terry
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
