PrepAway - Latest Free Exam Questions & Answers

Category: JN0-694

Exam JN0-694: Enterprise Routing and Switching Support, Professional (JNCSP-ENT)

what is causing the 802.1X supplicant to fail?

— Exhibit —

user@switch>show dot1x interface ge-0/0/1 detail
ge-0/0/1.0
Role: Authenticator
Administrative state: Auto
Supplicant mode: Multiple
Number of retries: 3
Quiet perioD. 60 seconds
Transmit perioD. 30 seconds
Mac Radius: Enabled
Mac Radius Restrict: Enabled
Reauthentication: Disabled
Configured Reauthentication interval: 3600 seconds
Supplicant timeout: 30 seconds
Server timeout: 30 seconds
Maximum EAPOL requests: 2
Guest VLAN member:
Number of connected supplicants: 0
— Exhibit —

Refer to the Exhibit.
You are asked to troubleshoot an access control issue on your EX Series switch. The user

connecting through port ge-0/0/1 indicates that their 802.1X supplicant is failing authentication and
they are not able to connect to the network.
Referring to the exhibit, what is causing the 802.1X supplicant to fail?

What is causing the problem?

— 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 —

Refer to the Exhibit.
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?

what is causing this behavior?

— 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;
}
}
}
user@router# show firewall
filter MF {
term 1 {
from {
precedence 0;
}
then forwarding-class best-effort;
}
term 2 {
from {
precedence 5;
}
then forwarding-class expedited-forwarding;
}
term 3 {
from {
precedence 2;
}

then forwarding-class assured-forwarding;
}
term 4 {
from {
precedence 6;
}
then forwarding-class network-control;
}
term 5 {
then accept;
}
}
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 —

Refer to the Exhibit.
Traffic with the IPP value af21 should be assigned to the expedited forwarding queue; however,
this traffic is not being assigned to that queue.
Referring to the exhibit, what is causing this behavior?

what is the source of this problem?

— 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 —

Refer to the Exhibit.
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?

what is causing the problem?

— Exhibit —

user@R1> show class-of-service interface ge-0/0/0
Physical interface: ge-0/0/0, Index: 134
Queues supporteD. 8, Queues in use: 4
Scheduler map: , Index: 2
Congestion-notification: Disabled
Logical interface: ge-0/0/0.0, Index: 69
Object Name Type Index
Classifier ipprec-compatibility ip 13
— Exhibit —

Refer to the Exhibit.
You are sending traffic to the ge-0/0/0 interface on R1 with the expedited forwarding (101) IP
precedence bits. However, the counters on the router show that it is not processing any traffic in
the expedited forwarding queue.
Referring to the exhibit, what is causing the problem?


Page 4 of 6« First...23456