03-10-2022 02:03 PM
Quick rundown on my LAN:
Access switches -> core -> internal routers -> firewalls -> DMZ -> router -> ISP
We don't have any cisco phones or phones that support CDP so I'm not trusting any switchports. My plan was to set my trust boundary where the access switches connect to the core and mark traffic on the access switches. I'm considering moving the trust boundary to my internal routers and marking traffic there although this doesn't seem common.
Best practice is to mark traffic as close to the source as possible but I was hoping to get some insight from others. With QoS being CPU intensive on routers, my internal routers average 15-20% CPU usage.
Solved! Go to Solution.
03-11-2022 10:42 AM
"Best practice is to mark traffic as close to the source as possible . . ."
That's so the classification, and possible remarking, load can be distributed as much as possible. It also allows usage of a ToS (or CoS) marking, ASAP too.
That noted, I've generally only worried about classification right before QoS treatment is to be used. (E.g. doing classification and treatment on a router's WAN egress interface.) Yes, it imposes, some additional load, but then so does QoS treatment. Usually, I haven't noticed a huge additional impact from either QoS classification and/or treatment.
(This approach also makes it simpler to maintain your QoS policies, as it's used in fewer places.)
03-10-2022 02:26 PM - edited 03-10-2022 02:26 PM
boundary must close to Client, so start from User/SW not form Router.
then SW add QoS to 802.1 tag and then send to router, router make classify and remark.
03-11-2022 03:31 AM
Hello
Apply the QOS boundary at the access layer/ access-ports.
Access switches -> core -> internal routers -> firewalls -> DMZ -> router -> ISP
However if you want to relocate this boundary you could not enable MLS qos on any access-layer or core switches then all classified/marked traffic from those layers will be honored and NOT be reclassified as such you could then append qos policy's on the ingress from core/ internal rtrs
Access switches -> core -> internal routers -> firewalls -> DMZ -> router -> ISP
03-11-2022 10:42 AM
"Best practice is to mark traffic as close to the source as possible . . ."
That's so the classification, and possible remarking, load can be distributed as much as possible. It also allows usage of a ToS (or CoS) marking, ASAP too.
That noted, I've generally only worried about classification right before QoS treatment is to be used. (E.g. doing classification and treatment on a router's WAN egress interface.) Yes, it imposes, some additional load, but then so does QoS treatment. Usually, I haven't noticed a huge additional impact from either QoS classification and/or treatment.
(This approach also makes it simpler to maintain your QoS policies, as it's used in fewer places.)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide