Cisco ASR 1001 Queuing on PPPoE Interfaces

The ASR 1001 has a few interesting limitations, mostly around some features being missing from the IOS XE codebase. The latest one I've hit is the inability to apply a shaping policy to a PPPoE virtual-access interface.

My setup looks like this: two GigE interfaces in a port-channel with a number of VLANs configured as sub-interfaces to the port-channel and PPPoE sessions terminated on those VLANs. Simple enough.

If I apply a simple policer to the virtual-template or configure it via RADIUS for a router dialling in with a PPPoE client the policy is applied, no questions asked. But a simple policer isn't really much good to me because I'm going to want a child-policy in order to define an LLQ for, say, VoIP traffic.

So, I need to apply a shaper parent policy effectively defining the bandwidth of the interface and a child policy containing my LLQ for my VoIP class and my other traffic classes specific bandwidth requirement.

All straightforward enough stuff, bread and butter for SPs and enterprises. Until you bring up your PPPoE client, do a show policy-map interface on the virtual-access subinterface and... nothing. A quick look at the log shows an error like this:

Sep  7 14:30:02 BST: %QOS-6-POLICY_INST_FAILED:
 Service policy installation failed

After digging around a bit and trying a few things I was confident enough that I'd hit at best some sort of bug, at worst a "feature limitation" so I got in touch with Cisco TAC. After a bit of troubleshooting the TAC engineer homed in on my port-channel configuration and suggested that I upgrade to IOX XE 3.7 as there is limited support for queuing on port-channel interfaces. Fine, I went ahead with that and tried again. Show policy-map interface and... nothing.

Another look at the logs showed the familiar policy installation error from before but this was now accompanied with this additional error:

Sep 11 08:19:32.251: Port-channel1 has more than one active member link

Yes, this port-channel has more than one active member link because, you know, it's a port-channel!

At this point I could see where this was going and spoke to the TAC engineer again. Apparently this is what he meant by "limited support" for PPPoEoVLAN on port-channels. So, in order to prove that the rest of my configuration worked I went ahead and re-configured the port-channel for fast-switchover (active / standby - see here (cisco.com)). Now the policy applied without a problem.

This leaves me in a bit of a predicament though. On one hand I now have policy-maps applying successfully PPPoE virtual-access interfaces. On the other hand I now have an ASR 1001 that can do 2.5Gbps throughput by default (and is upgradeable by license to 5Gbps throughput) that I've had to "waste" an interface on to get uplink resilience. And, on a box with only four SFP ports that's expensive wastage. I could use the other two SFP ports and artificially load-balance traffic by targeting different PPPoE VLANs on each port-channel, but I honestly would much rather see Cisco fix queuing on load-balanced port-channels. Hopefully this will happen sometime soon, before this box starts getting pushed beyond 1Gbps!