Hello

As a first step I would recommend you configure a bandwidth on all your interfaces to reflect the actual configuration in your network. For example if interface GigabitEthernet0/1 is actually a 10 Mbps connection to a remote site, configure bandwidth 10000 under the interface.

Secondly, in your current configuration you apply your QoS policy under the sub-interface GigabitEthernet0/1.100 for VoIP, so actually the Data traffic will never be subjected to it (since it arrives on another sub-interface GigabitEthernet0/1.1). I would recommend you apply the QoS policy on the physical interface GigabitEthernet0/1. It is then inherited by the sub-interfaces and therefore applied to all traffic.

Finally regarding your configuration of the QoS policy itself, rather than matching vlan 100 in your class-map I would match either the IP range of the VoIP phones (in ACL) or match all packets marked with DSCP=EF (also in ACL but make sure that no intermediate device clears the marking). I would recommend also adjusting your QoS policy as follows:

policy-map P_BW_GUARANTEES
 class VOICE
    priority percent 30
 class class-default
    bandwidth remaining percent 100
    
policy-map P_SHAPE
 class class-default
    shape average 10000000
  service-policy P_BW_GUARANTEES
 

In the configuration above you have a policy P_SHAPE for shaping all outgoing traffic to 10 Mbps and it has a nested policy P_BW_GUARANTEES, which gives VoIP traffic priority handling up to 30% of the port speed and everything else then gets the remaining bandwidth. You apply the QoS policy P_SHAPE on the physical interface GigabitEthernet0/1 in outbound direction. Verify using: show policy-map interface GigabitEthernet0/1

Please note: the priority command has a built-in policer which will limit your VoIP traffic to 30% of the port speed so that it doesn't override all other queues (and starve them).

Best regards,
Martin

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

As Martin has correctly noted, if you're going to shape traffic for 10 Mbps, you'll need to shape all the traffic, and then in a child policy, manage any shaped congestion.

But to your principal question, no, what you're (or Martin) is trying to do won't be effective if you're dealing with a multi-point network.  The problem with such networks, if two (or more) sites can send to another site, concurrently, what manages the WAN cloud egress bandwidth to that site?  To address this issue, either your WAN vendor needs to support QoS too, or you need to shape all your sites egress bandwidth so the possible aggregate doesn't exceed the available bandwidth.

For example, from what you've described, as seven sites might (in theory) transmit to one site, you can shape each to 10/7 Mbps.

If you do such shaping, you can experiment with over subscription and/or asymmetrical (i.e. all sites don't have to be the same) bandwidth allocations (e.g. branches could all use 1, while main uses 3).

BTW, on many routers, I believe the shaper doesn't count L2 overhead, if not, you need to set your shaped value lower to allow for it (I've found 15% a good general allowance).

There are a couple of things missing that may help. First, where are the phone servers, all at the main site, or distributed? How many IP phones are at each site?

With that information, you have a shot at determining the concurrent call count. This article provides excellent explanations of the different codecs and includes a link to Cisco's Voice Codec Bandwidth Calculator: http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html#topic1

Also, check with your service provider and see if they require a command, such as "traffic-shape rate 10000000" on the main interface to complement the "bandwidth 10000" statement. Be careful, the bandwidth statement is in kbps and the traffic-shape rate command is in bps.

Last, do you need to support anything else in the LLQs? If yes, again be careful, since Cisco's best practice is to allocate no more than 33% for the priority queues: http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/WANQoS.html

Please update us and let us know if it's working.