> > On Tue, May 22, 2007 at 01:48:48PM -0400, Lamar Owen wrote: > > On Tuesday 22 May 2007, Nassess, George wrote: > > > I am in the process of extending our distributed VoIP > call center to a > > > partner company, and their networking staff are extremely > adamant that > > > they do not wish to implement QoS on their remote LAN, > the DS3 link that > > > the voice traffic will traverse, or the core LAN in our shared > > > datacenter. > > > > I too would like to see a good discussion of this, as I'm > getting prepared to > > implement VoIP here, on an 8540MSR core with Catalyst 5500-series > > distribution-access switches (using RSM's and RSFC's in > each 5500-series to > > provide dual layer 3 uplinks into the core, collapsing access and > > distribution); Cat 5500's and 8500's don't implement all > the things VoIP is > > supposed to require, but I'd like to see both sides, too. > > I've typically "cheated" in doing voip QoS by rate-limiting TCP > traffic in one direction. This keeps the TCP traffic from taking the > entire link and results in a basic reservation of traffic. > > here's an example: (you may need to modify this based > on platform) > > interface Serial0/0 > description T1 to somewhere > ip address 1.2.3.4 0.0.0.0 > rate-limit input access-group 106 1280000 4470 8000 > conform-action transmit exceed-action drop > ! > access-list 106 permit tcp any any > ! > > The result is ~256k of reserved bw on a t1, enough for ~2x88k > g711ulaw streams. > > simulating the tcp loss with the rate-limit causes tcp > to think the > link is smaller, yet leaving headroom for the udp bits :) > > works well for a home network, you may need to adjust > depending on > other streaming media applications that are udp based > (perhaps they need to get > matched in your access-list 106) and depending on what you do. > > As long as you don't have any true congestion and output drops > on your interfaces (i assume you graph these?) you should be > ok without the > qos stuff. > g711ulaw streams. > > simulating the tcp loss with the rate-limit causes tcp > to think the > link is smaller, yet leaving headroom for the udp bits :) > > works well for a home network, you may need to adjust > depending on > other streaming media applications that are udp based > (perhaps they need to get > matched in your access-list 106) and depending on what you do. > > As long as you don't have any true congestion and output drops > on your interfaces (i assume you graph these?) you should be > ok without the > qos stuff. > > - jared
Who or why are people against using a policy map that allows "up to x" of bandwidth for the specified (ACL, class-map) but is available for all other traffic when there is no VOIP ? This seems backwards / worse to me to restrict the pipe and loose that much available bandwidth for other apps when there is no VOIP ? Eric _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
