Management and Troubleshooting · Topic 3 of 6
Firewall Engine Debug and System Support Trace
Learn how firewall engine debug and system support trace show which access control rule matched a connection and what Snort decided on each packet.
- 4 min
system support firewall-engine-debugshows the access control rule and action for a connection.- The command asks for protocol, client and server addresses and ports as filters.
system support traceshows per packet processing and verdicts from Snort.
What it is
Firewall engine debug and system support trace are device CLI tools that show how Snort handles a connection.
Firewall engine debug explains how the access control policy was applied to a connection. It shows the rule that matched and the action that followed.
System support trace goes one step further. It shows what happened to each packet, and it can include the same debug output with it.
How it works
Both tools run from the FTD CLI and ask which traffic you want to watch.
Why they exist
A packet capture shows that traffic arrives, and Packet Tracer shows a simulated result. Neither tells you what the live Snort engine decided for a real connection.
These two commands fill that gap. They answer questions such as why a connection was blocked, which rule it matched, and which application Snort found.
Firewall engine debug
You start it from the CLI. The device asks for the values that filter the output.
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address: 10.1.1.10
Please specify a client port:
Please specify a server IP address: 203.0.113.5
Please specify a server port: 443
Monitoring firewall engine debug messagesYou can leave a prompt empty to match any value. The more you narrow it down, the less noise you get.
When matching traffic arrives, the output shows the key facts of the decision. These include the access control rule that matched, the action, and the application and URL that Snort identified.
Stop the debug with Ctrl and C. A debug left running can use up resources on a busy firewall.
System support trace
> system support traceThe command asks for similar filter values. It also asks if you want to enable firewall engine debug at the same time. Answer yes to see the rule matching with the packet detail.
The output follows each packet through the engine. It shows the stages and the verdict that Snort gave. This helps when a packet is dropped by an intrusion rule or by a policy setting, because the line for that packet names the cause.
What to look for
| You see | It tells you |
|---|---|
| The matched rule name | Which access control rule applied |
| An allow or block action | The result of the rule |
| The application and URL | What Snort identified, which rules can match on |
| A verdict line per packet | How Snort treated that packet |
If the application is not yet identified, a rule that needs the application may not match until later in the connection. That explains traffic that is first allowed by one rule and then treated by another.
Using them with the other tools
Start with the connection event in the FMC and Packet Tracer. If the answer is not clear, run the engine debug while you reproduce the problem. Use system support trace when you need the per packet view.
Run the tools for as short a time as possible. Use filters, and stop them as soon as you have the answer.
The deployment link
If the debug shows a rule that you removed, the device may still run an old policy. Check the deployment status in the FMC, because a failed deploy leaves the old policy in place.
What to remember for the exam
Seven facts cover the usual questions.
system support firewall-engine-debugshows the access control rule and action for a connection.- The command asks for protocol, client and server addresses and ports as filters.
system support traceshows per packet processing and verdicts from Snort.- System support trace can also turn on the firewall engine debug output.
- These tools show what the live Snort engine decided, which a capture cannot.
- They should be run with filters and for a short time.
- Ctrl and C stops the output.
When a question asks how to find out which access control rule matched a live connection, the answer is firewall engine debug.
Common mistakes
These four mistakes are common with these tools.
Running them with no filter. The output can flood the session on a busy firewall.
Leaving them running. Stop the debug after you have the result.
Using Packet Tracer for a live verdict. It simulates a packet, and the debug shows the real decision.
Ignoring deployment state. The matched rule comes from the policy that is actually deployed.
Debug output uses device resources. Use it on a production firewall only with tight filters and for a short time.
Check yourself
Work through these three questions.
Which command shows the access control rule that matched a live connection?
system support firewall-engine-debug, which shows the rule and the action for the filtered traffic.What does system support trace add to the rule matching output?
It adds the processing and the verdict that Snort gave to each packet.
Why use filters with these tools?
Without filters the output can be too large to read and can use resources on a busy firewall.
Topic 3 of 6 in Management and Troubleshooting
Test yourself on Management and Troubleshooting
The full Cisco CCNP 300-710 SNCF question bank has 865 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Cisco. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.