PrepAway - Latest Free Exam Questions & Answers

Category: JN0-696 (v.2)

Exam JN0-696: Security Support, Professional (JNCSP-SEC) (update December 13th, 2015)

Which action will resolve this problem?

You recently configured the antivirus feature profile on your Junos device. The security
policy is sending traffic for antivirus scanning. However, the traffic is being blocked and you
repeatedly receive the system log message that the scan engine is not ready. You must not
allow the traffic to be dropped when the scan engine is not ready. Which action will resolve
this problem?

What is the problem?

In preparation for future expansion, a user decides to configure a stand-alone SRX Series
device for chassis-clustering mode. The user enters the command set chassis cluster
cluster-id 0 node 0 reboot on the device. After the device reboots, the user sees this output:
user@host> show chassis cluster status error: Chassis cluster is not enabled. user@host>
The device does not enter chassis-clustering mode. What is the problem?

which configuration change on SRX- 1 would resolve this problem?

Click the Exhibit button. You are troubleshooting a communication problem between a trust
zone and an untrust zone in the network, where PC-1 cannot ping PC-2. Referring to the
exhibit, which configuration change on SRX- 1 would resolve this problem? Add a security
policy to allow ICMP traffic from the untrust zone to the trust zone.

what is causing this behavior?

user@host> show security flow session interface ge-0/0/10.0 Session ID. 29, Policy name:
to-infrastructure/4, Timeout: 1250, Valid Resource information : FTP ALG, 1, 0 In:
10.1.1.213/61892 –> 10.2.2.20/21;tcp, If: ge-0/0/8.0, Pkts: 25, Bytes: 1242 Out:
10.2.2.20/21 –> 10.1.1.213/61892;tcp, If: ge-0/0/10.0, Pkts: 18, Bytes: 1278 Total sessions:
1 user@host> show interfaces ge-0/0/10 | match zone Security: Zone: infrastructure
user@host> show interfaces ge-0/0/8 | match zone Security: Zone: finance user@host>
show configuration security policies from-zone infrastructure to-zone finance user@host>
show log flow-traceoptions Jun 13 14:44:01 14:44:01.059151:CID-0:RT:SPU received an
event,type 112, common:3 Jun 13 14:44:01 14:44:01.059151:CID-0:RT:Rcv packet with rtbl
idx 0, cos 0 Jun 13 14:44:01 14:44:01.059151:CID-0:RT:SPU processing spu_flushed_pak,
flag: 0x2, mbuf:0x423f6100 Jun 13 14:44:01
14:44:01.060343:CID-0:RT:10.2.2.20/20->10.1.1.213/64313;6> matched filter filter2: Jun 13
14:44:01 14:44:01.060473:CID-0:RT:packet [64] ipid = 1614, @423fd19c Jun 13 14:44:01
14:44:01.060473:CID-0:RT:—- flow_process_pkt: (thd 3): flow_ctxt type 15, common flag
0x0, mbuf 0x423fcf80, rtbl_idx = 0 Jun 13 14:44:01 14:44:01.060473:CID-0:RT: flow
process pak fast ifl 71 in_ifp ge-0/0/10.0 Jun 13 14:44:01 14:44:01.060473:CID-0:RT:
ge-0/0/10.0:10.2.2.20/20->10.1.1.213/64313, tcp, flag 2 syn Jun 13 14:44:01
14:44:01.060473:CID-0:RT: find flow: table 0x49175b08, hash 34391(0xffff), sa 10.2.2.20,
da 10.1.1.213, sp 20, dp 64313, proto 6, tok 8 Jun 13 14:44:01 14:44:01.060473:CID-0:RT:
no session found, start first path. in_tunnel – 0, from_cp_flag – 0 Jun 13 14:44:01
14:44:01.060473:CID-0:RT: flow_first_create_session Jun 13 14:44:01
14:44:01.060473:CID-0:RT:-jsf : preset sess plugin info for session 31 Jun 13 14:44:01
14:44:01.060473:CID-0:RT: Allocating plugin info block for plugin(21) Jun 13 14:44:01
14:44:01.060473:CID-0:RT:[JSF] set ext handle 0x46389be8 for plugin 21 on session 31
Jun 13 14:44:01 14:44:01.060473:CID-0:RT:asl_usp_get_l3_out_ifp_out_tunnel ASL IPV4
out_ifp = ge-0/0/8.0 for dst:10.1.1.213 in vr_id:0 Jun 13 14:44:01
14:44:01.060473:CID-0:RT:SPU invalid session id 00000000 Jun 13 14:44:01
14:44:01.060473:CID-0:RT: jsf drop pak pid 21, jbuf 0x4fcd7038, release hold 0, sess_id 0

Jun 13 14:44:01 14:44:01.060761:CID-0:RT: After jsf gate hit. sid 0xfb39, pid 0, cookie 0x1f,
jbuf 0x15. rc = 1 Jun 13 14:44:01 14:44:01.060761:CID-0:RT:RM populated xlate info for
nsp2: 10.1.1.213/64313- >10.2.2.20/20out_ifp = ge-0/0/8.0, out_tunnel = 0x0 Jun 13
14:44:01 14:44:01.060761:CID-0:RT: flow_first_in_dst_nat: in 0/10.0>, out 0/8.0> dst_adr
10.1.1.213, sp 20, dp 64313 Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_in_dst_nat: bypassed by RM Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_rule_dst_xlate: bypassed by RM Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_routing: bypassed by RM Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_policy_search: bypassed by RM Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_reverse_mip: bypassed by RM Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_src_xlate: bypassed by RM Jun 13 14:44:01 14:44:01.060761:CID-0:RT:
flow_first_get_out_ifp: bypassed by RM Jun 13 14:44:01
14:44:01.060761:CID-0:RT:is_loop_pak: No loop: on ifp: ge-0/0/8.0, addr: 10.1.1.213,
rtt_idx:0 Jun 13 14:44:01 14:44:01.060761:CID-0:RT:[JSF]Normal interest check. regd
plugins 18, enabled impl mask 0x0 Jun 13 14:44:01 14:44:01.060761:CID-0:RT:-jsf int
check: plugin id 2, svc_req 0x0, impl mask 0x0. rc 4 Jun 13 14:44:01
14:44:01.060761:CID-0:RT:-jsf int check: plugin id 3, svc_req 0x0, impl mask 0x0. rc 4 Jun
13 14:44:01 14:44:01.060761:CID-0:RT:-jsf int check: plugin id 5, svc_req 0x0, impl mask
0x0. rc 4 Jun 13 14:44:01 14:44:01.060761:CID-0:RT:-jsf int check: plugin id 6, svc_req 0x0,
impl mask 0x0. rc 4 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:-jsf int check: plugin id 7,
svc_req 0x0, impl mask 0x0. rc 4 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:-jsf int check:
plugin id 8, svc_req 0x0, impl mask 0x0. rc 4 Jun 13 14:44:01
14:44:01.060975:CID-0:RT:-jsf int check: plugin id 14, svc_req 0x0, impl mask 0x0. rc 4 Jun
13 14:44:01 14:44:01.060975:CID-0:RT:+++++++++++jsf_test_plugin_data_evh: 3 Jun 13
14:44:01 14:44:01.060975:CID-0:RT:-jsf int check: plugin id 15, svc_req 0x0, impl mask
0x0. rc 4 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:-jsf int check: plugin id 21, svc_req
0x0, impl mask 0x0. rc 3 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:-jsf int check: plugin id
22, svc_req 0x0, impl mask 0x0. rc 4 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:-jsf int
check: plugin id 25, svc_req 0x0, impl mask 0x0. rc 4 Jun 13 14:44:01
14:44:01.060975:CID-0:RT:-jsf int check: plugin id 26, svc_req 0x0, impl mask 0x0. rc 2 Jun
13 14:44:01 14:44:01.060975:CID-0:RT:-jsf int check: plugin id 27, svc_req 0x0, impl mask
0x0. rc 4 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:[JSF]Plugins(0x0, count 0) enabled
for session = 4294967296, impli mask(0x0), post_nat cnt 31 svc req(0x0) Jun 13 14:44:01

14:44:01.060975:CID-0:RT:[JSF]c2s order list: Jun 13 14:44:01 14:44:01.060975:CID-0:RT:
21 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:[JSF]s2c order list: Jun 13 14:44:01
14:44:01.060975:CID-0:RT: 21 Jun 13 14:44:01 14:44:01.060975:CID-0:RT: service lookup
identified service 79. Jun 13 14:44:01 14:44:01.060975:CID-0:RT: flow_first_final_check: in
0/10.0>, out 0/8.0> Jun 13 14:44:01
14:44:01.060975:CID-0:RT:flow_first_complete_session, pak_ptr: 0x48ae5ba0, nsp:
0x4c38e248, in_tunnel: 0x0 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:construct v4 vector
for nsp2 Jun 13 14:44:01 14:44:01.060975:CID-0:RT: existing vector list 82-454e5c90. Jun
13 14:44:01 14:44:01.060975:CID-0:RT: Session (id:31) created for first pak 82 Jun 13
14:44:01 14:44:01.060975:CID-0:RT: flow_first_install_session======> 0x4c38e248 Jun
13 14:44:01 14:44:01.060975:CID-0:RT: nsp 0x4c38e248, nsp2 0x4c38e2c8 Jun 13
14:44:01 14:44:01.060975:CID-0:RT: make_nsp_ready_no_resolve() Jun 13 14:44:01
14:44:01.060975:CID-0:RT: route lookup: dest-ip 10.2.2.20 orig ifp ge-0/0/10.0 output_ifp
ge-0/0/10.0 orig-zone 8 out-zone 8 vsd 0 Jun 13 14:44:01 14:44:01.060975:CID-0:RT: route
to 10.2.2.20 Jun 13 14:44:01 14:44:01.060975:CID-0:RT:Doing jsf sess create notify Jun 13
14:44:01 14:44:01.060975:CID-0:RT:flow_delete_gate: invoked for gate 0x4c077c24 [id
1000003] Jun 13 14:44:01 14:44:01.060975:CID-0:RT:gate_start_ageout: ageout started for
gate 0x4c077c24 Jun 13 14:44:01 14:44:01.060975:CID-0:RT: jsf sess id ignore. sess 31,
pid 21, dir 1, st_buf 0x0. Jun 13 14:44:01 14:44:01.060975:CID-0:RT: jsf sess id ignore.
sess 31, pid 21, dir 2, st_buf 0x0. Jun 13 14:44:01 14:44:01.060975:CID-0:RT:All plugins
have ignored session :31 Jun 13 14:44:01 14:44:01.060975:CID-0:RT: existing vector list
2-454ecbd0. Jun 13 14:44:01 14:44:01.060975:CID-0:RT: existing vector list 2-454ecbd0.
Jun 13 14:44:01 14:44:01.060975:CID-0:RT:-jsf create notify: plugin id 21. rc 3 Jun 13
14:44:01 14:44:01.060975:CID-0:RT:flow_do_jsf_notify_session_creation():
natp(0x4c38e248): 0 SHORT_CIRCUITED. 0x00000000. Jun 13 14:44:01
14:44:01.060975:CID-0:RT:no need update ha Jun 13 14:44:01
14:44:01.060975:CID-0:RT:Installing c2s NP session wing Jun 13 14:44:01
14:44:01.060975:CID-0:RT:Installing s2c NP session wing Jun 13 14:44:01
14:44:01.061475:CID-0:RT: flow got session. Jun 13 14:44:01 14:44:01.061475:CID-0:RT:
flow session id 31 Jun 13 14:44:01 14:44:01.061475:CID-0:RT: vector bits 0x2 vector
0x454ecbd0 Jun 13 14:44:01 14:44:01.061475:CID-0:RT: tcp flags 0x2, flag 0x2 Jun 13
14:44:01 14:44:01.061475:CID-0:RT: Got syn, 10.2.2.20(20)->10.1.1.213(64313), nspflag
0x1021, 0x20 Jun 13 14:44:01 14:44:01.061475:CID-0:RT:mbuf 0x423fcf80, exit nh

0xa0010 Jun 13 14:44:01 14:44:01.061475:CID-0:RT: —– flow_process_pkt rc 0x0 (fp rc 0)
While troubleshooting a device, you see that it is permitting packets for which it appears
there is no policy. Using the information in the exhibit, what is causing this behavior?

why is the device denying the traffic?

user@host> show configuration security policies from-zone engineering to-zone hr policy
new-policy { match { source-address any; destination-address server1; application
hr-data-feed; } then { permit; } } policy old-policy { match { source-address pc1;
destination-address server1; application any; } then { deny; log { session-init; } } }
user@host> show configuration security policies global user@host> show configuration
security address-book | match server1 | display set set security address-book book2
address server1 172.19.55.20/32 set security address-book book3 address server1
172.20.11.18/32 user@host> show configuration security address-book | match pc1 |
display set set security address-book book1 address pc1 172.18.21.213/32 user@host>
show configuration applications application hr-data-feed { protocol tcp; destination-port
38888; } user@host> run show log flow-traceoptions | no-more Jun 13 15:54:09 host
clear-log[2503]: logfile cleared Jun 13 15:54:10
15:54:10.611915:CID-0:RT:172.18.21.213/38362->172.19.55.20/38888;17> matched filter
filter1: Jun 13 15:54:10 15:54:10.611915:CID-0:RT:packet [40] ipid = 38364, @423e421c
Jun 13 15:54:10 15:54:10.611915:CID-0:RT:—- flow_process_pkt: (thd 3): flow_ctxt type

15, common flag 0x0, mbuf 0x423e4000, rtbl_idx = 0 Jun 13 15:54:10
15:54:10.611915:CID-0:RT: flow process pak fast ifl 70 in_ifp ge-0/0/8.0 Jun 13 15:54:10
15:54:10.611915:CID-0:RT: find flow: table 0x49175b08, hash 9077(0xffff), sa
172.18.21.213, da 172.19.55.20, sp 38362, dp 38888, proto 17, tok 10 Jun 13 15:54:10
15:54:10.611915:CID-0:RT: flow_first_create_session Jun 13 15:54:10
15:54:10.611915:CID-0:RT: flow_first_in_dst_nat: in 0/8.0>, out A> dst_adr 172.19.55.20,
sp 38362, dp 38888 Jun 13 15:54:10 15:54:10.611915:CID-0:RT: chose interface ge-0/0/8.0
as incoming nat if. Jun 13 15:54:10 15:54:10.611915:CID-0:RT:flow_first_rule_dst_xlate:
DST no-xlate: 0.0.0.0(0) to 172.19.55.20(38888) Jun 13 15:54:10
15:54:10.611915:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip
172.18.21.213, x_dst_ip 172.19.55.20, in ifp ge-0/0/8.0, out ifp N/A sp 38362, dp 38888,
ip_proto 17, tos 0 Jun 13 15:54:10 15:54:10.611915:CID-0:RT:Doing DESTINATION addr
route-lookup Jun 13 15:54:10 15:54:10.611915:CID-0:RT: routed (x_dst_ip 172.19.55.20)
from engineering (ge-0/0/8.0 in 0) to ge-0/0/10.0, Next-hop: 172.19.55.20 Jun 13 15:54:10
15:54:10.611915:CID-0:RT:flow_first_policy_search: policy search from zone engineering->
zone hr (0x0,0x95da97e8,0x97e8) Jun 13 15:54:10 15:54:10.611915:CID-0:RT: app 0,
timeout 60s, curr ageout 60s Jun 13 15:54:10 15:54:10.611915:CID-0:RT: Error : get sess
plugin info 0x4c390388 Jun 13 15:54:10 15:54:10.611915:CID-0:RT: Error : get sess plugin
info 0x4c390388 Jun 13 15:54:10 15:54:10.612416:CID-0:RT: packet dropped, denied by
policy Jun 13 15:54:10 15:54:10.612416:CID-0:RT: denied by policy old-policy(6), dropping
pkt Jun 13 15:54:10 15:54:10.612416:CID-0:RT: packet dropped, policy deny. Jun 13
15:54:10 15:54:10.612416:CID-0:RT: flow didn’t create session, code=-1. Jun 13 15:54:10
15:54:10.612416:CID-0:RT: —– flow_process_pkt rc 0x7 (fp rc -1) A user added the
new-policy policy to permit traffic. However, they report that the traffic is still not permitted
by the device. Using the information in the exhibit, why is the device denying the traffic?

what will resolve this problem?

user@host> show security flow session … Session ID. 41, Policy name: allow/5, Timeout:
20, Valid In: 172.168.66.143/43886 –> 192.168.100.1/5000;tcp, If: ge-0/0/1.0, Pkts: 1,
Bytes: 60 Out: 10.100.1.100/5555 –> 172.168.66.143/43886;tcp, If: ge-0/0/2.0, Pkts: 0,
Bytes: 0 user@host> show configuration … security { nat { destination { pool server {
address 10.100.1.100/32 port 5555; } rule-set rule1 { from zone UNTRUST; rule 1 { match {
destination-address 192.168.100.1/32; destination-port 5000; } then { destination-nat pool
server; } } } } proxy-arp { interface ge-0/0/1.0 { address { 192.168.100.1/32; } } } } policies {
from-zone UNTRUST to-zone TRUST { policy allow { match { source-address any;
destination-address any; application [ junos-ping tcp-5000 ]; } then { permit; } } } } zones {
security-zone TRUST { interfaces { ge-0/0/2.0 { host-inbound-traffic { protocols { all; } } } } }
security-zone UNTRUST { interfaces { ge-0/0/1.0 { host-inbound-traffic { system-services {
ping; } } } } } } } applications { application tcp-5000 { protocol tcp; destination-port 5000; } }
Your customer is attempting to reach your new server that should be accessible publicly
using 192.168.100.100 on TCP port 5000, and internally using 10.100.100.1 on TCP port
5555. You notice a session forms when they attempt to access the server, but they are
unable to reach the server. Referring to the exhibit, what will resolve this problem?

what is causing the problem?

user@host> show log ibgp-trace … Jun 12 10:21:08
10:21:08.367627:CID-0:RT:192.168.2.1/49170->192.168.1.1/179;6> matched filter
ibgp-traffic: Jun 12 10:21:08 10:21:08.367747:CID-0:RT:packet [64] ipid = 11792,
@423f741c Jun 12 10:21:08 10:21:08.367747:CID-0:RT:—- flow_process_pkt: (thd 2):
flow_ctxt type 15, common flag 0x0, mbuf 0x423f7200, rtbl_idx = 0 Jun 12 10:21:08
10:21:08.367747:CID-0:RT: flow process pak fast ifl 71 in_ifp ge-0/0/3.0 Jun 12 10:21:08
10:21:08.367747:CID-0:RT: ge-0/0/3.0:192.168.2.1/49170->192.168.1.1/179, tcp, flag 2 syn
Jun 12 10:21:08 10:21:08.367747:CID-0:RT: find flow: table 0x4f161150, hash
15898(0xffff), sa 192.168.2.1, da 192.168.1.1, sp 49170, dp 179, proto 6, tok 7 Jun 12
10:21:08 10:21:08.367747:CID-0:RT: no session found, start first path. in_tunnel – 0,
from_cp_flag – 0 Jun 12 10:21:08 10:21:08.367747:CID-0:RT: flow_first_create_session Jun
12 10:21:08 10:21:08.367747:CID-0:RT:Doing DESTINATION addr route-lookup Jun 12
10:21:08 10:21:08.367747:CID-0:RT: routed (x_dst_ip 192.168.1.1) from trust (ge-0/0/3.0 in
0) to lo0.0, Next-hop: 92.168.1.1 Jun 12 10:21:08
10:21:08.367747:CID-0:RT:flow_first_policy_search: policy search from zone trust-> zone
loopback-zone (0x0,0xc01200b3,0xb3) Jun 12 10:21:08 10:21:08.367747:CID-0:RT: policy
has timeout 900 Jun 12 10:21:08 10:21:08.367747:CID-0:RT: app 0, timeout 1800s, curr
ageout 20s Jun 12 10:21:08 10:21:08.367747:CID-0:RT: permitted by policy allow-bgp(8)
Jun 12 10:21:08 10:21:08.368250:CID-0:RT: flow_first_install_session======>
0x5394a110 Jun 12 10:21:08 10:21:08.368250:CID-0:RT:flow_first_service_lookup():
natp(0x5394a110): app_id, 0(0). Jun 12 10:21:08 10:21:08.368250:CID-0:RT: service
lookup identified service 0. Jun 12 10:21:08 10:21:08.368250:CID-0:RT:
flow_first_final_check: in 0/3.0>, out Jun 12 10:21:08 10:21:08.368250:CID-0:RT: existing
vector list 2-49c75930. Jun 12 10:21:08 10:21:08.368250:CID-0:RT: Session (id:137)
created for first pak 2 Jun 12 10:21:08 10:21:08.368250:CID-0:RT: post addr xlation:
192.168.2.1->192.168.1.1. Jun 12 10:21:08 10:21:08.368250:CID-0:RT:check self-traffic on
lo0.0, in_tunnel 0x0 Jun 12 10:21:08 10:21:08.368250:CID-0:RT:retcode: 0xa01 Jun 12
10:21:08 10:21:08.368250:CID-0:RT:pak_for_self : proto 6, dst port 179, action 0x0 Jun 12

10:21:08 10:21:08.368250:CID-0:RT: flow_first_create_session Jun 12 10:21:08
10:21:08.368250:CID-0:RT: flow_first_in_dst_nat: in , out A> dst_adr 192.168.1.1, sp
49170, dp 179 Jun 12 10:21:08 10:21:08.368752:CID-0:RT: chose interface lo0.0 as
incoming nat if. Jun 12 10:21:08 10:21:08.368752:CID-0:RT: packet droppeD. for self but
not interested Jun 12 10:21:08 10:21:08.368752:CID-0:RT: packet dropped, packet
droppeD. for self but not interested. Jun 12 10:21:08 10:21:08.368752:CID-0:RT: flow find
session returns error. Jun 12 10:21:08 10:21:08.368752:CID-0:RT: —– flow_process_pkt rc
0x7 (fp rc -1) You are asked to troubleshoot a new IBGP peering problem on your SRX
Series device. The IBGP peering is not establishing. Referring to the outputs in the exhibit,
what is causing the problem?

what will resolve this problem?

user@host> show configuration … security { nat { destination { pool server { address
10.100.100.1/32 port 5555; } rule-set rule1 { from zone UNTRUST; rule 1 { match {
destination-address 192.168.100.1/32; destination-port 5000; } then { destination-nat pool
server; } } } } proxy-arp { interface ge-0/0/1.0 { address { 192.168.100.1/32; } } } } policies {
from-zone UNTRUST to-zone TRUST { policy allow { match { source-address any;
destination-address any; application [ junos-ping tcp-5000 ]; } then { permit; } } } } zones {
security-zone TRUST { interfaces { ge-0/0/2.0 { host-inbound-traffic { protocols { all; } } } } }
security-zone UNTRUST { interfaces { ge-0/0/1.0 { host-inbound-traffic { system-services {

ping; } } } } } } } applications { application tcp-5000 { protocol tcp; destination-port 5000; } }
Your customer is attempting to reach a new server that should be accessible publicly using
192.168.100.100 on TCP port 5000, and internally using 10.100.100.1 on TCP port 5555.
You notice no sessions form when the customer attempts to access the server. Referring to
the exhibit, what will resolve this problem?


Page 2 of 41234