PrepAway - Latest Free Exam Questions & Answers

Category: JN0-694 (v.1)

Exam JN0-694: Enterprise Routing and Switching Support, Professional (JNCSP-ENT) (update March 15th, 2015)

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 —
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 —
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 above. 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 —
Traffic with the IPP value af21 should be assigned to the expedited forwarding queue; however, this
traffic is not being assigned to that queue. 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 —
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. 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 —
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. What is causing the problem?


Page 4 of 41234