Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] How does snoop and debug flow basic work on higher end devices, such as ISG-1000, ISG-2000, NetScreen 5200, and NetScreen 5400?



Article ID: KB5925 KB Last Updated: 18 Dec 2017Version: 11.0
Snoop and 'debug flow basic' only captures the first packet of sessions in 'get db stream' output. What is the cause of this?

A customer tried to run debug flow basic on the a NS5000 series firewall; only the first packet was displayed in the output of get dbuf stream.  This is also applicable to snoop.


The CPU processes the following packets on ASIC based platforms:

  • The first packet for session creation.

  • The packets that need ALG/DI/Web Filtering.

  • The packets for protocols, such as ICMP, ICMPv6, IGMP, PIM, OSPF, PIM, VRRP, SCTP, and so on.

When the commands debug flow basic and snoop are run, they will capture the packets that are processed or handled by the CPU of the device.

Currently, on the ISG and NS-5000 series firewalls, debug flow and snoop work for TCP based traffic in the following manner:
  1. Ideally, the first packet that is SYN will be captured by debug flow basic and snoop, as it is received in the hardware (ASIC) and then sent to the CPU for processing; so it appears in both. This is also termed first packet processing.

    If the first packet is non-SYN, then the TCP SYN Check and TCP SYN bit check features will decide whether to allow or deny the traffic. For more information, refer to KB4444  - What is the default setting for 'set flow tcp-syn-check' and how do you check.

  2. The ASIC maintains a hardware session, along with the software session. The next return packet is handled in hardware; not via the CPU. So, debug flow and snoop will not display the next return packet.

  3. thus, you cannot see the TCP 3 way handshake completely in debugs. For example, if you Telnet via the device, debug flow and snoop will display only the first TCP SYN packet.

    Note: For troubleshooting purposes, you can configure the policy to ignore the building of a hardware session and re-run the debug flow or snoop commands. 

This is applicable only to ScreenOS 6.1 or later.

This is suggested for troubleshooting purposes. Running No-hw-sess indicates that the traffic is sent to the CPU for processing. Therefore, this is not advisable in a High CPU condition. Also, this command can cause High CPU usage, in case of high traffic flow matching the policy.

The following example is of a policy with no-hw-sess being configured:

set policy from trust to untrust any any any permit no-hw-sess

To add it in an existing policy, use the following command:

set policy id <number>
set no-hw-sess
set flow all-tcp-mss XXX

This will force the three-way handshaking process to the CPU. You will be able to see the TCP three-way handshake in debugs. Use the above command with caution; it may degrade the firewall performance. For more information, refer to KB6346  - What does 'set flow all-tcp-mss' and 'set flow tcp-mss' do?

Modification History:
‚Äč2017-12-07: Article reviewed for accuracy. Added correct products in the categories. Also added summary of the article. Article is correct and complete.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search