Hey there Paul, I have considered that, but I do have some clients that are not on my voice platform (yet) and I need to match by ports. With RTP being mostly in that range, I needed to cover all my boxes as I have some that NBAR doesn't seem to work. So you can see my dilemma with that as I wanted to standardize on one setup oppose to have several different tweaks out there ...
I will have to keep a close eye out on the policy-map stats and maybe ultimately saying "screw it" and match to the voice switch VLAN. Thanks again for the reply and re-assurance. -graham On 9/19/09 7:31 AM, "Paul Stewart" <[email protected]> wrote: > Hi Graham... That should work just fine... One minor thing to note by > matching UDP port ranges.. any traffic (not just RTP) that hits those ranges > will get priority .. typically not a big thing but worth mentioning. In my > earlier posting, I was actually matching by the IP blocks where the softswitch > platform (Metaswitch) is deployed vs port ranges. Priority will only use > bandwidth as it requires it so yes, the default class will have access to all > the bandwidth until something "prioritized" needs it.... Hope this > helps... Paul -----Original Message----- From: > [email protected] [mailto:[email protected]] > On Behalf Of Graham Wooden Sent: September 18, 2009 10:00 PM To: > cisco-nsp Subject: [c-nsp] Gut check needed - QoS Hi all, Paul?s email from > yesterday regarding QoS on a T1 link got me thinking about a recently deployed > PtP T1 serving the same purpose, data/voip to a customer. The routers > involved on each side are not fancy; my T1 edge is a 2621 and the CPE is a > 1760. The 2621 is hanging off of my 6500/Sup32 that handles my core stuff. > My softswitches are hanging off of the same chassis. The CPE 1760 is plugged > into switch that has a PIX and a Linksys SPA8000 ATA. Below is what I had > deployed. Pauls email from yesterday and talking with a good friend earlier > confirmed some of this. I > reviewed http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note091 > 86a0080 103eae.shtml to double check the use between ?priority? and > ?bandwidth?. Priority appears to be a better fit. Both sides have the same > config applied. Does anyone see anything wrong? I am not 100% sure on the > ?ip route-cache policy? under the serial 0/0. I don?t see it too often in > other configs and examples. While this particular ATA does the RTP in a > smaller port range, I like the ACL ranges as I have started to deploy this in > other situations (where RTP is very random between ports 10K and 20K). And > lastly, Is it safe to assume that the class-default will have access to the > full T1 until calls start rolling through? TIA, -graham ----- class-map > match-any VOIP description "Prioritize SIP and RTP" match access-group > 101 ! policy-map VOIP class VOIP priority percent 50 class class-default > fair-queue ! interface Serial0/0 bandwidth 1536 ip address n.n.n.n > 255.255.255.252 no ip unreachables no ip proxy-arp ip route-cache policy > no ip mroute-cache load-interval 30 service-module t1 cablelength short > 110ft service-module t1 timeslots 1-24 service-policy output > VOIP ! access-list 101 permit udp any any range 4000 5999 access-list 101 > permit udp any any range 10000 > 20000 _______________________________________________ cisco-nsp mailing list > [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp a > rchive at > http://puck.nether.net/pipermail/cisco-nsp/ _________________________________ > ______________ cisco-nsp mailing list > [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp a > rchive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
