ACL-based QoS on Egress/ouput

[mickpro77]

Hi,

I'm a network engineer whom although works for an ISP has no experience with QoS.

There is an end user, "behind" a partner ISP, with a couple hundreds sites, that are querying (inbound: end user => partner ISP => us/me => Internet) and fetching (outbound: Internet => us/me => partner ISP => end user) a lot of data from the Internet all at once every other day, maxing out the outbound capacity of the interconnections we have with their ISP every time, which is impacting the other users sites routed through the same interconnection with that partner ISP.

Topology:

End user <> partner ISP <> us/me <> Internet

What I'm trying to achieve is limit the outbound bandwidth/traffic this specific end user is causing via a QoS traffic policy applied on the interface facing our partner ISP in egress/outbound/output direction.

I've done PCAPs on that interface and have managed to find the source IPs, the destination IPs and the protocol used (I'm gonna use dummy IPs as/for examples here).

Source IPs (end users' sites) are, although not consecutive, all within 192.168.0.0/24.

Destination IPs (on the Internet) are all within 192.167.255.0/24.

Protocol is HTTPS (port 443).

So, to sum up, it's (for example, and excluding NAT/PAT happening in between, which is irrelevant):

inbound (query): 192.168.0.1:49152(dynamically picked port) => 192.167.255.1:443

outbound (response): 192.167.255.1:443 => 192.168.0.1:49152(dynamically picked port

Here is what I was planning on implementing:

ip access-list extended ACL-Traffic_policy
permit tcp 192.167.255.0 0.0.0.255 eq 443 192.168.0.0 0.0.0.255
 
class-map match-any CM-Traffic_policy
match access-group ACL-Traffic_policy
 
policy-map PM-Traffic_policy
class CM-Traffic_policy
bandwidth percent 10
police cir 100000000 conform-action transmit exceed-action drop
 
interface Gi0/0/4
service-policy output PM-Traffic_policy

But then I found out from the source below (which is for the same router model being the endpoint of the interconnection with our partner ISP, although we are using IOS XE v16, not v17) that "QoS ACLs are supported only for ingress traffic"

https://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/qos/17-1-1/b-qos-guidelines-xe-17-1-asr920/m_qos.html#ID-1374-0000007d

And so I'm not too sure how to do it then, can anybody help?

The source above also says: 

"In case of a PE router,

• For an egress policy-map to work at the access interface, it is mandatory to configure an ingress policy-map at the core interface of the same router."

Is that relevant to what I'm trying to achieve? and if so can anyone develop on how? as the document doesn't do so unless I'm mistaken.

KR

[Ramblin Tech]

You might use the ACL on an ingress policy for the Internet-facing interface to match and then set qos-group and/or discard-class. In your egress policy toward the partner ISP your class-map would match on qos-group to place the outbound traffic in a rate-limited queue and/or match on discard-class to subject the traffic to more aggressive WRED discards.

[mickpro77]

Thanks for your answer RT.

So I understand that I need to match the traffic I wanna limit on the inbound, mark it as a qos-group and then limit that qos-group allowed bandwidth via policy or shaping on the outbound.

[MHM Cisco World]

https://aitaseller.wordpress.com/2012/09/19/basic-qos-part-1-traffic-policing-and-shaping-on-cisco-ios-router/

Check this link

And if you want to try QoS you need GNS3 or eve-ng not PKT

MHM

[mickpro77]

Thanks for your answer MHM.

Great to have as it helps me understand QoS better, however it doesn't seem to be addressing output traffic policy/shaping based on ACL, which is what I'm trying to achieve, does it? (I haven't read it all yet so I might have missed it, in which case I apologize).

[mickpro77]

I've drafted the following config:

INBOUND TRAFFIC MARKING (as qos-group 1)

ip access-list extended ACL-QoS_inbound_traffic_marking
permit tcp 192.168.0.0 0.0.0.255 192.167.255.0 0.0.0.255 eq 443

class-map match-any CM-QoS_inbound_traffic_marking
match access-group ACL-QoS_inbound_traffic_marking

policy-map PM-QoS_inbound_traffic_marking
class CM-QoS_inbound_traffic_marking
set qos-group 1

interface Gi0/0/4 (interface facing partner ISP)
service-policy input PM-QoS_inbound_traffic_marking

OUTBOUND TRAFFIC POLICY (matching qos-group 1)

class-map match-any CM-QoS_outbound_traffic_policy
match qos-group 1

policy-map PM-QoS_outbound_traffic_policy
class CM-QoS_outbound_traffic_policy
bandwidth percent 10
police cir 100000000 conform-action transmit exceed-action drop

interface BDI20 (interface facing Internet, within the same router as Gi0/0/4)
service-policy output PM-QoS_outbound_traffic_policy

How does that look?

[Ramblin Tech]

I believe that is the right idea. I also see that I had the interfaces backwards in my response!

Your OP link with the implementation restrictions was to ASR 920 docs, so I am assuming that is your platform. All the ASR920  RSP models have quirks when it comes to QoS support, as do virtually all NPU QoS implementations. The trick is to identify them early in your network engineering design process (I worked with a very big SP that used RSP1 & RSP2 and several times we ran up against TCAM resource issues impacting QoS and PBR support).