Cisco CBRFIR (300-215) common mistakes
Cisco CBRFIR (300-215) · Understand the traps and how to avoid them.
Treating the ACP as a simple top-down permit/deny list and forgetting that the first matching rule wins, so rules are ordered by convenience rather than by specificity and intent.
Candidates often add rules as they go during labs, placing a broad permit at the top and then wondering why later deny rules never trigger; they conflate the ACP with a traditional ACL where order is also first-match but where prefilter and default actions are absent.
What to do instead
Before writing rules, sketch the traffic flow and order rules from most specific to least specific. Place block rules for known-bad traffic above broad permits, verify each rule's hit counters, and confirm the default action (block or trust) is set deliberately.
Confusing Prefilter policy with the Access Control Policy and expecting prefilter rules to apply to traffic that is already being handled by the ACP, or vice versa.
Both policies process traffic in sequence and both can block or tunnel, so candidates assume they are interchangeable; they miss that prefilter handles fast-path decisions like tunneled traffic, GRE, and pre-encrypted flows before the ACP evaluates.
What to do instead
Memorize the pipeline order: prefilter first, then ACP, then the default action. Use prefilter only for tunnel handling and early fast-path blocks. Test with packet tracer to confirm which policy a given flow hits.
Assuming a rule that permits traffic also inspects it, and leaving intrusion, file, and malware inspection disabled or unassigned on the rule.
Candidates focus on the allow/block decision and forget that inspection requires explicitly attaching an intrusion policy and file/malware policy to the rule, and that the default action may bypass inspection entirely.
What to do instead
For every permit rule, explicitly attach the intended intrusion policy and file policy. Verify inspection is active by checking the connection events for the flow and confirming the rule shows the inspection policy in the rule editor.
Misunderstanding the difference between an intrusion policy's drop and alert-only modes, then expecting blocking behavior from a policy that is set to detect only.
Candidates see an IPS rule with a block action in the rule set and assume traffic is dropped, but the policy-level setting (prevention vs. detection) controls whether drop actions are enforced.
What to do instead
Confirm the intrusion policy is in Prevention mode when blocking is required. Check the rule action (drop vs. alert) and the policy mode separately, and validate with a test exploit whether the connection is actually reset.
Deploying configuration changes to the wrong device or forgetting to deploy at all, then troubleshooting behavior that reflects the old configuration.
In multi-device or clustered deployments, candidates edit a policy and expect it to take effect immediately, not realizing changes must be deployed and that a deployment can target a specific device or all devices.
What to do instead
After every change, confirm the deployment target and complete the deploy. Check the deployment status and task list, and verify the running configuration on the device reflects the change before starting any test.
Mixing up management interface, diagnostic interface, and data interface roles when configuring initial device setup, leading to unreachable management or broken traffic flow.
Candidates configure interfaces by IP address alone without checking which interface is designated for management and which carries data, so they assign conflicting gateways or route management traffic through a data path.
What to do instead
Review the interface role table before configuration: management interface for FMC communication, data interfaces for traffic. Verify routing and default gateway per interface, and confirm FMC registration succeeds before moving on.
Reading troubleshooting output without correlating it to the correct layer-jumping to ACL or policy conclusions when the problem is routing, NAT, or a broken connection event pipeline.
Candidates see a blocked connection and assume a rule blocked it, but the block may come from routing failure, NAT translation, or the default action; they also ignore that connection events require the eventing configuration to be healthy.
What to do instead
Work layer by layer: verify routing and NAT first, then policy match, then inspection. Use packet tracer to see the simulated path and rule match, and confirm connection events are being generated and sent to the manager.
Ignoring file and malware policy prerequisites, such as the file policy being attached to the rule and the correct file inspection configuration, then concluding malware detection is broken.
Candidates test with a file transfer but never confirm the rule carries a file policy, that the file type is being inspected, or that the malware defense components are updated and active.
What to do instead
Attach the file policy to the permit rule, confirm the file type is in scope for inspection, verify the malware and file reputation components are current, and check file events in the analysis view to confirm the file was actually seen and analyzed.
Treating NAT and access control as independent, then debugging a policy block that is actually a NAT translation or routing order problem.
Candidates configure a static or dynamic NAT rule and expect the ACP to see the translated address, but policy evaluation order relative to NAT and the direction of translation cause the rule to match on unexpected addresses.
What to do instead
Establish whether policy sees pre- or post-NAT addresses for the given flow, align rule match criteria with that ordering, and use packet tracer to confirm the address the policy evaluates. Test with and without NAT to isolate the cause.
Skipping the monitoring and analysis workflow-relying only on live traffic tests and never validating with connection events, intrusion events, or dashboards.
Candidates treat monitoring as an afterthought and finish configuration without confirming events are generated, correlated, and visible; they then cannot diagnose failures during the exam or in operations.
What to do instead
After each configuration change, generate test traffic and confirm the expected connection, intrusion, or file events appear in analysis. Use the event viewer and dashboards to verify counts, and treat missing events as a configuration defect to investigate.