O'Reilly logo

Junos Security by James Quinn, Timothy Eberhard, Patricio Giecco, Brad Woodberg, Rob Cameron

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Troubleshooting Security Policy and Traffic Flows

In most cases, simple policy logging of the traffic that is being denied and permitted is sufficient to verify what the SRX is doing with the data. However, in some instances more information is needed. On the NetScreen platform this information was gained via debugs, typically via debug flow basic. Juniper has taken into account how often debugs are used when troubleshooting traffic flows, in addition to policies, and has improved on this feature with traceoptions.

Within traceoptions you can accomplish the equivalent of a “debug flow basic” via basic-datapath traceoption. Traceoptions monitor and log traffic flows going into and out of the SRX and, much like the NetScreen debugs, filters tend to be very resource-intensive. The authors of this book highly suggest that when you use traceoptions you always have a packet filter set, and that the packet filter is as specific as possible to avoid any adverse system impacts.

Note

Unlike on the NetScreen platform, on the SRX you can configure only one expression per packet filter. To examine bidirectional communication you need multiple packet filters, one for each direction.

Troubleshooting Sample

Our sample problem is as follows: while configuring a new web server, users are complaining that they cannot access the website. It has already been confirmed that policy is written correctly and traffic logs session initiation. It’s all shown somewhat briefly in Figure 4-5.

The source is 10.1.1.100, a local workstation on the Trust zone in Dept-A via port ge-0/0/0.0.

The destination is 10.2.0.3, a new web server on the web-dmz zone via port fe-0/0/2.0.

Sample problem showing users unable to access the website

Figure 4-5. Sample problem showing users unable to access the website

The first thing we should do is to configure a logfile for the traceoption output. We can do this using the file <file_name> command. Here, the output file is named tshoot_web:

juniper@SRX5800# edit security flow traceoptions
[edit security flow traceoptions]
juniper@SRX5800# set file tshoot_web

Next we need to set the filters. It’s worth noting that nothing takes effect until the configuration is committed, so it’s perfectly safe to change the order in which these items are configured:

[edit security flow traceoptions]
juniper@SRX5800# set packet-filter trust_to_web source-prefix 10.1.1.100/32
destination-prefix 10.2.0.3/32
[edit security flow traceoptions]
juniper@SRX5800# set packet-filter web_to_trust source-prefix 10.2.0.3/32
destination-prefix 10.1.1.100/32

Note

In the preceding output, two packet filters have been configured. The first filter is for 10.1.1.100 to 10.2.0.3 and the second filter is for the reverse traffic flow 10.2.0.3 talking to 10.1.1.100.

The last item we need to configure is the actual traceoption flag. Here, it is basic-datapath, as this should give us all the information we need:

[edit security flow traceoptions]
juniper@SRX5800# set flag basic-datapath

If you haven’t heard it before, it’s always wise to review the configuration before applying:

juniper@SRX5800# show security flow traceoptions
file tshoot_web;
flag basic-datapath;
packet-filter trust_to_web {
    source-prefix 10.1.1.100/32;
    destination-prefix 10.2.0.3/32;
}
packet-filter web_to_trust {
    source-prefix 10.2.0.3/32;
    destination-prefix 10.1.1.100/32;
}
[edit]

The output of the config looks correct. All of the required configuration options are there: a traceoptions file, a traceoptions flag, and two packet filters for bidirectional traffic. Since everything looks OK, we can commit the configuration and the workstation can initiate some traffic so that we can monitor it. Once the test traffic has been completed, all the data to troubleshoot our problem should be in the tshoot_web traceoptions file.

Note

The output contains a lot of detailed information regarding what the SRX is doing with the packet as it passes through its hardware and does its series of checks, and the reality is that you can overlook much of this information in the output because it’s for developers who are troubleshooting and does not apply to what you need to know. Also, the traceoptions output will likely change over the printed lifetime of this book, as the developers add and remove information.

Troubleshooting Output

The output of the packet’s details is shown in its entirety in Example 4-1. Look through it and then we’ll break down what each portion means or does and what we can overlook.

This output is from a single first packet as it enters the SRX in our troubleshooting scenario (see Figure 4-5).

Example 4-1. Output of the packet’s details, in its entirety

juniper@SRX5800> show log tshoot_web
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:<10.1.1.100/51510-
>10.2.0.3/80;6> matched filter trust_to_web:
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:packet [48] ipid = 57203,
@423f6b9e
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:---- flow_process_pkt: (thd
1): flow_ctxt type 13, common flag 0x0, mbuf 0x423f6a00
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: flow process pak fast ifl
68 in_ifp ge-0/0/0.0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  ge-
0/0/0.0:10.1.1.100/51510->10.2.0.3/80, tcp, flag 2 syn
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: find flow: table
0x4d5c8238, hash 1430(0xffff), sa 10.1.1.100, da 10.2.0.3, sp 51510,
dp 80, proto 6, tok 384
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  no session found, start
first path. in_tunnel - 0, from_cp_flag - 0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow_first_create_session
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow_first_in_dst_nat: in
<ge-0/0/0.0>, out <N/A> dst_adr 10.2.0.3, sp 51510, dp 80
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  chose interface ge-
0/0/0.0 as incoming nat if.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_rule_dst_xlate:
DST no-xlate: 0.0.0.0(0) to 10.2.0.3(80)
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_routing: call
flow_route_lookup(): src_ip 10.1.1.100, x_dst_ip 10.2.0.3, in ifp ge-
0/0/0.0, out ifp N/A sp 51510, dp 80, ip_proto 6, tos 0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:Doing DESTINATION addr
route-lookup
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  routed (x_dst_ip
10.2.0.3) from trust (ge-0/0/0.0 in 0) to ge-0/0/0.0, Next-hop:
10.1.1.1
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  policy search from zone
trust-> zone trust
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  app 6, timeout 1800s,
curr ageout 20s
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_src_xlate:
10.1.1.100/51510 -> 10.2.0.3/80 | 10.2.0.3/80 -> 0.0.0.0/51510:
nat_src_xlated: False, nat_src_xlate_failed: False
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_src_xlate: src
nat 0.0.0.0(51510) to 10.2.0.3(80) returns status: 0, rule/pool id:
0/0, pst_nat: False.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  dip id = 0/0,
10.1.1.100/51510->10.1.1.100/51510
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_get_out_ifp:
1000 -> cone nat test
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  choose interface ge-
0/0/0.0 as outgoing phy if
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:is_loop_pak: No loop: on
ifp: ge-0/0/0.0, addr: 10.2.0.3, rtt_idx:0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:policy is NULL (wx/pim
scenario)
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:sm_flow_interest_check:
app_id 0, policy 4, app_svc_en 0, flags 0x2. not interested
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:sm_flow_interest_check:
app_id 1, policy 4, app_svc_en 0, flags 0x2. not interested
Jan 17 12:35:51 12:35:50.1249501:CID-
0:RT:flow_first_service_lookup(): natp(0x4b9f2198):
local_pak(0x3fdedc70.0x423f6a00):  TCP proxy NOT interested: 0.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  service lookup identified
service 6.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow_first_final_check:
in <ge-0/0/0.0>, out <ge-0/0/0.0>
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  existing vector list 2-
446fe828.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  Session (id:9270) created
for first pak 2
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:
flow_first_install_session======> 0x4b9f2198
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: nsp 0x4b9f2198, nsp2
0x4b9f2204
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:
make_nsp_ready_no_resolve()
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  route lookup: dest-ip
10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-0/0/0.0 orig-zone 6 out-
zone 6 vsd 0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  route to 10.1.1.100
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:Installing c2s NP session
wing
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:Installing s2c NP session
wing
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow got session.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow session id 9270
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  tcp flags 0x2, flag 0x2
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  Got syn,
10.1.1.100(51510)->10.2.0.3(80), nspflag 0x1021, 0x20
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:mbuf 0x423f6a00, exit nh
0x30010
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: ----- flow_process_pkt rc
0x0 (fp rc 0)

That’s a lot to digest. To make this easier (quicker) to read, a helpful tip is to use the trim command option. The trim command removes a specified number of characters. For instance, you can use it to remove the date and time to make the code a lot easier to read or fit on a screen. Example 4-2 shows the trace file trimmed. Trim 42 removes the date and time as well as the CID-0:RT:, leaving just the important data.

Example 4-2. Trimmed trace file

juniper@SRX5800> show log tshoot_web | trim 42
<10.1.1.100/51510->10.2.0.3/80;6> matched filter trust_to_web:
packet [48] ipid = 57203, @423f6b9e
---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0,
mbuf 0x423f6a00
 flow process pak fast ifl 68 in_ifp ge-0/0/0.0
  ge-0/0/0.0:10.1.1.100/51510->10.2.0.3/80, tcp, flag 2 syn
 find flow: table 0x4d5c8238, hash 1430(0xffff), sa 10.1.1.100, da
10.2.0.3, sp 51510, dp 80, proto 6, tok 384
  no session found, start first path. in_tunnel - 0, from_cp_flag - 0
  flow_first_create_session
  flow_first_in_dst_nat: in <ge-0/0/0.0>, out <N/A> dst_adr 10.2.0.3,
sp 51510, dp 80
  chose interface ge-0/0/0.0 as incoming nat if.
flow_first_rule_dst_xlate:  DST no-xlate: 0.0.0.0(0) to 10.2.0.3(80)
flow_first_routing: call flow_route_lookup(): src_ip 10.1.1.100,
x_dst_ip 10.2.0.3, in ifp ge-0/0/0.0, out ifp N/A sp 51510, dp 80,
ip_proto 6, tos 0
Doing DESTINATION addr route-lookup
  routed (x_dst_ip 10.2.0.3) from trust (ge-0/0/0.0 in 0) to ge-
0/0/0.0, Next-hop: 10.1.1.1
  policy search from zone trust-> zone trust
  app 6, timeout 1800s, curr ageout 20s
flow_first_src_xlate: 10.1.1.100/51510 -> 10.2.0.3/80 | 10.2.0.3/80 -
> 0.0.0.0/51510: nat_src_xlated: False, nat_src_xlate_failed: False
flow_first_src_xlate: src nat 0.0.0.0(51510) to 10.2.0.3(80) returns
status: 0, rule/pool id: 0/0, pst_nat: False.
  dip id = 0/0, 10.1.1.100/51510->10.1.1.100/51510
flow_first_get_out_ifp: 1000 -> cone nat test
  choose interface ge-0/0/0.0 as outgoing phy if
is_loop_pak: No loop: on ifp: ge-0/0/0.0, addr: 10.2.0.3, rtt_idx:0
policy is NULL (wx/pim scenario)
sm_flow_interest_check: app_id 0, policy 4, app_svc_en 0, flags 0x2.
not interested
sm_flow_interest_check: app_id 1, policy 4, app_svc_en 0, flags 0x2.
not interested
flow_first_service_lookup(): natp(0x4b9f2198):
local_pak(0x3fdedc70.0x423f6a00):  TCP proxy NOT interested: 0.
  service lookup identified service 6.
  flow_first_final_check: in <ge-0/0/0.0>, out <ge-0/0/0.0>
  existing vector list 2-446fe828.
  Session (id:9270) created for first pak 2
  flow_first_install_session======> 0x4b9f2198
 nsp 0x4b9f2198, nsp2 0x4b9f2204
  make_nsp_ready_no_resolve()
  route lookup: dest-ip 10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-
0/0/0.0 orig-zone 6 out-zone 6 vsd 0
  route to 10.1.1.100
Installing c2s NP session wing
Installing s2c NP session wing
  flow got session.
  flow session id 9270
  tcp flags 0x2, flag 0x2
  Got syn, 10.1.1.100(51510)->10.2.0.3(80), nspflag 0x1021, 0x20
mbuf 0x423f6a00, exit nh 0x30010
 ----- flow_process_pkt rc 0x0 (fp rc 0)

Now, let’s analyze the data from the traceoption’s output shown in Example 4-2.

The first line, shown here, displays the source IP 10.1.1.100 and destination IP 10.2.0.3, as well as the ports used to communicate. It then documents that this traffic matched the trust_to_web traceoptions filter.

<10.1.1.100/60218->10.2.0.3/80;6> matched filter trust_to_web:

The next line gives us the IPID, which is 57203 in this example:

packet [48] ipid = 57203, @423f6b9e

These two lines are basically useful to internal developers for troubleshooting hardware/software issues, and not for our problem at hand:

---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0,
mbuf 0x423f6a00
 flow process pak fast ifl 68 in_ifp ge-0/0/0.0

Notice that the inbound interface is ge-0/0/0.0 and the protocol is TCP, and that this is a SYN packet:

ge-0/0/0.0:10.1.1.100/60218->10.2.0.3/80, tcp, flag 2 syn

Here is the output as the SRX performs its 5-tuple lookup. The 5-tuple includes the source, destination, source port, destination port, and protocol. Protocol number 6 is TCP.

find flow: table 0x4d5c8238, hash 1430(0xffff), sa 10.1.1.100, da 10.2.0.3, sp
51510, dp 80, proto 6, tok 384

Note

The Internet Assigned Numbers Authority (IANA) has assigned numbers to all protocols. Here is a link to a list that IANA updates periodically: http://www.iana.org/assignments/protocol-numbers/.

Now that the 5-tuple lookup has been completed, a flow lookup is done. At this point, as shown by the output, the SRX determines if there is an existing session for this packet and whether it can take the fast path, or if this is a new session and it needs to go down the slow path. The example packet that is being broken down is, in fact, a first packet of a new session, and as such, the SRX determines that no existing session has been found and one must be created:

no session found, start first path. in_tunnel - 0, from_cp_flag - 0
  flow_first_create_session

The SRX then checks to see if there are any destination NAT configurations that apply. In this case, there are none, so no NAT is applied:

flow_first_in_dst_nat: in <ge-0/0/0.0>, out <N/A> dst_adr 10.2.0.3, sp 51510,
dp 80
  chose interface ge-0/0/0.0 as incoming nat if.
flow_first_rule_dst_xlate:  DST no-xlate: 0.0.0.0(0) to 10.2.0.3(80)

After the destination NAT has been looked up and applied, a route lookup can be done if one exists. The route lookup must take place after a destination NAT for routing purposes:

10.2.0.3, in ifp ge-0/0/0.0, out ifp N/A sp 51510, dp 80, ip_proto 6, tos 0
Doing DESTINATION addr route-lookup
  routed (x_dst_ip 10.2.0.3) from trust (ge-0/0/0.0 in 0) to ge-0/0/0.0,
Next-hop: 10.1.1.1

Once a route lookup is done on the destination, the SRX can determine the source and destination zones via a zone lookup. It then does a policy search to see if this traffic is denied/rejected/permitted or some other action, but in our case, it’s permitted:

policy search from zone trust-> zone web-dmz
  app 6, timeout 1800s, curr ageout 20s

If it had been denied by policy, a message such as this would have shown up, saying that the packet was denied and dropped:

packet dropped, denied by policy
packet dropped, policy deny.
flow find session returns error.
----- flow_process_pkt rc 0x7 (fp rc −1)

But that’s not the case, and now that the policy has been evaluated, the SRX checks to see if any source NAT configuration applies. In this case, there is no source NAT and everything returns false:

flow_first_src_xlate: 10.1.1.100/51510 -> 10.2.0.3/80 | 10.2.0.3/80 ->
0.0.0.0/51510: nat_src_xlated: False, nat_src_xlate_failed: False
flow_first_src_xlate: src nat 0.0.0.0(51510) to 10.2.0.3(80) returns status: 0,
rule/pool id: 0/0, pst_nat: False.
  dip id = 0/0, 10.1.1.100/51510->10.1.1.100/51510
flow_first_get_out_ifp: 1000 -> cone nat test

The SRX then determines the outgoing interface for this packet:

choose interface ge-0/0/0.0 as outgoing phy if
is_loop_pak: No loop: on ifp: ge-0/0/0.0, addr: 10.2.0.3, rtt_idx:0

Next, the SRX does some additional policy checks to see if items such as TCP proxy and WX apply:

policy is NULL (wx/pim scenario)
sm_flow_interest_check: app_id 0, policy 4, app_svc_en 0,
flags 0x2. not interested
sm_flow_interest_check: app_id 1, policy 4, app_svc_en 0,
flags 0x2. not interested
flow_first_service_lookup(): natp(0x4b9f2198): local_pak(0x3fdedc70.0x423f6a00):
TCP proxy NOT interested: 0.
  service lookup identified service 6.

In the preceding output, notice the policy number, policy 4. All security policies are assigned an index number. This index number is mainly for internal reference, but it can be viewed within the show security policies command, as shown in the following output, where you can see that policy 4 is a default-permit:

juniper@SRX5800> show security policies | match index
  Policy: default-permit, State: enabled, Index: 4, Sequence number: 1
  Policy: default-permit, State: enabled, Index: 5, Sequence number: 1
  Policy: protect_inside_users, State: enabled, Index: 6, Sequence number: 2
  Policy: webdmz_mgt, State: enabled, Index: 8, Sequence number: 1
  Policy: web_deny, State: enabled, Index: 9, Sequence number: 2
  Policy: default-deny, State: enabled, Index: 7, Sequence number: 1
  Policy: http-access, State: enabled, Index: 10, Sequence number: 1
  Policy: deny-all, State: enabled, Index: 11, Sequence number: 2

Back to our SRX output … the packet is sent out as the last checks are completed, as indicated here:

flow_first_final_check: in <ge-0/0/0.0>, out <ge-0/0/0.0>
  existing vector list 2-446fe828.
  Session (id:9270) created for first pak 2
  flow_first_install_session======> 0x4b9f2198
 nsp 0x4b9f2198, nsp2 0x4b9f2204
  make_nsp_ready_no_resolve()
  route lookup: dest-ip 10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-0/0/0.0
orig-zone 6 out-zone 6 vsd 0
  route to 10.1.1.100
Installing c2s NP session wing
Installing s2c NP session wing
  flow got session.
  flow session id 9270
  tcp flags 0x2, flag 0x2
  Got syn, 10.1.1.100(51510)->10.2.0.3(80), nspflag 0x1021, 0x20
mbuf 0x423f6a00, exit nh 0x30010
 ----- flow_process_pkt rc 0x0 (fp rc 0)

Although the output from traceoptions is a bit cryptic and hard to read, sometimes it’s much easier to understand if you look at it line by line, like we just did.

So, from the output in the tshoot_web file, it appears that traffic is going out the incorrect interface. From the preceding output, the route lookup is done and it appears that traffic is exiting the same interface on which it is entering. The ifp is the inbound interface and the output_ifp is the outbound interface.

route lookup: dest-ip 10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-0/0/0.0
orig-zone 6 out-zone 6 vsd 0

Look at the routing table to confirm that traffic is not exiting the proper interface:

juniper@SRX5800> show route 10.2.0.3
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0          *[Static/5] 6d 11:52:38
                    > to 10.1.1.1 via ge-0/0/0.0

The routing is incorrect. A quick static route should fix this problem and route traffic out the proper interface:

juniper@SRX5800> edit
[edit]
juniper@SRX5800> set routing-options static route 10.2.0.0/24 next-hop 10.2.1.1

Fix the problem and return to the show route command. Once a correct route is added, the traffic works for all users on the internal LAN:

juniper@SRX5800> show route 10.2.0.3
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.0.0/24     *[Static/5] 00:02:32
                    > 10.2.1.1 via fe-0/0/2.0

Turning Off Traceoptions

After you have completed any troubleshooting in your network, is it highly recommended that you turn off traceoptions. Unless there is a very good reason to leave them running, you should always disable them as soon as you have finished troubleshooting, as traceoptions can consume SRX resources, and depending on the amount of traffic being debugged, SRX performance could be impacted.

There are two ways to turn off traceoptions. The first method is to just deactivate the configuration. This leaves the traceoptions configuration in the SRX, but it is turned off until it is reactivated at a later date when troubleshooting has resumed.

To deactivate everything use the deactivate security flow traceoptions command. However, be careful when using the deactivate command, because much like the delete command, if you use it incorrectly, it can have a severe impact on the SRX.

 [edit]
juniper@SRX5800# deactivate security flow traceoptions

To confirm that the traceoptions have been disabled, just look at the configuration with the show command. Junos will tell you that this portion of the configuration is inactive:

juniper@SRX5800# show security flow traceoptions
##
## inactive: security flow traceoptions
##
file tshoot_web;
flag basic-datapath;
packet-filter trust_to_web {
    source-prefix 10.1.1.100/32;
    destination-prefix 10.2.0.3/32;
}
packet-filter web_to_trust {
    source-prefix 10.2.0.3/32;
    destination-prefix 10.1.1.100/32;
}

The second method to turn off traceoptions is to delete the traceoptions configuration. If the traceoptions configuration is no longer needed and troubleshooting has been completed, it’s wise to delete the configuration from the SRX.

To do this, use the delete command coupled with the security flow traceoptions configuration:

[edit]
juniper@SRX5800# delete security flow traceoptions

Now confirm that the traceoptions configuration is gone:

[edit]
juniper@SRX5800# show security flow traceoptions
[edit]
juniper@SRX5800#

The authors recommend that whenever you use the delete command you issue a show | compare before committing the configuration. This will display all changes to the configuration that are applied when a commit is done. It also ensures that no unintended configurations are made, or in this case, deleted:

juniper@SRX5800# show | compare
[edit security]
-   flow {
-       traceoptions {
-           file tshoot_web;
-           flag basic-datapath;
-           packet-filter trust_to_web {
-               source-prefix 10.1.1.100/32;
-               destination-prefix 10.2.0.3/32;
-           }
-           packet-filter web_to_trust {
-               source-prefix 10.2.0.3/32;
-               destination-prefix 10.1.1.100/32;
-           }
-       }
-   }
[edit]

As shown, only the traceoptions configuration has been deleted, so it’s safe to do a commit and exit configuration mode.

Note

To remove old troubleshooting logfiles, use the file delete <filename> command. It’s always a best practice to remove old, unused files when you no longer need them.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required