Sign In with your
Trend Micro Account
Need Help?
Need More Help?

Create a technical support case if you need further support.

N-Platform Tuning Tips

    • Updated:
    • 31 Jul 2017
    • Product/Version:
    • TippingPoint IPS N-series
    • Platform:
Summary

Tuning the N-Platform is not a one step process; instead it is a process that requires multiple steps, which can include;

  1. Disabling of filters that are sending lots of traffic into deep inspection, but are not producing any hits.
  2. Reducing or eliminating the use of Permit and or Permit + Notify action sets on filters.

Note: Permit + Notify should be used sparingly and with caution. Permit + Notify could have the effect of causing deep inspection on an abnormally large amount of traffic, leading to system performance degradation, Adaptive Filter Configuration and Layer 2 Fallback (L2FB).

  1. Enabling Flow Control filters with a Trust action set.
  2. Enabling Best Effort Mode.
  3. The use of Inspection Bypass rules (not supported on 660N or 1400N) for trusted traffic flows. Inspection bypass will completely bypass the inspection engine for those flows.
 

Note: The N-Platform IPS devices support up to a maximum of 8 inspection bypass rules per device.

While the IPS architecture is implemented to meet both security and performance requirements, certain traffic mixes may result in a degraded performance. There are several diagnostic CLI commands and filter procedures that will help better manage your IPS device. This document discusses the following areas;

  • show np rule-stats
  • show np tier-stats
  • Best Effort Mode
  • Big Flow
Details
Public

show np rule-stats

The "show np rule-stats" CLI command displays the top 20 triggered filters and allows the user to view the effect a particular filter has on the IPS. The command is useful for troubleshooting performance issues.

 

SAMPLE OUTPUT===============

 # show np rule-stats 

  Filter      Flows  Success  % Total  % Success  Zoneless %Zoneless
    5876     706346        0       39       0.00         0         0
   10762      36353        0       22       0.00         0         0
    8096      36353        0        9       0.00         0         0
    8078      20978        0        1       0.00         0         0
    2397      15430        0        8       0.00         0         0
    9421       7870        0        4       0.00         0         0
    8610       2755        0        1       0.00         0         0
    2402      30275    10745        1      35.49         0         0
    8350       2505        0        1       0.00         0         0
    4044       2234        0        1       0.00         0         0
    4152       2234        0        1       0.00         0         0
    4046       2234        0        1       0.00         0         0
    6515       1499        0        0       0.00         0         0
    6545       1499        0        0       0.00         0         0
    4616       1499        0        0       0.00         0         0
    5456       1499        0        0       0.00         0         0
    5457       1499        0        0       0.00         0         0
    9292       1159        0        0       0.00         0         0
   10562       1159        0        0       0.00         0         0
    5571        604        0        0       0.00         0         0
    Total of 875984 flows

 
ColumnDescription
FilterFilter number
FlowsNumber of flows that have come to the Smart-Path
SuccessNumber of times this filter has matched. In this example we received 706,346 flows and none matched filter 5876.
% TotalA ratio of Total traffic that was brought to the Smart-Path by this filter to the total traffic on the IPS.
% SuccessNumber of Successes divided by the number of Flows
ZonelessNumber of zoneless hits
% ZonelessA ratio of zoneless flows to the total number of Flows
 

Pay close attention to filters that have a high “% Total” but not “% Success”. These filters are possible candidates to be disabled if optimization is required.

Any filter that has success rate greater than 0% is matching against a filter. A success rate of 100% means each time a filter is triggered a threat is found. These filters should not be disabled in this case. If you have an excessive amount of notifications changing this filter to Block only will alleviate this issue.

  •  In the above example, filters 5876 and 10762 might be candidates to disable in order to gain some performance. Filter 2402 should not be under consideration due to its high success rate. Note: Care should be taken when disabling filters. Read the filter description to make sure that your systems are patched for that particular vulnerability. If your systems have been patched, it may be safe to disable that filter.
  •  In TOS v2.5.x and above you have the ability to reset the rule statistics. This is especially beneficial for IPS units that have been up for an extended time. The command only shows the top 20 based on number of flows. To reset this counter and generate a current Top 20 issue the following command via the CLI "clear np rule-stats" If a filter has any successes over time, it would be prudent to leave it on. If the filter has not logged successes but is responsible for a large percentage of the traffic inspection, some performance might be regained by turning that particular filter off.
  •  What is a Zoneless filter hit? A zoneless filter hit is a condition that occurs when an IPS device registers a filter hit on a segment even though the filter that is causing the hit is not enabled in that particular segment.

This condition occurs because on the IPS devices, the triggering mechanism is enabled in a global context. When you enable a filter (irrespective of segment), the trigger is installed into Tier 1 (which is where trigger matching occurs). This trigger will then match against traffic from all segments. If the filter is only enabled on segment 1 but it matches traffic against segment 2, then the filter hit will be reported as zoneless hit.

Note: This was removed from the N-Platform devices in a number of TOSs as the triggering mechanism was not applied in a global context but on a per segment basis. As of TOS 3.6.1 the zoneless hits were returned to the N-Platform devices.


show np tier-stats

 

The "show np tier-stats" CLI command, displays bandwidth usage and resource utilization as traffic is passing through the IPS. The maximum value for each line is displayed to the right in parenthesis. The value in parenthesis indicates the maximum number since the last time the IPS was rebooted or the "clear np rule-stats" command was utilized.

Tier 1: Inspection bypass and L2FB is handled here, preventing traffic from going to the next tier. It also handles the rate limiter, jumbo packet shunting, and hardware watchdog timer.

  • Rx Mbps = Rate in Mbits/second received by the device across all ports.
  • Tx Mbps = Rate in Mbits/second transmitted by the device across all ports.
  • Rx packets/sec = Rate in packets/second received by the device across all ports.
  • Tx packets/sec = Rate in packets/second transmitted by the device across all ports.
  • Bypass Mbps = Mbps matching inspection bypass rule, not counted against IPS total limit
  • A/B Balance = shows how Zuma is balancing between XLRs (50/50 is ideal).
  • Utilization = % as rated against system throughput
  • Ratio to next tier = only inspection bypass can bring this below 100%.

 

SAMPLE OUTPUT ===============

# show np tier-stats
----------------------------------------------------------
Tier 1:
----------------------------------------------------------
 Rx Mbps               =          0.0  (0.0)
 Tx Mbps               =          0.0  (0.0)
 Rx packets/sec        =          0.0  (16.0)
 Tx packets/sec        =          0.0  (16.0)
 Bypass Mbps           =          0.0  (0.0)
 VLANTrans packets/sec =          0.0  (0.0)
 VLANTrans to Rx /sec  =          0.0%
 A/B Balance           =        100.0% (A: 9.0  B: 7.0)
 Utilization           =          0.0% (  0.0%)
 Ratio to next tier    =        100.0% [100.0%]
----------------------------------------------------------


Tier 2: Load balances flows through the KS threads and handles traffic management trusts. Block filters will prevent traffic from proceeding to the next tier.

  • Utilization = % usage of total capacity for Tier 2
  • Ratio to next tier = 100% - traffic normalization filters, traffic management trust/block, trust streams.

Tier 2:
----------------------------------------------------------
 Tx trust packets/sec  =          0.0  (0.0)
 Utilization           =          0.0% (  0.0%)
 Ratio to next tier    =        100.0% [100.0%]
----------------------------------------------------------



Tier 3: This tier is designed to search for suspicious traffic that needs to undergo deep inspection. This section handles IPv6 + GRE and Mobile IPv4 tunnels. IP reassembly, maintaining connection table, and TCP state tracking is handled here. If triggers are found it determines what filters need to be checked against the packet or flow then it turns on soft-reroute for the flow, and if necessary sends it for deep packet inspection.

  • Rx Mbps = Bandwidth (Mbps) of how much traffic will be inspected by filter inspection and IP reassembly
  • Rx packets/sec = Bandwidth (packets/sec) of how much traffic will be inspected by filter inspection and IP reassembly
  • Utilization = % usage of total capacity for Tier 3
  • Ratio to next tier = % of traffic for TCP reassembly or matched trigger.

Tier 3:
----------------------------------------------------------
 Rx Mbps               =          0.0  (0.0)
 Rx packets/sec        =          0.0  (16.0)
 Tx trust packets/sec  =          0.0  (0.0)
 Utilization           =          0.0% (  0.0%)
 Ratio to next tier    =          0.0% (  0.0%)
----------------------------------------------------------


Tier 4: This section shows why traffic is going deep. Similar to Tier 3 on the E-series IPS, it performs TCP Reassembly and Threat Verification (Header based checks, protocol decoders, content search, and regular expression matching). Also action handling occurs here whether the packet is dropped, rate limited, or rate limited in the connection table.

  •  Rx Mbps = Bandwidth (Mbps) that reached tier 4.
  •  Rx packets/sec = Bandwidth (packets/sec) that reached tier 4
  •  Rx due to:
  •  Trigger match = at Tier 4 due to trigger.
  •  Reroute = packets from stream after trigger matched.
  •  TCP sequence = at Tier 4 due to need to reorder TCP.
  •  Ratio to next tier = % of traffic that matched a filter irrespective of Action Set.

Tuning is required if congestion is occurring or if an IPS is being operated close to its maximum rated throughput. The deeper a flow is inspected the more processing is required to inspect the flow, so the most performance gains can be attained by optimizing the KS threads at this level (Tiers 3 & 4). The three most process intensive operations are;

  • IP Reassembly
  • Threat verification
  • TCP Packet reordering


Tier 4:
----------------------------------------------------------
 Rx Mbps               =          0.0  (0.0)
 Rx packets/sec        =          0.0  (0.0)
 Rx due to:
   Trigger match       =          0.0% (  0.0%)
   Reroute             =          0.0% (  0.0%)
   TCP sequence        =          0.0% (  0.0%)
 Ratio to next tier    =          0.0% (  0.0%)

----------------------------------------------------------
 


Best Effort Mode

What is "Best Effort" mode? "Best Effort" mode is a feature available in the TippingPoint 660N, 1400N, 2500N, 5100N and 6100N IPS devices which protects latency sensitive applications (voice, video) by shunting permitted traffic packets around the inspection engine.

When "Best Effort" mode is enabled, the default latency threshold is set at 1000 microseconds, and the default recovery percentage at 20%. The device will enter "Best Effort" mode when latency reaches 1000 microseconds, and will exit the "Best Effort" mode when latency drops to 200 microseconds (20% of 1000). When the latency reaches the default or user-defined threshold, permitted traffic is shunted around the inspection engine until latency falls to the defined recovery percentage. As an example at default settings (1000µs/20%), a single TCP stream ramps from 318 Mbps to 552 Mbps by shunting 50% of packets.

The N-Platform is architected as a collection of parallel network processor threads. Each of these threads implements the security protection that is configured by the user. When processing traffic, the network flows are load balanced among all of the available threads in the system. In infrequent cases, the traffic directed to a single processor thread can exceed the level that thread can manage, causing the appliance to drop the overflow traffic. If Best Effort mode is enabled, then the appliance simply forwards the overflow packets, instead of dropping them. The forwarded traffic is only related to the specific processing thread, all other threads would be unaffected. This feature was designed to protect latency sensitive applications.

Example: If you are running a video application thru the IPS device and the video is choppy, you could turn on "Best Effort" in order to address the problem.

How to manage "Best Effort": To manage "Best Effort" you have to access the IPS via the CLI and execute the "debug np best-effort" command with appropriate subcommand.

 
debug np best-effort parameters
SubcommandDescriptionUsage
enableEnables "Best Effort" mode.debug np best-effort enable
disableDisables "Best Effort" mode.debug np best-effort disable
-queue-latencyDefines the latency threshold at which "Best Effort" mode is entered. The default is 1000 microseconds.debug np best-effort enable -queue-latency <microseconds>
-recover-percentDefines the recovery percentage at which "Best Effort" mode is exited. The default is 20%.debug np best-effort enable -recover-percent <percent>
 

"Best Effort" and "show np tier-stats": When "Best Effort" mode is enabled on the IPS and you execute the "show np tier-stats" CLI command a new parameter "Ratio to best effort" is displayed;

 
----------------------------------------------------------
Tier 3:
----------------------------------------------------------
  Rx Mbps               =        443.1  (1,386.3)
  Rx packets/sec        =     44,758.0  (163,216.0)
  TX trust packets/sec  =         0.0   (0.0)
  Utilization           =          8.3% (26.0%)
  Ratio to best effort  =         0.1%  (58.9%)
  Ratio to next tier    =         41.8% (93.0%)
----------------------------------------------------------
Tier 4:
----------------------------------------------------------
  Rx Mbps               =        168.3  (395.1)
  Rx packets/sec        =     18,746.0  (36,617.0)
  Rx due to:
    Trigger match       =          0.4% (41.4%)
    Reroute             =         88.4% (100.0%)
    TCP sequence        =         11.1% (51.0%)
  TX trust packets/sec  =         0.0   (0.0)
  Ratio to best effort  =        15.8%  (96.2%)
  Ratio to next tier    =          0.0% (1.8%) 
 

What is "Ratio to Best Effort"? Ratio to best effort is the amount of traffic being trusted at that tier. If tier 3 receives 100Mbps, and you have a ratio to best effort of 10%, then 10Mbps of traffic would be trusted, the remaining 90% will either be clean (not hit a trigger), or pass to tier 4 for reassembly or threat verification.


Big Flow

With the N-Platform IPS device, eight new filters (7620, 7621, 7622, and 7623-TCP and 7624, 7625, 7626 and 7627 -UPD) are available to detect flows based on the size of the flow (Mb). These filters can be used in conjunction with a newly available action set of  "Trust". Applying the Trust Action set to these filters will let any TCP/UDP flow that exceeds the filter's size to be trusted.

When the filter condition is matched, the flow (based on source/destination IP, source/destination port, and protocol) will be placed in a trusted flows table to be allowed to pass uninspected for 30 minutes. After 30 minutes has elapsed, the flow will be removed from the table and go back to normal inspection. Assuming the flow is still passing, once it reaches the filter's configured size again it will return to the trusted flows table.

The assumption with the TCP/UDP flow management filters is that malicious traffic will reside in the first portion of any communication. Once traffic has exceeded a given amount of data being transferred, the likelihood of an attack occurring is almost non-existent. The use of these filters will assist in the overall performance of the IPS.

You can enable one filter from each of the TCP and/or the UDP groups with a trust action to facilitate large flows:

 
TCP FiltersUDP Filters
7620 (5MB)
7621 (10MB)
7622 (100MB)
7623 (500MB)
7624 (5MB)
7625 (10MB)
7626 (100MB)
7627 (500MB)
Premium
Internal
Rating:
Category:
Configure; Troubleshoot; Deploy
Solution Id:
TP000085622
Feedback
Did this article help you?

Thank you for your feedback!

To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
We will not send you spam or share your email address.

*This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.

If you need additional help, you may try to contact the support team. Contact Support


To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
We will not send you spam or share your email address.

*This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.