QoS DSCP marking on router cpu/self generated traffic

[ktang1]

Hi,

I have a CGR2010 router running IOS 15.9. How do you mark the DSCP value to the router cpu/self generated traffic such as ntp, snmp and syslog? I tried adding

service-policy input xxx

to the loopback0 interface but it didn't mark any of those traffic.

Thanks

[Joseph W. Doherty]

I'm unfamiliar with a CGR2010 and device generated traffic, sometimes, cannot be dealt with the same as transit traffic.  That said, possibly your best chance is to try setting the ToS using an interface egress service policy.  (Unclear why your tried using an ingress service policy on a loopback interface - perhaps that's because such interface's IP appears in as the source IP in device's self generated traffic [when configured to be the source for certain service traffic types]?)

[ktang1]

Hi Joseph,

Yes, I used ingress service policy on loopback interface as it's the source IP for those self generated traffic. If I set ToS using interface egress service policy, will the packet be still queued (if i use QBWFQ) before sending out? My concern is that the non-marked router self-generated traffic will fall into the default class queue in QBWFQ.

[Joseph W. Doherty · Accepted solution]

"If I set ToS using interface egress service policy, will the packet be still queued (if i use QBWFQ) before sending out?"

Yes such traffic will be queued, assuming there's sufficient interface congestion to require queuing.

"My concern is that the non-marked router self-generated traffic will fall into the default class queue in QBWFQ."

Yes, if no other class matches the packet, but for you to tag packets, differently from class-default traffic, you should be matching such traffic in another class.

(If my response seems unclear, please let me know.)

[ktang1]

Hi Joseph,

Thanks for your explanation. I tried interface egress service policy with DSCP marking (set dscp) and bandwidth percent in the same policy map, and it works when there's interface congestion.

I thought QoS marking can only be done on the interface ingress. What's the pros/cons on marking traffic on interface ingress or egress? Most of the Cisco QoS documents show marking on interface ingress.

[Joseph W. Doherty]

". . . and it works when there's interface congestion."

BTW, setting the ToS should work regardless whether there's interface congestion or not.

"What's the pros/cons on marking traffic on interface ingress or egress?"

When done on ingress, it's possible you might have one or few ingress interfaces (for your policy) vs. lots for egress, so less to maintenance.

Also when done on ingress, you can remark on egress, using another set of criteria.

When done on egress, similar to ingress, you might have just one or few egress interfaces (needing a policy) vs. many ingress that would, i.e. possibly less maintenance.

Of course, sometimes you'll want/need to use both ingress and egress policies.

Personally, I often do marking during egress because as an egress policy is also used for congestion management, if we mark there, we might exclude the need for an ingress policy that's only used for marking.  (Again, less maintenance.)