i think there is an issue with the "correct" answer.

It should be:

"no sequence 30" and then put this entry as sequence 5. 
Otherwise you put the same entry as sequence 5 as already set in sequence 30

How do you configure a different interface to send netflow records?  

The destination is on the same subnet as the mgmt interface (gig 0).

Gig 0 is isolated from other vrf's it is unlikely that other interfaces will be able to send traffic to 192.168.100.17.  This is a private ip address on the Mgmt-intf vrf.  

The more likely solution is to fix a connectivity problem between two devices on the same vrf and network segment.

IP addressing problem in diagram. Are both devices directly connected but in different subnets?


It is not the filename.
Switch is a tftp client, no need to configure it for server function.


Not sure about the other two.  
Adding a route in the switch won't help if there is no router.  I suppose you could specify an exit interface of e0/1 but then you would have to do the same in the server.

Using TFTP Server IP address 10.0.0.0.1?  THats the switch address but who knows the ip addressing in the exhibit seems wrong.

IF this is how the question is intended than an better explanation is warranted.

SNMPv3 is the only version that supports authentication.


ACL related problems would deny traffic.  You would not see an AUTHFAIL if the ACL was a problem.

the community strings are valid.

You cannot configure SNMP authentication on SNMPv2 and below

Only option to support authentication failures is to update to SNMP v3

same question and answers

Diagram has router a twice, no router b.

R3 show that gig 0/1 172.16.250.2 is up up. This is the interface to R2 gig 0/0
R3 shows 172.16.250.14 is connected to gig 0/2.  This address doen't exist on exhibit diagram.


Answer is correct.  question is misleading because configs are nor correct.

Routing table of R4 shows that R4 does not know about 192.168.1.0/30 or 192.168.2.0/24.

Traceroute shows that there is a routing problem between R1 and R2.
R1 knows how to get to R2. This is evident in R3's routing table which shows 172.16.0.0/16 via R1. This also proves that R1 and R2 are eigrp neighbors.

putting a static route on R4 wont fix the problem between R1 and R2.

Redistributing routes into EIGRP does not work without assigning a metric. The option to use a route map to set a metric does not work.  No where is the route map tied to eigrp.

The exhibit showing pings has wrong destinations.  Should be pinging 10.1.1.x not 10.1.2.x

Diagram shows Client on the 10.1.2.0/24 network.  but R2 fa 0/1 is configured for 10.1.1.1/24.  

This question is also a bad example of summarization.  R2 sees 10.1.1.0/24 as directly connected and connects to 10.1.2.0/24 using the summary router 10.0.0.0/8.  R1 performs the same.  

I am not sure what the problem is here but it is not caused by auto-summarization. Full network connectivity exists with the current configuration.

PC1> trace 10.1.2.10
trace to 10.1.2.10, 8 hops max, press Ctrl+C to stop
1  10.1.1.1  0.260 ms  0.107 ms  0.140 ms
2  192.168.1.1  0.365 ms  0.299 ms  0.376 ms
3  *10.1.2.10  0.427 ms (ICMP type:3, code:3, Destination port unreachable)

PC1>


R1#show ip route 10.0.0.0
Routing entry for 10.0.0.0/8, 4 known subnets
  Attached (2 connections)
  Variably subnetted with 3 masks
  Redistributing via eigrp 10
D        10.0.0.0/8 is a summary, 00:06:23, Null0
C        10.1.1.0/24 is directly connected, Ethernet0/1
L        10.1.1.1/32 is directly connected, Ethernet0/1
D        10.1.2.0/24 [90/307200] via 192.168.1.1, 00:05:29, Ethernet0/0
R1#

1. you cant really configgure SSH service on a cisco device. You can configure SSH, you can allow it on the VTY Lines.  You can force it to user v1 or v2 but there is no command to configure it as a service.  If SSH was misconfigured you would not get a prompt for a password.


2. If Transport input SSH/ALL is not configured on the line, you will get connection refused.  Not a prompt for a password.

user@user-pc:~$ ssh admin@198.51.100.64
ssh: connect to host 198.51.100.64 port 22: Connection refused


3. If telnet was requiring local database with username/password for authenticaiton, it would prompt for a user name.

user@user-pc:~$ telnet 198.51.100.64
Trying 198.51.100.64
Connected to 198.51.100.64.
Escape character is '^]'.


User Access Verification

Username: admin
Password:
R1>


4. If the vty lines are not configured for local authentication, telnet will work because of the following config

line vty 0 4
login
password admin

SSH attempts will experience an authentication failure without login local configured on the vty lines.