cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Popup Hotspot Using ISR 1000 with WiFi/LTE for Teleworkers and Micro Branchesr
2167
Views
15
Helpful
1
Replies
Highlighted
Beginner

QoS traffic marking - NBAR vs ACL

We have a few hundred routers in our environment, all of which are exclusively 2800 ISRs, 3800 ISRs, and 7200-G2s.

What are the guidelines or best-practices when it comes to using ACLs?  At what point do ACLs become excessively long and start to hamper the performance of the router and how would we measure/determine that?

We have previously used the QoS auto-discovery feature in our routers to monitor our normal traffic flows and then produce a recommended policy-map to apply to our interfaces to classify and queue our Enterprise traffic.  The resulting policy-map relies heavily on nbar.  Over time, we have then added and modified the recommended class-maps and added even more nbar match statements.

For a number of reasons, it is our strong preference to use ACL's to match traffic instead of nbar.  Especially when matching traffic types where nbar is only looking at port numbers and not performing inspection.  We would rather have one match statement in a class-map that refers to an extended ACL that then matches several different traffic types (based on port number).

The problem is this.  If we have a class-map right now with 15 match statements using nbar ("match protocol dns", "match protocol telnet", etc), then the resulting ACL that would match the exact same traffic (in both directions) comes out to approximately 40 lines.  If we remove nbar match statements from ALL of our class-maps and create their equivalent ACL's to match the same traffic (in both directions), then we end up with something closer to 200 lines of ACLs (when all of the individual ACL's are added together).

So in that case, if we have traffic that does NOT match any of our ACLs and eventually falls to the bottom of the policy-map, then that traffic will have been evaluated against 200 lines of ACLs by the time it hits the end of the policy-map.

Is that significant?  Is that insignificant?  How would we determine that?  In terms of router performance and impact, is it better to use 40 nbar match statements or 200 lines of ACLs?

Any thoughts or guidance would be appreciated.

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: QoS traffic marking - NBAR vs ACL

NBAR will increase CPU processing a bit, around 10% (give and take depending on the implementation). However, since traffic that doesn't match these NBAR lines will not have to match as many ACL lines, it may be forwarded faster.

You might also want to consider marking some traffic closer to the source, allowing the 3845 to evaluate based on DSCP markings

and not having to classify based on many ACEs. This would of course depend on your current Network Design and topology.

View solution in original post

1 REPLY 1
Highlighted
Cisco Employee

Re: QoS traffic marking - NBAR vs ACL

NBAR will increase CPU processing a bit, around 10% (give and take depending on the implementation). However, since traffic that doesn't match these NBAR lines will not have to match as many ACL lines, it may be forwarded faster.

You might also want to consider marking some traffic closer to the source, allowing the 3845 to evaluate based on DSCP markings

and not having to classify based on many ACEs. This would of course depend on your current Network Design and topology.

View solution in original post