2.8 Hit Count and Policy Install Workflow

The Hit Count Feature

Hit Count is a SmartConsole feature that records how many times each Access Control rule matches over a configurable time window. The count appears as a column in the rulebase and is updated periodically from the gateway's hit data. Hit Count turns the rulebase from a static document into an observable one: administrators can see which rules are actually firing and which are dormant.

Hit Count serves three main purposes:

1. Identify unused rules. A rule with zero hits over a long window (say, 90 days) is a candidate for removal. Unused rules add clutter, increase the chance of accidental matches, and create audit noise.
2. Optimize rule order. Rules with very high hit counts that sit low in the rulebase force the gateway to evaluate many other rules first before reaching them. Moving high-hit rules up (within the constraints of first-match logic) reduces the average number of rule evaluations per connection.
3. Audit rule effectiveness. A rule that is supposed to allow business traffic but has zero hits may indicate that the source, destination, or service fields do not match the real traffic pattern — a misconfiguration that the administrator did not notice because no one complained.

Hit Count can be enabled per layer and configured with a time window. The data is stored on the management server and displayed in SmartConsole as a numeric counter next to each rule.

Configuring Hit Count

Hit Count is enabled in SmartConsole in the Access Control policy's properties or per-layer settings. The configuration options include:

• Time window — the period over which hits are counted (for example, last 24 hours, last 7 days, last 30 days, last 90 days). A longer window gives a more stable picture but slower feedback to changes.
• Resolution — how granular the counts are. Higher resolution uses more storage on the management server.
• Display — whether to show absolute counts, percentages, or trends.

Once enabled, the Hit Count column appears in the rulebase. Administrators can sort by hit count to surface the most- and least-used rules quickly.

Hit Count Caveats

• A zero hit count does not always mean a rule is unused. The rule may match traffic only during specific incidents (for example, a failover scenario) that did not occur during the window.
• Hit Count reflects matches, not the action's effect. A rule with high hits may be an Accept that allows legitimate traffic, or a Drop that blocks many scans — the count alone does not tell you which.
• Hit Count does not measure rule quality. A well-designed rule may have low hits because it is a narrow exception; a poorly designed broad rule may have very high hits. Use Hit Count as one signal among several.

The Policy Install Workflow

Installing a policy in R82 follows a defined workflow:

1. Edit the policy in SmartConsole — add, modify, or remove rules in the Access Control, NAT, and Threat Prevention layers.
2. Validate the policy. SmartConsole runs a policy validation that checks for compilation errors, unresolved object references, layer inconsistencies, and other issues. Validation does not push the policy; it confirms the policy is compilable.
3. Install the policy. The Install Policy dialog lets the administrator select the policy package, the target gateways, and any install options (such as whether to reset connections on specific rules). The management server compiles the policy for each gateway and pushes it over SIC.
4. Verify on the gateway. The gateway activates the policy in kernel memory and reports success or failure back to the management server. The administrator can verify the active policy with fw stat on the gateway CLI, which shows the policy name, the installation time, and the source management server.

Policy Validation in Detail

The validation step is more than a syntax check. SmartConsole validation catches:

• Unresolved objects — rules that reference deleted or renamed objects.
• Incompatible layers — for example, an Application layer placed before a Network layer, which is not supported.
• Duplicate rules — rules with identical match fields and actions (a warning, not an error).
• Shadowed rules — rules that can never match because a broader rule above them matches the same traffic.
• Missing installation targets — a layer with no gateways assigned.

Validation runs automatically when you click Install Policy. A failed validation prevents the install from proceeding, so the gateways keep the previously installed policy — a guardrail that protects production from a broken policy.

Install Policy Options

The Install Policy dialog provides several options:

• Install on all gateways in the package or install on selected gateways only — useful for staged rollouts.
• Preview — show which gateways will receive the policy and any compilation warnings without actually installing.
• Reset on Policy Install — for specific rules, terminate existing connections that match those rules when the new policy activates. Used when a rule change must affect existing flows, not just new ones.
• Threat Prevention generation — when installing a Threat Prevention policy, the gateway fetches the latest protections from the management server.

Verifying the Installed Policy

After installation, verify the policy on each gateway with these CLI commands:

• fw stat — shows the currently active policy, the policy name, the source management server, and the installation time. This is the first command to run after any policy install.
• fw unloadlocal — emergency only. Unloads the policy from the gateway, leaving it without enforcement. Used when a new policy breaks connectivity and you need to restore management access. The gateway is unprotected until a new policy is installed.
• fw installlocal — installs a previously compiled policy that is stored on the gateway. Used to reinstall the last compiled policy without contacting the management server.
• cpstat fw — shows firewall statistics including the active policy and inspection status.

fw unloadlocal is a critical emergency tool but should never be used routinely — it leaves the gateway open. The exam expects you to know that fw unloadlocal is the emergency rollback for a bad policy and that fw stat confirms the active policy.

Install Failures and Troubleshooting

Common install failure causes:

• SIC failure — the management server cannot authenticate to the gateway. Re-establish SIC trust.
• Compilation errors — unresolved objects or invalid layer configurations. Validation should catch these before install.
• Gateway resource exhaustion — the gateway cannot load the policy into memory. Check fw ctl zdebug and gateway resources.
• Network connectivity — the management server cannot reach the gateway. Check routing and intermediate firewalls.

The Install Policy dialog and the install log in SmartConsole show the specific failure reason for each gateway.

Best Practices

• Validate before installing, even for small changes. Validation is fast and catches mistakes.
• Use Preview to confirm target gateways before installing on production.
• Verify with fw stat after install to confirm the active policy on each gateway.
• Use Hit Count to continuously clean up the rulebase — review zero-hit rules quarterly.
• Keep fw unloadlocal as an emergency-only tool — never as a routine rollback.
• Stage large policy changes by installing on one gateway first, then on the rest after verification.

Why This Matters for the Exam

The CCSA R82 exam tests Hit Count's purpose (rule optimization and audit), the policy install workflow (edit → validate → install → verify), the role of fw stat (confirm active policy), and fw unloadlocal (emergency rollback). Expect a question about what to do when a policy install breaks connectivity: the answer is fw unloadlocal to restore management access, then reinstall a corrected policy.