I’ve worked with Netscreens for a few years now, starting with ScreenOS version 5.x, and when troubleshooting I had always been pointed towards debug flow as the way to see what was going on. I suspect many of you have also been taught:

• clear db
• debug flow basic
• (wait for packets you wanted to capture)
• undebug all
• get db stream (to view output)

This is definitely helpful for rule debugging but for simple packet capture is a bit over the top, which is where the snoop command comes in.

Snoop

To be clear, snoop won’t tell you anything about what decisions the firewall made about the packets, but it’s a simple way to see the actual traffic. Here’s an example of the output produced by snoop:

19944926.0: ethernet2/1(o) len=206:0010dbff2070->00005e000101/8100/0800, tag 1872
              1.4.63.82 -> 1.15.18.27/17
              vhl=45, tos=00, id=13096, frag=0000, ttl=64 tlen=188
              udp:ports 500->500, len=168
              00 00 5e 00 00 01 00 10 db a1 27 a1 81 00 07 50     ..^........p....
              08 00 45 00 00 bc 33 28 00 00 40 11 b6 18 01 04     ..E...3([email protected]
              3f 52 01 0e 12 1b 01 f4 01 f4 00 a8 95 79 a8 d3     @4P..........y..
              a6 4a f3 28 34 82 00 00 00 00 00 00 00 00 02 18     ...........3@...
              09 00 00 00 00 00 00 00 00 c2 0a 00 00 ea 00 00     ....a..'........
              00 08 00 00 00 16 00 00 00 b8 02 31 aa 90 00 00     ...P....y.......

Pretty straightforward stuff – you get to see the source and destination IP and protocol (17 is UDP), some header and port information, and the length, followed by a hex dump of some of the packet. That’s enough to see what’s going on in many cases. So how do you use it?

Snoop Configuration

First step, make sure nothing else is filling the debug buffer:

• undebug all
• snoop off

Now double check the current status of snoop to make sure it’s not running:

netscreen-> snoop info
Snoop: OFF
Filters Defined: 0, Active Filters 0
Detail: ON, Detail Display length: 96
Snoop tunnel traffic: ON
netscreen->

In this case there are no filters already defined, so we can create one. As a simple example, let’s filter on a specific IP:

• snoop filter ip 1.2.3.4

There are actually a number of options you can add to this command, including IPs, ports, IP protocols and direction (the default is to capture both inbound and outbound). You can also add more than up to eight filters; just issue the snoop filter ip command again and the filter will be added. If we check the status of the snoop again, the new filter shows up and it has an id:

netscreen-> snoop info
    Snoop: OFF
    Filters Defined: 1, Active Filters 1
    Detail: ON, Detail Display length: 96
    Snoop tunnel traffic: ON
    Snoop filter based on:
    id 1(on): IP ip 1.2.3.4 dir(B)

The filter id can be used to individual enable, disable, or delete a filter:

netscreen-> snoop filter id 1 ?
delete               delete snoop filter
off                  turn off snoop filter
on                   turn on snoop filter

Now the filter is in place, let’s clear the old debug buffer before we start adding content:

• clear dbuf

And finally, we’ll start our snoop:

• snoop

You’ll be prompted to type y to continue with the snoop. At any point, you can view the current buffered output by issuing:

• get dbuf stream

If you’re on console, if memory serves, the db stream is mirrored there automatically, but I believe on a VTY you don’t get to see it unless you issue the get db stream command.

When you’re done, stop the snooping:

• snoop off

If you want to delete the filters you added (all of them):

• snoop filter delete

…or you can delete individual filters by id.

My 10 Bits

I failed to discover this command’s existence for the longest time, and I have no idea how as it’s incredibly useful; just remember to turn it off afterwards. It feels – subjectively – safer somehow than a debug flow basic, but I welcome your opinions on that statement!