NetScreen Debugging Commands

If you need to troubleshoot problems with traffic flowing through a NetScreen firewall, or not flowing through, as the case may be, you can use the snoop command to provide packet sniffer capabilities for a Juniper NetScreen firewall, but, if you need to see how policies are being applied or exactly how the firewall is handling problematic traffic, then you need to use the built-in debugging capability.

When you have debugging turned on, information is stored in the debug buffer. The command clear db clears any existing data from the buffer, which you may want to do each time you start a new debugging session. To view any existing debug filters, you can use the command get ffilter. You can set a filter with set ffilter. The command debug flow basic starts debugging, while the command undebug all turns off debugging. You can view the debug buffer with get dbuf stream or the shortened form get db str.

ns5gt-> clear db
ns5gt-> get ffilter
ns5gt-> set ffilter dst-port 27900
filter added
ns5gt-> get ffilter
Flow filter based on:
id:0 dst port 27900
ns5gt-> debug flow basic
ns5gt-> undebug all
ns5gt-> get db str
****** 306813.0: <Trust/trust> packet received [33]******
  ipid = 24666(605a), @03cc7fb0
  packet passed sanity check.
  trust:192.168.2.3/53434->207.38.11.34/27900,17<Root>
  existing session found. sess token 2
  flow got session.
  flow session id 1539
  post addr xlation: 72.45.13.244->207.38.11.34.
<text snipped>
****** 306885.0: <Untrust/untrust> packet received [35]******
  ipid = 35709(8b7d), @03c31c30
  packet passed sanity check.
  untrust:72.81.210.154/3049->10.45.13.244/27900,17<Root>
  self check, not for us
  chose interface untrust as incoming nat if.
  packet dropped: for self but not interested

I can see from the above output that a UDP datagram was receivd from 72.81.210.154 port 3049 at 10.45.13.244/27900,17, i.e. port 27900 on the untrust side of the firewall. The 17 specifies the IP protocol number; 17 indicates it is a UDP datagram. I can see that the firewall just dropped the packet, so apparently "thinks" it doesn't have any policies defined to deal with such packets.

In the example above, I filtered only on the destination port. You can specify multiple filtering options. The first command below filters on a source IP address, 173.20.5.255 and specify that only UDP data should be examined, i.e. IP protocol number 17. The next command, debug flow basic actually starts the capture of data to the debug buffer.

ns5gt-> set ffilter src-ip  173.20.5.255 ip-proto 17
filter added
ns5gt-> debug flow basic

The options for setting filters are as follows:

ns5gt-> set ffilter ?
<return>
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

If you set multiple filters it is as if there is an "or" between them. That is, if ANY packet matches ANY of of the flow filters then that packet will be matched. You can remove filters with unset ff.

ns5gt-> unset ff
filter 0 removed
ns5gt-> get ff
ns5gt->

For viewing the data in the buffer, you can use the get dbuf mem or get dbuf stream commands. The options for the get dbuf stream command are as follows:

ns5gt-> get dbuf stream ?
>                    redirect output
|                    match output
<return>
all                  from all slots
<number>             percentage offset of debug buffer(0-99)

The command get dbuf stream produces output in the following format:

ns5gt-> get db stream
45
              vhl=45, tos=00, id=60051, frag=0000, ttl=63
              udp:ports 49693->58540, len=25

312908.0: 1(o):0010db7d2861->001d70cce905/0800
              10.45.13.244->173.22.35.38/17, tlen=45
              vhl=45, tos=00, id=60051, frag=0000, ttl=62
              udp:ports 2109->58540, len=25

312909.0: 2(i):00173f449751->0010db7d2862/0800
              192.168.2.3->173.22.35.38/17, tlen=45
              vhl=45, tos=00, id=60060, frag=0000, ttl=63
              udp:ports 49693->58540, len=25

312909.0: 1(o):0010db7d2861->001d70cce905/0800
              10.45.13.244->173.22.35.38/17, tlen=45
              vhl=45, tos=00, id=60060, frag=0000, ttl=62
              udp:ports 2109->58540, len=25

You can also filter the display of information stored in the debug buffer using | incl searchpattern. E.g., suppose I wanted to dispaly just those lines for UDP data (protocol number 17) that show the source and destinations involved. I know those lines have ,17 in them, so I can use the following command:

ns5gt-> get dbuf stream | incl ",17"
  trust:192.168.2.3/61405->173.20.5.255/33554,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  trust:192.168.2.3/61405->173.20.5.255/33554,17<Root>
  untrust:173.20.5.255/33278->72.45.13.244/2738,17<Root>
  trust:192.168.2.3/61405->173.20.5.255/33554,17<Root>

You can even use some regular expression syntax. For instance I could use get dbuf stream | incl "untrust:.*,17" to limit the output to use those lines that contain "untrust:" followed by any character, which is represented by the "." occuring zero or more times, which is the meaning attached to the "*", then followed by ",17". I.e., I'm looking for lines that contain "untrust" followed by ",17" somewhere later on the line.

ns5gt-> get dbuf stream | incl "untrust:.*,17"
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
  untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>

You can also use the get dbuf mem command to view the data stored in the debug buffer, which will show the data in hex format as well as ASCII.

ns5gt-> get dbuf mem
====32768
32 37 38 36 28 30 61 65 32 29 2c 20 40 30 33 63     2786(0ae2),.@03c
31 33 63 33 30 0d 0a 20 20 70 61 63 6b 65 74 20     13c30....packet.
70 61 73 73 65 64 20 73 61 6e 69 74 79 20 63 68     passed.sanity.ch
65 63 6b 2e 0d 0a 20 20 75 6e 74 72 75 73 74 3a     eck.....untrust:
31 37 33 2e 32 30 2e 35 2e 32 35 35 2f 33 33 35     173.20.5.255/335
31 35 2d 3e 31 30 2e 34 35 2e 31 33 2e 32 34 34     15->10.45.13.244
2f 31 39 36 38 2c 31 37 3c 52 6f 6f 74 3e 0d 0a     /1968,17<Root>..
20 20 73 65 6c 66 20 63 68 65 63 6b 2c 20 6e 6f     ..self.check,.no
74 20 66 6f 72 20 75 73 0d 0a 20 20 63 68 6f 73     t.for.us....chos
65 20 69 6e 74 65 72 66 61 63 65 20 75 6e 74 72     e.interface.untr
75 73 74 20 61 73 20 69 6e 63 6f 6d 69 6e 67 20     ust.as.incoming.
6e 61 74 20 69 66 2e 0d 0a 20 20 70 61 63 6b 65     nat.if.....packe
74 20 64 72 6f 70 70 65 64 3a 20 66 6f 72 20 73     t.dropped:.for.s
65 6c 66 20 62 75 74 20 6e 6f 74 20 69 6e 74 65     elf.but.not.inte
72 65 73 74 65 64 0d 0a 2a 2a 2a 2a 2a 2a 20 33     rested..******.3
32 30 35 33 30 2e 30 3a 20 3c 54 72 75 73 74 2f     20530.0:.<Trust/
74 72 75 73 74 3e 20 70 61 63 6b 65 74 20 72 65     trust>.packet.re
63 65 69 76 65 64 20 5b 34 38 5d 2a 2a 2a 2a 2a     ceived.[48]*****
2a 0d 0a 20 20 69 70 69 64 20 3d 20 35 30 32 34     *....ipid.=.5024
36 28 63 34 34 36 29 2c 20 40 30 33 63 62 32 66     6(c446),.@03cb2f
62 30 0d 0a 20 20 70 61 63 6b 65 74 20 70 61 73     b0....packet.pas
--- more ---

You can hit the spacebar or other keys to page through the data or hit q to quit.

If you want to clear out any captured data, unset all filters, and turn debugging off when you are finished with your debugging activity, you could enter the following sequence of commands:

ns5gt-> clear dbuf
ns5gt-> get ffilter
Flow filter based on:
id:0 src ip 173.20.5.255
ns5gt-> undebug all
ns5gt-> unset ff
filter 0 removed

References:

  1. NetScreen+debug
    Geek2Live: NetScreen debug Illustrated
  2. Debugging ScreenOS on Juniper Netscreen
    By: Greg Ferro Date: March 11, 2008 Etherealmind.com

Valid HTML 4.01 Transitional

Created: Tuesday April 14, 2009