@Ramblin Tech wrote:
H-QoS via policy aggregation?
Maybe!
If OP only wants just one specific set of combined subinterfaces, and the other subinterfaces independent, as they currently are (?), and the existing policies only shape the default class, it may be a very suitable approach.
If the need is more complex, likely this feature, even possibly the later XE 2.6 variant, might not be up to challenge.
BTW, what I suggested, is dependent on the main interface "seeing" all the subinterface traffic in a policy applied to it. This may not be the case, or it may work on some platform/IOS combos, and not others. (When you start really pushing complexity in MQC, I've often seen one platform/IOS accept a config that another platform/IOS does not.)
I don't have any hardware to test with. Do have a copy of CML, which might accurately provide a faithful result.
I'm also wondering whether "match vlan #" would work on the main interface.
from: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-16-12/qos-mqc-xe-16-12-book/qos-intro.html
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map parent-vlan100
class class-default
shape average 100m
service-policy child
!
policy-map parent-vlan200
class class-default
shape average 50m
service-policy child
!
int gigabitethernet1/0/0.100
service-policy out parent-vlan100
int gigabitethernet1/0/0.200
service-policy out parent-vlan200
This example shows that although the definition may be shared the instances of the policy on different interfaces are truly unique.
You can also create hierarchical policies with policy-maps used in user-defined classes.
The following example illustrates a 3-level hierarchical policy, the max currently supported on the ASR 1000 Series Router. For a packet to match a class at the application level it must now match 3 requirements: the voice or video classifier at the child, the vlan classifier in the vlan-sharing policy-map, and the class-default (anything) in the physical level policy-map:
class-map vlan100
match vlan 100
class-map vlan200
match vlan 200
!
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map vlan-sharing
class vlan100
shape average 100m
service-policy child
class vlan200
shape average 50m
service-policy child
!
policy-map physical-policy
class class-default
shape average 500m
service-policy vlan-sharing
!
interface gigabitethernet1/0/0
service-policy out physical-policy
In the above, the first portion, is probably somewhat similar to what OP is doing now.
The second portion, is what I had in mind, more or less. (I've often done similar QoS with multiple tunnels crossing a physical interface, just not with router subinterfaces.)
Assuming the second portion works, it might require being used exclusively, i.e. you might not be able to mix the two techniques on the same interface. (Not a big deal if you only have a few, like the OP's 3, but if you have hundreds, then you might have a major conversion effort.)
Again, I've often seen complex QoS configs impacted by their level of complexity. So, @Vlad8 can you provide an example of what your subinterface policies are (actually) now?
PS:
BTW, Jim, I wasn't aware of the feature you referenced. Reading it though, it seems inferior to the above because I usually find I need a multi-level hierarchal policy when shaping, not aggregation of multiple streams. Again, though, perhaps it would be suitable for OP.
The usual case I've had to deal with, having a hub with a 10x the bandwidth of spoke sites, but more than 10 spoke sites. So, from the hub, need to deal with its overall bandwidth limit, (to) spoke bandwidth limits, and prioritization of traffic when either the hub or (to) spoke bandwidth limits are exceeded.
