Tags

, , , , ,

The Debug utility can help troubleshooting traffic flow issues for many different traffic types.  Below you will find how to run debug flow basic as well as a few other debug options.

netscreen_5400_frontwtop_high

Many times, when contacting support, debugging information is requested to further troubleshoot a problem.  The following shows a brief procedure on obtaining debugging information:

  • Connect or Telnet to the Juniper Firewall device.
  • Turn on the dbuf buffer.  This sets up a portion of memory required to hold the debug information needed.

When troubleshooting the firewall, the output of the debug will be directed either to the console or to a buffer. Usually, the debugging information should go to the buffer, opposed to the console. When information is sent to the console, it is resource intensive, and can produce performance problems if too much debugging information is sent to the console. The alternative is sending the data to a buffer called dbuf.

From the command line interface (CLI): set console dbuf

  • Set the parameters for debugging.  This is important.  Specify what information is to be captured in the debug.  Capturing too much information can overload the CPU of the Firewall.  For additional information, consult: Understanding debug filters.

From the CLI:

fw-> set ffilter ?

dst-ip               flow filter dst ip
dst-port             flow filter dst port
ip-proto             flow filter ip proto
src-ip               flow filter src ip
src-port             flow filter src port
ns100-> set ffilter

These are the options available to filter a debug.

Example: Trying to find out why a PC, IP address 192.168.10.50, on the local network cannot get out to the Internet.  Set up a filter so the debug will show what happens when that PC tries to communicate to the Internet:

set ffilter src-ip 192.168.10.50

The Firewall will perform a debug on the data coming from the source IP of 192.168.10.50.

Note: Keep in mind that these parameters apply to the outermost IP header, so if the packets are encapsulated in a VPN tunnel, then you may not capture those packets in the tunnel, unless you also add filters for the VPN tunnel.

  • Turn on the debug flow.  This will display information related to the flow of traffic through the box.  There are three levels of debug flow:

basic
all
drop

For most cases, debug flow basic should be sufficient.  From the CLI:

debug flow basic 

Use debug flow drop command to see dropped or denied packets (including those that did not make it to the policy engine).  This will give you detailed information about all packets trying to pass through the firewall, but for some reason is dropped.  Logs on the policy will only get logged if a session is completed.  This debug will give you dropped information, just in case a session does not get created.

debug flow drop

  • After traffic has flowed through the firewall, and failed, turn off the debug.  Press the <esc> or from the CLI:

undebug all 

  • Obtain the output of the debug.  From the CLI:

Example fw-> get dbuf stream
12630.0: trust:172.16.10.144/1545->24.0.0.27/53,17
12630.0:   search acl set 0
12630.0:   Send to untrust
12630.0: icmp embed ip: 24.0.0.27/53->172.16.10.144/1545,17
12630.0: untrust:24.0.0.27/53->172.16.10.144/1545,17
12630.0:   Send to trust
12630.0: untrust:24.0.0.27/53->172.16.10.144/1545,17
12630.0:   Send to trust
12630.0: trust:172.16.10.144/38400->204.71.200.75/256,1
12630.0:   search acl set 0
12630.0:   Send to untrust 

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

Advertisements