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

[Martin T]

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/guide/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/
>