Думаю причина в очень большом объёме трафика который надо классифицировать по проколам прикладного уровня.[snapback]8189[/snapback]
покопался у цискарей, так и есть. в презенташке от 99г написано
Performance:- Approximately 15% increase in CPU usage with stateful classification at T3 rate with 256-byte packets and average flow lengths on 7200 platform
- Static classification similar to ACL performance
с тех пор NBAR есть не только на 7200, а прирост нагрузки похоже тот-же. посмотрел на твои графики, imho не смертельно. глянь вот на эти тесты
Network Based Application Recognition Performance Analysis, там нагрузка на процессор и покруче. и там же сказано
What Does NBAR Performance Depend On?Several factors can impact NBAR performance in software-based execution.
A. Router Configuration1. Number of protocols being matched against it
2. Number of regular expressions being used
3. The complexity of packet inspection logic required
B. Traffic Profile (Packet Protocol Sequence)1. The number of flows
2. Long duration flows are less expensive than shorter duration flows
3. Stateful protocol matches are more performance impacting than static port applications
A traffic mix consisting of a high volume of short-lived flows requires a higher level of resources to classify new flows which soon "expire" from the flow cache. Conversely, a lower level of resources is required with a traffic mix of fewer and longer-lived flows, since these flow entries would be in the cache for a longer amount of time.
Things That do not Impact NBAR1. Post match actions (such as queuing, tagging, etc.)
2. Link speed (NBAR is interface agnostic)
3. Having NBAR on multiple interfaces (packets already classified are cached, no reclassification will take place)
4. Inbound vs. outbound packet matches (using NBAR on service policy input instead of service policy output)
ну а дальше, если загрузка процессор будет уходить в потолок, остается только менять железо на более мощное и переходить на dNBAR.