cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
291
Views
20
Helpful
3
Replies
jnewton83985
Beginner

QoS Marking

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. 

1 ACCEPTED SOLUTION

Accepted Solutions
Joseph W. Doherty
Hall of Fame Expert

"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.)

View solution in original post

3 REPLIES 3
MHM Cisco World
Advisor

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.

paul driver
VIP Expert

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


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Joseph W. Doherty
Hall of Fame Expert

"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.)