QOS - inbound outbound term usage and complexity

[Clutz5250]

I just want to confirm my knowledge here I guess. In a general perspective, it would seem to me you’d use the inbound statement on a router to only classify/mark because the interface it’s connected to is at line rate coming in; there’s no way to drop traffic coming in.

outbound to my knowledge is where you can actually control bandwidth (shaping, policing).

Where it gets fuzzy is the thinking of things like SVIs +QoS, like if the traffic direction is being internally switched somehow - which blows my mind when defining inbound/outbound.

I presume with enough complexity (vrfs and vlans) this walks into an MPLS use case, because I don’t know how you could sort vlan based qos without going insane. Curious how SDN can do this without it causing some manner of latency.

[Joseph W. Doherty]

". . . it would seem to me you’d use the inbound statement on a router to only classify/mark because the interface it’s connected to is at line rate coming in; there’s no way to drop traffic coming in."

You can also police ingress traffic rate.

Such policing will limit rate that ingress interface forwards into device and may also impact traffic source sender's(s') transmission rate.

As far as SVIs are concerned, possibly just another L3 interface for QoS.  Although with switches, some QoS is limited to physical ports.

[Clutz5250]

---

@Joseph W. Doherty wrote:

You can also police ingress traffic rate.

Such policing will limit rate that ingress interface forwards into device and may also impact traffic source sender's(s') transmission rate.

---

What is the use case for that though? Seems like a very bad idea.

[Joseph W. Doherty]

Why you think a bad idea?

But a couple of reasons to do upon ingress.

First, same as an ingress ACL, if you're going to drop, drop as soon as possible so that traffic no longer needs to be processed.

Second, perhaps one ingress interface and lots of egress interfaces.  I.e. one interface configurations vs. many and/or ingress sees the aggregate sum on the single ingress interface, but what limits should place on multiple egress interfaces to restrict the source's aggregate transmission rate.

We also might be policing to change ToS markings (as you mentioned in your OP), not drop, but where to apply the policing still hold true, i.e. ingress interface might be better.

[Clutz5250]

Well, assuming we are talking about a basic scenario like this:

router1 -> router2 -> router3
               ^Ingress policy
that traffic is already going at line rate and arrived at router2. if you drop it coming in, then why? it's already been transmitted. Why would you police that there  instead of an egress policy that could actually queue, like on the interface egressing toward router 3? Seems like if you want to drop traffic at the ingress, you may as well use an ACL. Seems way to broad using QoS in this way.

I don't mean to sound like i know what I'm talking about here. My application of QoS is probably cookie cutter. I think i have a pretty decent grasp, but there are perhaps holes like this, where I'm just confused.

[Joseph W. Doherty]

And if you have no administrative control on R1?  I.e. why further process it on R2 if you would drop it upon R2 egress to R3?

BTW, yes you might use an ACL, but if you already have an ingress policy, why add an ACL too.  Also, on a router an ingress policy might take advantage of NBAR.