Rule Hit Count Report
The Rule Hit Count Report provides the following:
Policy Compliance: Generate a Rule Hit Count Report to provide evidence that security controls are in place and working effectively, demonstrating compliance to auditors.
Redundancy Removal: Identify unused or less-used rules so you can remove or modify them to reduce redundancy and clutter in your implementation.
Troubleshooting: When network issues arise, identify the rules that were in effect during the relevant traffic flow, allowing you to resolve problems faster and more efficiently.
For more information, see the topics Work with Reports in the PCE in this guide and "Rulesets and Rules" in the REST API Developer Guide.
PCE Version:
SaaS: 24.2.0 or later
On-prem 23.5.10 or later
VEN Version: 23.2.30 or later
Support for up to 25k VENs.
Support for up to 75k total rules.
The VEN can report a maximum of 100 rule IDs for each reported flow entry. If there are more than 100 rule ID matches for a flow, the rule IDs are truncated.
No support for Superclusters.
Only active rules are counted.
Essential rules (rules necessary for the Illumio platform to function) are not counted.
The report includes each rule's hypertext reference attribute (HREF). The HREF maps directly to a rule in the PCE UI, but clicking the HREF does not redirect you to the specific rule. It merely loads the JSON object of the rule.
VENs report to the PCE the hit count of all the overlapping rules for a flow.
VEN enablement for this feature makes use of label scopes similar to firewall co-existence and SecureConnect.
Rule count data is retained for 90 days, after which the oldest data is dropped.
Last Hit timestamps are retained for the life of the PCE.
The report includes the active rule IDs within the rule sets you specified when you configured the report, plus all the deny rules.
Hit Count values reflect the total number of hits recorded during the configured time range.
Due to PCE policy optimization, some rules that weren't written to overlap may end up overlapping. For example:
Given two flows:
A → B on TCP/443
A → C on TCP/443
Although the flow from A → B on TCP/443 never overlaps with the flow from A → C, due to policy optimization, the rule counter for both rules may increment.
STEP 1: Enable Rule Hit Count
The PCE and VENs require enablement through the Illumio REST API. For details, see "Enable Rule Hit Count" in the REST API Developer Guide.
STEP 2: Create Rule Names in the PCE
To ensure that there are names in the Rule Name column, you need to add a Note through the PCE UI for each rule that will be captured in the report. The Rule Hit Count Report populates the Rule Name column by pulling the Note contents from the specified rules.
Go to Policy > Rulesets & Rules.
Click a ruleset to open its details page.
To provide a name that the Rule Hit Count Report can use, add a note to a rule.
Click the three vertical dots adjacent to the rule, and then click Add Note.
Enter a name for the rule. The name you enter appears in the Rule Name column when you generate the Rule Hit Count Report.
Click the Save icon in the upper right corner. A word bubble icon
appears next to the pencil icon.
STEP 3: Generate the Rule Hit Count Report
See Add a Report.
The following example scenarios help explain how rule hit counts are calculated and reported.
Scenario 1
Flow: Workload A → Workload B on TCP/443 (reported by both sides)
Enforcement Mode: n/a
Rules | Count | Comments |
|---|---|---|
Workload A → Workload B on TCP/443 | 2 | Both workloads reported the flow and this rule is executed by both of them. |
Workload A → Any IP List | 1 | Only workload A executes this rule. |
Some IP List Covering A → B | 1 | Only workload B executes this rule. |
Scenario 2
Flow: Workload A → Workload B on TCP/443 through a network enforcement point that blocks A → B (so only reported by A)
Enforcement Mode: n/a
Rules | Count | Comments |
|---|---|---|
Workload A → Workload B on TCP/443 | 1 | Because A has a VEN on it and it allowed the flow and B hasn't reported it. |
Workload A → Any IP List | 1 | Because A has a VEN on it and it allowed the flow. |
Some IP List Covering A → B | 0 | Because A has a VEN on it and it allowed the flow. |
Scenario 3
Flow: Workload A → Workload B on TCP/445
Case 1 Enforcement:
Workload A Enforcement Mode - Visibility and TCP/445 is not allowed outbound
Workload B Enforcement Mode - Full
Rules | Count |
|---|---|
Allow Any (0.0.0.0/0) → Workload B on all services | 1 |
Case 2 Enforcement:
Workload A Enforcement Mode - Full and TCP/445 is not allowed outbound
Workload B Enforcement Mode -Full
Rules | Count |
|---|---|
Allow Any (0.0.0.0/0) → Workload B on all services | 0 |
Case 3 Enforcement:
Workload A Enforcement Mode - Selective
Workload B Enforcement Mode -Full
Rules | Count |
|---|---|
TCP/445 is blocked outbound on A via boundary | 1 |
Allow Any → Workload B on all services | 0 |
Scenario 4
Flow: Workload (Endpoint) C → Workload (Server) B on TCP/443
Endpoint A - Label:Loc1 (IP address: 10.3.2.4/24 → subnet = 10.3.2.0/24 == 10.3.2.0 → 10.3.2.255)
Server B - Label:App1
Endpoint C - Label:Loc2 (IP address: 10.3.2.7/24 → subnet = 10.3.2.0/24 == 10.3.2.0 → 10.3.2.255)
Behavior:
Endpoint C will drop the flow if it's in Enforcement Mode (because there's no rule allowing outbound)
Server B will accept a flow from either Endpoint A or Endpoint C if the flow makes it to server B
Case 1 Enforcement:
Endpoint C Enforcement Mode - Full
Rules | Count | Comments |
|---|---|---|
Loc1 | Endpoints (Use WL subnets) → App1 | 0 | Endpoint C will drop the flow because there is no outbound rule. |
Case 2 Enforcement:
Endpoint C Enforcement Mode - Selective
Rules | Count | Comments |
|---|---|---|
Loc1 | Endpoints (Use WL subnets) → App1 | 1 | Endpoint C will allow the flow because there is no boundary. Server B will allow the flow because Endpoint C is in the same subnet as Endpoint A. The report indicates that the Loc1 rule was hit, but the flow is coming from a Loc2 Endpoint. |
Scenario 5 (PCE rule optimization)
Flow: Workload A → Workload B on TCP/443
If the address of workload B and workload C overlap, then PCE rule optimization could merge the following rules resulting in the second rule also being incremented.
Rules | Count | Comments | |
|---|---|---|---|
Workload A → Workload B on TCP/443 | 2 | Both workloads report the flow. | 2 |
Workload A → Workload C on TCP/443 | 2 | The reported flow could potentially contain this rule ID as well because of PCE rule optimization. |