[c-nsp] Gut check needed - QoS

[Graham Wooden]

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" <paul at paulstewart.org> 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:
> cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]
> 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
> cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
a
> rchive at 
> http://puck.nether.net/pipermail/cisco-nsp/

_________________________________
> ______________
cisco-nsp mailing list
> cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
a
> rchive at http://puck.nether.net/pipermail/cisco-nsp/