At present the limiter traffic policy/QoS functions using the tc-police mechanism, using tc filters attached to an ingress qdisc. The limiter is configured to drop any packets exceeding the configured bandwidth with no opportunity for further processing. The tc-police framework however does support the conform-exceed keyword which allows customization of what happens to packets that either exceed or do not exceed the configured limit, allowing tweaking of how the limiter behaves. We can expose the verdict actions passed to confirm-exceed by adding additional configuration nodes with defaults that default to the existing behaviour of dropping packets that exceed the rate.
There are several potential usecases for this, one being the ability to redirect or mirror the exceeded traffic to an IFB interface for analysis by the use of the reclassify action along with some custom tc filters placed after the generated filters. We could also combine the use of an ingress shaper with the limiter by dropping the exceeding packet as normal but reclassify the non-exceeding traffic such that they're redirected to an IFB with a shaper on it (again, either via a custom tc fitler or via the interface redirect configuration directive). We could also flip the limiter where only packets exceeding a certain bandwidth may pass which, again, might be useful with other custom tc filter rules.
Relevant PR: