Interesting, thanks for that Wen. Our QoS is primarily aimed at ensuring bandwidth for certain applications, but we do use the priority command to ensure voice traffic is queued faster so that will be our problem, I think; in essence our QoS is configured as follows:
- A series of ACLs define the traffic to match on (some port-based such as TCP25, TCP3389 etc. and some address-based such as any traffic from certain servers)
- A series of class maps reference these ACLs
- A policy map is then used to set outbound bandwidth and priority statements against those class maps - our requirement here is to ensure certain traffic gets a stated amount of the bandwidth, and the priority statement ensures voice traffic is queued first (unless we've got that wrong!?)
- A second policy map is then used to shape traffic to the remote router (based on a class map that refers to an ACL matching the destination IP range) and also applies the first policy map
The policy maps are as follows:
policy-map qos_setoutbound_lb-sh_pm
class qos_voip_cm
priority 3072
class qos_rdp_cm
bandwidth 2048
class qos_msds_cm
bandwidth 2048
class qos_rmi_cm
bandwidth 1024
class qos_http_cm
bandwidth 5632
class class-default
fair-queue
random-detect dscp-based
policy-map qos_shapeoutbound_lb-sh_pm
class qos_to_lb-sh_cm
shape average 18000000
service-policy qos_setoutbound_lb-sh_pm
The command on the tunnel interface is: ip nhrp map group LB_tunnel0 service-policy output qos_setoutbound_lb-sh_pm
I think that the policy map that sets the priority and bandwidth statements would be the problem then, as that affects the queuing? I'd be interested in what you think a solution might be - maybe we mark traffic on the ingress to the hub router (from the LAN) and then let the QoS engine queue based on that?
Frustrating that this restriction isn't listed in the Cisco document, which has a "restrictions" section....
Cheers,
Tom
