Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

Help on Interesting VoIP QoS Scenario

I have a bit of an interesting problem with configuring QoS for inter-office VoIP. We have a network consisting of approximately 20 offices including a headquarters, two regional headquarters, and 17 remote offices. In nearly every office we have a MC3810 serving as a voice gateway between the PBX and private network. We then use VoIP to handle nearly all inter-office voice to save on long distance charges.

The problem is that our 'private' network really isn't that private. Every office has a subnet within the reserved IP address range for the internal Ethernet side, and a public IP address for the serial port going over Sprint's IP network. We then use IP tunnels for all inter-office data traffic and any internet-bound traffic gets NAT'ed and not tunneled. Therefore, all 'private' traffic is really just encapsulated in an IP tunnel over an internet backbone.

Trickier still is that the headquarters and regional headquarters offices have much higher bandwidth than the remote offices. Any sort of traffic shaping that I've investigated would either severely limit the headquarters-to-regional-headquarters bandwidth or allow flooding of the headquarters-to-remote-office pipe.

Right now, I am using policy-maps to establish a reserved amount of bandwidth for traffic matching ip precedence 5, which I've assigned to VoIP packets using the "ip precedence 5" command on each VoIP dial-peer. The config looks like:

class-map match-all voip

match ip precedence 5

!

policy-map ipwan

class voip

priority 204

class class-default

fair-queue

Then the serial interface is given the command "service-policy output ipwan". My first question is whether or not that has any effect whatsoever since the packets (I presume) have already been encapsulated within the tunnel before they hit the serial interface. Does the precedence get set on the tunnel packet if the packet it's encapsulating has a precedence set?

Right now, the VoIP is behaving like there is little or no QoS applied at all. Any kind of significant transfer being initiated results in horrible jitter on the receiving end's voice conversation. Is there any way to verify that precedence 5 packets are being matched and sent with a guaranteed bandwidth priority? Any help that could be provided would be greatly appreciated.

Thanks,

James Willard, CCNA

james@whispering.org

3 REPLIES

Re: Help on Interesting VoIP QoS Scenario

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center (http://www.cisco.com/tac) or speak with a TAC engineer. You can open a TAC case online at http://www.cisco.com/tac/caseopen

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

Cisco Employee

Re: Help on Interesting VoIP QoS Scenario

James,

Do you have point to point lleased line connections on the Sprint network? Or is your traffic just going to a Sprint IP cloud?

If the first option, take a look at this document:

http://www.cisco.com/warp/public/788/voice-qos/voip-mlppp.html

It provides good guidelines.

Carlos

New Member

Re: Help on Interesting VoIP QoS Scenario

The T1s are not point-to-point, but they are not frame relay. They're all T1s terminating directly into Sprint's IP backbone. We don't have QoS guaranteed over those links, but the circuits are only one or two hops away from each other on the Sprint backbone. The problem seems to be more related to the headquarters having four times the bandwidth as the remote office flooding the remote office with traffic.

99
Views
0
Helpful
3
Replies
CreatePlease to create content