Policy-map on tunnel or physical interface?

Question

Hi all,
I have a 3800 headend router which has a number of ipsec tunnels to remote office sites. Our current QoS design applies a policy-map to each tunnel interface to prioritise and shape outbound traffic.
My question is how does the physical egress interface queue and transmit traffic from tunnel interfaces with this design? For example, if a mixture of large data packets and voice packets from different tunnel interfaces hit the physical interface around the same time what will happen to the voice packets?
Furthermore, would it be a better to apply the policy-map to the physical interface instead of the tunnel interfaces? What advantages if any would this bring?
Many thanks.

Answer 1

If you're shaping each tunnel to the outbound physical bandwidth, yes it would be better to just have the policy, without any shaping, on the physical interface. Again, you'll will either need to depend on a copied ToS value in the outbound packet or use qos pre-classify. (A single physical policy would be much like your QUEUE_DATA if using qos pre-classify.)
e.g.
!assumes qos-preclassify
interface Ethernet0
service-policy output QUEUE_DATA
What I thought you might be doing, and you could also do, was shape each tunnel to the far side's ingress bandwidth. This would require a distinct policy, if the shaper values change, for every tunnel interface, or a policy on the physical interface that has a class per tunnel (matches against tunnel destination address).
e.g.
!assume local outbound interface not oversubscribed
policy-map NESTED_QOS_512K
class class-default
shape average 512000
service-policy QUEUE_DATA
policy-map NESTED_QOS_768K
class class-default
shape average 768000
service-policy QUEUE_DATA
policy-map NESTED_QOS_1500K
class class-default
shape average 1500000
service-policy QUEUE_DATA
interface Tunnel1
service-policy output NESTED_QOS_786K
interface Tunnel2
service-policy output NESTED_QOS_512K
interface Tunnel3
service-policy output NESTED_QOS_1500K
interface Tunnel4
service-policy output NESTED_QOS_512K
e.g.
!assume local outbound interface not oversubscribed
class-map match-all Tunnel1
match group (ACL that matches tunnel1 destination address)
class-map match-all Tunnel2
match group (ACL that matches tunnel2 destination address)
policy-map outbound_tunnels
class Tunnel1
shape average 768000
service-policy output QUEUE_DATA
class Tunnel2
shape average 512000
service-policy output QUEUE_DATA
Interface Ethernet 0
service-policy outbound outbound_tunnels
If all the far side bandwidths exceed your local outbound physical bandwidth, then you should have both tunnel policies, that shape each tunnel, and a physical interface policy.
e.g.
!assume local outbound interface is oversubscribed
policy-map NESTED_QOS_512K
class class-default
shape average 512000
service-policy QUEUE_DATA
policy-map NESTED_QOS_768K
class class-default
shape average 768000
service-policy QUEUE_DATA
policy-map NESTED_QOS_1500K
class class-default
shape average 1500000
service-policy QUEUE_DATA
interface Tunnel1
service-policy output NESTED_QOS_786K
interface Tunnel2
service-policy output NESTED_QOS_512K
interface Tunnel3
service-policy output NESTED_QOS_1500K
interface Tunnel4
service-policy output NESTED_QOS_512K
!assumes qos-preclassify
interface Ethernet0
service-policy output QUEUE_DATA