Cisco qos, service-policy on output interface on 1100 ISR seems ignored

Question

I am trying to configure QoS for a specialty purpose application, and it is the first time I have done QoS. This is on an 1100 ISR with IOS XE 16.09.03.

The device is a set of 4 that establish a mesh of tunnels over a private WAN (2 on each end) that has limited bandwidth (10mbs). The anticipated total traffic is only about 3mbs, but we want to shape and queue the traffic just in case so certain traffic is always carried with low latency and jitter.

I can't get the output traffic to see the policy map at all, or at least it does not appear to. The traffic is properly tagged and transported (I can sniff it at each end) but when I simulate an excess of traffic it is dropped randomly.

Here are the relevant parts (I hope):

policy-map XXXXX_QoS_Queues_Out
 class Class_MATCH_EF
  priority percent 35
 class Class_MATCH_CS3
  bandwidth percent 15
 class Class_MATCH_CS2
  bandwidth percent 15
 class class-default
  bandwidth percent 35

policy-map TRAFFIC_SHAPER
 class class-default
  shape average 9000000
   service-policy XXXXX_QoS_Queues_Out

Traffic is tagged by input policy maps and all that seems to work (which is why I'm not cluttering this with all those access lists and classes), we have only 3 tags plus "other". The issue does not seem to be whether it is getting into the right queue, or getting the right tags, but whether the TRAFFIC_SHAPER and XXXX_QoS_Queues_Out does anything at all.

The tunnel looks like this:

interface Tunnel1
 ip address 172.26.51.1 255.255.255.0
 ip pim dense-mode
 ip hello-interval eigrp 10 1
 ip hold-time eigrp 10 3
 delay 1
 qos pre-classify
 tunnel source Vlan200
 tunnel mode ipsec ipv4
 tunnel destination xx.xx.xx.xx
 tunnel protection ipsec profile IKEV2_IPSEC_PROFILE

interface Vlan200
 ip address xx.xx.xx.xx 255.255.255.240
 ip access-group PROTECT-WAN-PORT in

interface GigabitEthernet0/1/7
 switchport access vlan 200
 switchport mode access
 service-policy output TRAFFIC_SHAPER

I'm attempting to shape the overall traffic to 9mbs, with percentages as indicated going to different traffic. But the issue is I never see it even using the policy-map (this show taken while the circuit is pretty saturated):

#show policy-map int gi0/1/7
 GigabitEthernet0/1/7

Service-policy output: TRAFFIC_SHAPER

Class-map: class-default (match-any)
  34 packets, 13206 bytes
  5 minute offered rate 0000 bps, drop rate 0000 bps
  Match: any
  Queueing
  queue limit 64 packets
  (queue depth/total drops/no-buffer drops) 0/0/0
  (pkts output/bytes output) 0/0
  shape (average) cir 9000000, bc 36000, be 36000
  target shape rate 9000000

  Service-policy : XXXXXremmove_QoS_Queues_Out

    queue stats for all priority classes:
      Queueing
      queue limit 512 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0

    Class-map: Class_MATCH_EF (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match:  dscp ef (46)
      Priority: 35% (3150 kbps), burst bytes 78750, b/w exceed drops: 0


    Class-map: Class_MATCH_CS3 (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match:  dscp cs3 (24)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      bandwidth 15% (1350 kbps)

    Class-map: Class_MATCH_CS2 (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match:  dscp cs2 (16)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      bandwidth 15% (1350 kbps)

    Class-map: class-default (match-any)
      34 packets, 13206 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      bandwidth 35% (3150 kbps)

Notice the tiny number of packets seen. It does not significantly increase over time, just a few packets here and there. Even if the classification matches were incorrect, I should see hundreds of thousands of packets in the class-default.

I also dropped the 9mbs to 900k on the traffic shape and nothing happened.

Note I cannot apply the policy-map (or any that I've found that relate to queuing) to the VLAN interfaces, nor can I apply it directly to the tunnel (it complains about VLAN 200), and on this device it doesn't appear you can put an IP on the interface, you have to use VLAN's (unless I just can't figure out the right commands, the manuals only show vlans). While I might hope the SHOW command is incorrect, it is consistent with a lack of any difference in handling for traffic that is tagged "ef" vs other.

I feel like I'm missing something basic to get this connected. I'd appreciate any pointers.

Answer 1

You are applying the parent (shaping) policy map to interface gig0/1/7. I haven't touched the ISR 1k series yet, but from its name, that seems to be a port of an integrated switch module.

On the ISRs I have come across (G1, G2, 4k), switched ports never really supported QoS, especially not if it came to any form of queueing.

Suggestion: Apply the service policy ouptut to either interface vlan 200 or to interface tunnel1.

---

EDIT after comment: Neither interface tunnel nor interface vlan seem to accept the output service policy as it is. This is probably related to restricted hardware/queuing capabilities of the underyling (physical) switch port interfaces which do not allow to allocate buffer memory in a suitable way to implement the desired queuing behaviour.

The routed ports ("WAN Ports") of the given router (very much like on its product predecessor like the 890 series) can be expected to be of different hardware nature (not based on switch silicon) and have different buffering/queuing capabilities. They should accept an output service policy like this one.

---

Other than that: the fact that traffic is being marked by input policies is no guarantee that the class-maps used on the egress side are matching on the desired criteria.