Juniper Enterprise Routing and Switching Support, Professional (JNCSP-ENT) - JN0-694 Exam Practice Test

-- Exhibit --
{master:0}[edit ethernet-switching-options secure-access-port]
user@switch# show
interface ge-0/0/1.0 {
static-ip 172.27.0.2 vlan v11 mac 00:0c:29:b5:89:7c;
no-dhcp-trusted;
}
vlan v11 {
arp-inspection;
}
interface ge-0/0/2.0 {
dhcp-trusted;
}
user@switch> show log messages | match arp
Feb 8 14:31:45 switch eswd[1280]: ESWD_DAI_FAILED. 3 ARP_REQUEST received, interface ge-0/0/1.0[index 73], vlan v11[index 5], sender ip/mac 172.27.0.2/00:0c:29:b5:89:7d, receiver ip/mac 172.27.0.1/00:00:00:00:00:00
Feb 8 14:34:05 switch eswd[1280]: ESWD_DAI_FAILED. 3 ARP_REQUEST received, interface ge-0/0/1.0[index 73], vlan v11[index 5], sender ip/mac 172.27.0.2/00:0c:29:b5:89:7d, receiver ip/mac 172.27.0.1/00:00:00:00:00:00
Feb 8 14:36:05 switch eswd[1280]: ESWD_DAI_FAILED. 3 ARP_REQUEST received, interface ge-0/0/1.0[index 73], vlan v11[index 5], sender ip/mac 172.27.0.2/00:0c:29:b5:89:7d, receiver ip/mac 172.27.0.1/00:00:00:00:00:00
-- Exhibit -
Click the Exhibit button.
You have been asked to troubleshoot a problem where a user is not able to send traffic through your switch. While troubleshooting, you see the log messages shown in the exhibit.
What is causing the problem?

An end user on interface ge-0/0/1.0 is trying to receive a multicast stream for 232.0.0.1 sourced from but is not receiving it. You use the show igmp group command and do not see this group in the list. You enable traceoptions for IGMP and find the following IGMPv3 report from the end user's host:
Jun 10 13:11:03.577641 RCV IGMP V3 Report len 16 from 192.168.1.13 intf ge-0/0/1.0
Jun 10 13:11:03.577984 Records 1
Jun 10 13:11:03.578027 Group 232.0.0.1, type IS_EX, aux_len 0, sources 0
Which configuration change is required to allow the group to be added in the router?

-- Exhibit -user@router# show class-of-service
classifiers {
inet-precedence ipp-test {
import default;
forwarding-class best-effort {
loss-priority low code-points be;
}
forwarding-class expedited-forwarding {
loss-priority low code-points af21;
}
forwarding-class assured-forwarding {
loss-priority low code-points af11;
}
forwarding-class network-control {
loss-priority low code-points nc1;
}
}
}
interfaces {
ge-* {
scheduler-map map-test;
unit * {
classifiers {
inet-precedence ipp-test;
}
rewrite-rules {
inet-precedence ipp-rw-test;
inet-precedence default;
}
}
}
}
...
rewrite-rules {
inet-precedence ipp-rw-test {
forwarding-class best-effort {
loss-priority low code-point be;
loss-priority high code-point af21;
}
forwarding-class expedited-forwarding {
loss-priority high code-point af21;
loss-priority low code-point be;
}
forwarding-class assured-forwarding {
loss-priority low code-point af11;
loss-priority high code-point af11;
}
forwarding-class network-control {
loss-priority low code-point nc1;
loss-priority high code-point nc1;
}
}
}
user@router> show class-of-service ... Code point type: inet-precedence Alias Bit pattern af11 001 af21 010 af31 011 af41 100 be 000 cs6 110 cs7 111 ef 101 nc1 110 nc2 111 -- Exhibit -
Click the Exhibit button.
Traffic with the IP precedence value af21 ingresses the router and should be rewritten with the same value as it egresses; however, this traffic is rewritten to a different value.
Referring to the exhibit, what is the source of this problem?

-- Exhibit - -- Exhibit -

Click the Exhibit button.
On R1, the interface fe-0/0/1 is assigned to the default routing instance and fe-0/0/2 is assigned to a virtual router instance named VR-1.
Referring to the exhibit, the static route 200.200.200.200/32 is missing from the routing table of the default routing instance.
What should you do on R1 to resolve this problem?

There is a lot of traffic marked with IP precedence values af2l and af3l that ingresses the router. The af3l traffic should be using the expedited forwarding queue, but the traffic is much lower than expected and there are no drops seen on the egress interface. Referring to the exhibit, what is causing the problem?

You are troubleshooting a problem where external routes are not being summarized into the OSPF backbone.

Referring to the exhibit, what needs to be done to resolve this problem?