[c-nsp] prioritize VoIP and Skype traffic in office routers

Chuck Church chuckchurch at gmail.com
Fri Feb 3 01:28:14 EST 2012


Martin,

	If you can easily match the VoIP traffic via an extended access
list, that will be fine.  If your ISP is rate limiting you to 20 mbit, you
might want to use shaping or policing to limit your non-preferred traffic to
18 megabit, and then prioritize the VoIP/Skype traffic.  This might take
some fine tuning, but can be done.

Chuck

-----Original Message-----
From: Martin T [mailto:m4rtntns at gmail.com] 
Sent: Wednesday, February 01, 2012 7:59 PM
To: mtinka at globaltransit.net; chuckchurch at gmail.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] prioritize VoIP and Skype traffic in office routers

Mark:

<<You mean as in trying to signal RSVP-based resource <<reservation from
your network to your ISP's network? As in <<IntServ?

I thought manual RSVP reservation. For example there are four routers:

gateway_A <-> ISP_router_A <-> ISP_router_B <-> gateway_B

"gateway_A" and "gateway_B" would be under my management. I thought to
configure "ip rsvp sender" and "ip rsvp reservation" to both gateway
devices, but as much as I understand, this still requires ISP to configure
it's router interfaces for handling RSVP requests.


<<Well, if your ISP won't support QoS, how would you expect to <<have your
QoS policy implemented end-to-end? If you <<implemented it on your routers,
it would only be "on" in <<your network. Once your QoS'ed packets enter your
ISP's <<network, they won't be given any corresponding treatment.

I don't expect my QoS policy to be implemented end-to-end as my ISP doesn't
support this. All I would like to insure is that prioritized traffic(VoIP
and Skype) would get processed in my routers as fast as possible.



Chuck,

yes, it's Ethernet and my connection speed is limited in ISP edge routers
using the CAR(basically "rate-limit input"/"rate-limit output";
exceed-action drop). So for example in case my connection speed is 20Mbps in
both directions(set by ISP), then I should traffic-shape or rate-limit my
traffic to <20Mbps already in my gateways(this brings possible congestion
point to my routers) and configure for example "Priority Queueing" for VoIP
and Skype traffic- did I understand you correctly? In addition, why do you
prefer NBAR for VoIP while this should be doable using the extended
access-list as well?


regards,
martin


Kuupäeval 1. veebruar 2012 18:30 kirjutas Chuck Church
<chuckchurch at gmail.com>:
> Martin,
>
>        It depends on your ISP connections.  If Ethernet, then it's 
> probably rate limited by ISP in one or both directions.  If so, plain 
> prioritization won't help alone, you'll need to police/shape yourself, 
> but send the VoIP/Skype first.  It's do-able.  If your circuits are T1 
> or something else that is essentially line-rate to/from you, then 
> prioritization alone will work.  NBAR is good for VoIP, Skype I'm not so
sure about, haven't tried it.
> Changing the CEF load sharing won't have any effect.
>
> Chuck
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Martin T
> Sent: Wednesday, February 01, 2012 10:57 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] prioritize VoIP and Skype traffic in office routers
>
> I would like to improve packet processing prioritization in case of 
> temporary congestions in my gateways(Cisco 1842,
> C1841-ADVIPSERVICESK9-M) which are serving two small offices in 
> different cities. My ISP(same for both offices) does not support RSVP 
> so I can't make any RSVP requests. In addition, they do not support 
> prioritization based on DSCP or TOS field values. VoIP gateways are
located in office LAN's.
>
> So far I have came up with following ideas:
>
> 1) Process packets passing the router using CEF("ip cef" in global 
> configuration mode). Should I consider changing the load-sharing
algorithm?
> At the moment I use "universal" load-sharing algorithm for CEF.
>
> 2) Change interface queuing strategy(currently it's FIFO) for all Fast 
> Ethernet interfaces in gateways. There are many possibilities like 
> Custom Queuing, CBWFQ, Priority Queuing. "Priority Queuing" seems to 
> be especially appealing in this scenario- Skype and VoIP traffic would 
> have the highest priority and there isn't a worry that they could take 
> all of the available bandwidth. Any opinions here? Is Priority Queuing a
smart decision here?
>
> 3) use WRED
>
>
> For classifying traffic I would use NBAR for 
> Skype(http://www.cisco.com/en/US/docs/ios/12_4t/qos/configuration/guid
> e/qsnb
> arrm.html)
> and transport layer protocol + port numbers for VoIP.
>
> Which interface buffer queuing would be the best in described 
> scenario? Are all three methods reasonable?
>
> PS if any additional information is needed, feel free to ask!
>
> regards,
> martin
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>




More information about the cisco-nsp mailing list