0

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.

  • Where are you using the XXXXX_QoS_Queues_Out? You need to apply it somewhere, either in a policy map or a service policy. You probably want to have a service policy on the tunnel using it. You also probably would want to set the bandwidth statement on the tunnel interface to something less than the physical interface shape to account for the tunnel overhead. – Ron Maupin Oct 1 at 20:22
  • @RonMaupin XXXXX_QoS_Queues_Out is a child service policy under its parent TRAFFIC_SHAPER. – Marc 'netztier' Luethi Oct 1 at 20:32
  • @RonMaupin as mentioned it is there as a child policy. And the router rejects this policy (or any I have tried) on the tunnel itself, saying it cannot apply to the VLAN 200 underneath. – Linwood Oct 1 at 20:39
  • @Marc'netztier'Luethi, yes, but it doesn't work there because the traffic has a tunnel IP header, not the marked IP headers from inside the tunnel. – Ron Maupin Oct 1 at 20:40
  • Please add the config bits for the class-maps used for egress queuing, too. The fact that traffic is correctly marked "elsewhere" with input policy maps is no guarantee that it gets properly matched/queued on the egress side. – Marc 'netztier' Luethi Oct 1 at 20:40
2

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.

  • The router will not take the service policy on either tunnel (Service policy installation failed on Tunnel1. traffic shape not applicable in this direction. policy:TRAFFIC_SHAPER, dir:OUT, ptype:, ctype:DEFAULT) nor vlan (error Service-policy TRAFFIC_SHAPER not supported on Vlan200 ). I've tried both the policy shown, and just a separate polcy map without shaping and just a priority, neither will take. – Linwood Oct 1 at 20:55
  • The ISR here is supposed to be an Integrated Services Router, though running ios-xe everything looks a bit switch-y. We bought these instead of something like 3650's because we needed eigrp over tunnel interfaces. – Linwood Oct 1 at 20:59
  • Will the service-policy work on the (routed) Gigabit WAN interfaces? (at least can it be configured? Even if that's not its intended place) – Marc 'netztier' Luethi Oct 1 at 21:00
  • That's an interesting question -- I honestly had not noticed that the Gi0/0/0-1 ports behaved differently than the Gi0/1/0-7 ports. Let me try doing it without a VLAN. – Linwood Oct 1 at 21:04
  • From the ISR 4k I remember difficulty to apply egress policies to (mpls-over-gre-over-ipsec) tunnel interfaces if the underlying interfaces was meant to be a L3 port-channel - it would just not work (had to resort to an ECMP config instead of port-channel). I would assume that something similar applies here: If the tunnel's underlying interface or the interface itself don't lend themselves to queuing, you can't attach the service-policy to any of the "upper" interfaces. – Marc 'netztier' Luethi Oct 1 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.