QoS voice traffic on WAN of Cisco 1841

Question

I have the following lab topology and I am using the below configuration on the 1841. What I want to achieve here is reserve 1000Kbps of bandwidth for traffic between the voice VLAN and the remote VoIP provider across the Internet (lets pretend; 10 users, each needs 100Kbps of up and down bandwidth for RTP, and they all always use the phone at the same time).

The pfSense device is just to limit the wan connection of the 1841 as this will go on the end of a 20Mbps Internet connection presented as Ethernet eventually. It plays no further role in this scenario (no NAT, or Firewalling, just plain L3 routing between LAN and WAN interfaces, limiting the traffic).

class-map match-any CM-VOICE-TRAFFIC
 match access-group 145

policy-map PM-PRIORITISE-VOICE
 class CM-VOICE-TRAFFIC
   bandwidth 1000
 class class-default
   fair-queue

interface FastEthernet0/1
 service-policy output PM-PRIORITISE-VOICE

access-list 145 permit ip any 10.0.59.0 0.0.0.255
access-list 145 permit ip 10.0.59.0 0.0.0.255 any

The configuration I have given is only applied outbound on the WAN interface (so I have guaranteed 1000Kbps of traffic to the voice VLAN for their upstream path towards the VoIP provider). What can I do to guarantee the downstream bandwidth of the voice VLAN on this 1841 only?

Is it possible to create an inbound policy on fa0/1 (WAN) that prioritises packets that match access-list 145, as they pass through the router, so that other packets inbound on WAN don't affect the downstream speed of the voice VLAN (peraps queuing packets that don't match ACL-145)?

Or is it possible to create a policy on the physical fa0/0 interface, even though it is split into two sub interfaces, that will guarantee 1000Kbps of the traffic out of it, towards the voice VLAN, when it needs it?

Answer 1

The short answer is no.  Your queuing policy needs to be applied outbound at the point of bottleneck.  In this case, the bottleneck is the WAN connection (20 Mbps) between the pfSense and the 1841.  Thus, the proper location of your queuing policies are outbound on the LAN interface (a bit of a misnomer) of the pfSense and outbound on Fa0/01 of the 1841, which you have.

All that being said, your policy on the 1841 is flawed.  In your example, you've reserved 1 Mbps of bandwidth for VoIP and applied the policy to a 100 Mbps interface.  What happens when the PCs start pushing 70Mbps of traffic while trying to make a VoIP call?  From a queuing standpoint on the 1841, the answer is nothing.  There is only 70 Mbps of data flowing out Fa0/1.  Therefore, there is always 1 Mbps available for VoIP.  However, once this traffic reaches the pfSense,  at least 50 Mbps of data and VoIP will be dropped.  Your calls would be terrible at best.

Without getting into all of the details, and using your prior example, the policy should be something like this:

class-map match-any CM-VOICE-TRAFFIC
 match access-group 145
!
policy-map PM-PRIORITISE-VOICE-child
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map Shape-20Mb-parent
 class class-default
  shape average 20000000
  service-policy PM-PRIORITISE-VOICE-child
!
interface FastEthernet0/1
 service-policy output Shape-20Mb-parent
!
access-list 145 permit ip 10.0.59.0 0.0.0.255 any

This policy creates an artificial bandwidth limit on all traffic leaving the Fa0/1 on the 1841.  Thus, the pfSense will never have the opportunity to drop traffic indiscriminately.  Also, instead of the bandwidth command, the priority command should be used to limit latency and jitter.  The tagging and the ACL change should be self-explanatory.