Show Command Output Questions

CRC errors are always caused by a faulty switch port and require port replacement.

Why wrong: CRC errors are usually caused by cabling issues or electromagnetic interference, not necessarily a faulty port.

Giants are frames that exceed the maximum transmission unit (MTU) and are always discarded by the switch.

Why wrong: Giants are frames larger than the maximum allowed size, but some switches may forward them if configured for jumbo frames; they are not always discarded.

The 'show controllers' command provides a detailed view of CRC errors but does not show runts or giants.

Why wrong: 'show controllers' displays hardware-level details including CRC errors, but it can also show runts, giants, and other frame errors depending on the platform.

Authentication mismatch between R2 and 3.3.3.3

Why wrong: A mismatch would stop the neighbor relationship from reaching 2WAY in the first place.

R2 must be configured as a point-to-point network type

Why wrong: That is not required here and would change behavior rather than explain the current normal state.

R2 has a duplicate router ID

Why wrong: A duplicate router ID causes other issues and is not what this output indicates.

Enter interface configuration mode and issue the 'speed 100' command to match the remote interface speed.

Why wrong: This is incorrect because the interface is administratively down, not a speed mismatch. Speed mismatches typically cause CRC errors or interface resets, not an administratively down state.

Enter interface configuration mode and issue the 'duplex full' command to force full-duplex operation.

Why wrong: This is incorrect because the interface is administratively down, not a duplex mismatch. Duplex mismatches typically cause high error rates and collisions, not an administratively down state.

Enter interface configuration mode and issue the 'no keepalive' command to disable keepalives.

Why wrong: This is incorrect because keepalive issues typically cause 'line protocol is down' while the interface remains up, not 'administratively down'. The output shows the interface is administratively down, which is a manual shutdown.

The EtherChannel will form successfully because LACP active mode negotiates the channel regardless of speed/duplex or VLAN differences.

Why wrong: This is incorrect because LACP does not override speed/duplex or VLAN mismatches; these must match on all member interfaces for the channel to form.

The EtherChannel will not form because the port-channel interface must be configured with the same VLAN as the physical interfaces, but the physical interfaces can have different speeds.

Why wrong: This is incorrect because speed must match on all physical interfaces; different speeds prevent the channel from forming.

The EtherChannel will form successfully because the port-channel interface inherits the VLAN from the first physical interface added, so no additional configuration is needed.

Why wrong: This is incorrect because the port-channel interface does not automatically inherit VLAN settings; it must be explicitly configured, and all physical interfaces must have matching VLANs.

The default gateway is configured incorrectly on the host.

Why wrong: The host is sending ICMP requests to 192.168.10.1, which is the correct default gateway, and the switch replies, so the gateway is reachable.

An ACL is applied to the SVI blocking ICMP.

Why wrong: The capture shows ICMP replies from 192.168.10.1, so no ACL is blocking ICMP traffic.

The SVI is administratively down.

Why wrong: The SVI shows 'no shutdown' and is replying to pings, so it is administratively up.

snmp-server community NetOpsRO ro snmp-server user AdminUser v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow export EXPORTER

Why wrong: This is incorrect because the SNMPv3 user is created without a group, which is required for authentication and privacy privileges. Also, 'ip flow export' is not a valid interface command; the correct command is 'ip flow monitor' referencing a flow monitor that uses the exporter.

snmp-server community NetOpsRO ro snmp-server group AdminGroup v3 priv snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 version 2c TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input

Why wrong: This is incorrect because the 'snmp-server host' command includes 'version 2c', which forces traps to be sent using SNMPv2c with the community string. However, the trap community 'TrapComm' is specified, but the command syntax is correct; the error is that the trap destination should not specify version 2c if the community is intended for v2c traps, but the question does not specify version, so it's acceptable. Actually, the main error is missing the flow exporter reference in the flow monitor; the flow monitor must be configured with the exporter. The given config does not show the flow monitor configuration.

snmp-server community NetOpsRO ro snmp-server group AdminGroup v3 priv snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2 snmp-server enable traps snmp-server host 192.0.2.10 TrapComm flow exporter EXPORTER destination 192.0.2.20 version 9 ! interface GigabitEthernet0/0 ip flow monitor FLOW-MONITOR input flow monitor FLOW-MONITOR exporter EXPORTER

Why wrong: This is incorrect because the flow monitor configuration is placed after the interface command, which is out of order. The flow monitor must be configured before it is applied to the interface. Additionally, the 'flow monitor' command should be in global configuration mode, not after the interface command.

The routers are in different OSPF areas.

Why wrong: This would be a valid reason if one router were in area 0 and the other were in another area. In the exhibit, both routers place the same subnet into area 0, so the area setting is not the issue. The failure occurs at the interface parameter level instead.

The subnet mask prevents multicast OSPF packets from being exchanged.

Why wrong: The subnet mask shown is a normal /24 LAN mask and does not stop OSPF multicast traffic. OSPF commonly uses multicast on broadcast segments without any problem in that mask size. The real incompatibility is the timer mismatch, not the mask.

The OSPF process IDs do not match on the two routers.

Why wrong: This sounds believable because many learners assume OSPF process IDs must match between neighbors. In reality, the process ID is locally significant and is not exchanged as a neighbor-forming parameter. Two routers can still become neighbors with different local process numbers if the real link parameters match.

Because static routes cannot reference exit interfaces.

Why wrong: This is wrong because static routes can be configured with outgoing interfaces.

Because the destination must be a /24, not a /16.

Why wrong: This is wrong because the issue shown is interface state, not the destination mask.

Because static routes require NTP before installation.

Why wrong: This is wrong because time synchronization is unrelated to static-route installation.

snmp-server community public snmp-server community private snmp-server user admin v3 auth md5 Cisco123 priv des56 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9

Why wrong: This configuration is incorrect because it uses MD5 instead of SHA for SNMPv3 authentication and DES instead of AES 128 for encryption. Additionally, the community strings lack the RO and RW keywords, which are required to specify access levels.

snmp-server community public RO snmp-server community private RW snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c private snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 9

Why wrong: This configuration incorrectly uses the private community string for the v2c trap host. The v2c trap host should use the read-only community string 'public' as specified in the question, not the read-write 'private'.

snmp-server community public RO snmp-server community private RW snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456 snmp-server enable traps snmp-server host 203.0.113.10 version 2c public snmp-server host 203.0.113.10 version 3 auth admin ip flow-export destination 203.0.113.20 2055 ip flow-export version 5

Why wrong: This configuration incorrectly uses NetFlow version 5 instead of version 9. The question explicitly requires version 9, which supports templates and is more flexible than the older version 5.

Replace the faulty cable between R1 and R2 to eliminate CRC errors caused by physical layer issues.

Why wrong: This is incorrect because CRC errors are more commonly caused by duplex mismatch than by faulty cables; the interface shows full-duplex, but the errors suggest the other end is half-duplex.

Disable autonegotiation on the interface with 'no negotiation auto' to force the link to use the configured speed and duplex.

Why wrong: This is incorrect because disabling autonegotiation alone does not resolve a duplex mismatch; you must explicitly set both speed and duplex to match the other device.

Increase the interface MTU to reduce fragmentation and improve performance on the link.

Why wrong: This is incorrect because MTU adjustments do not address CRC errors or duplex mismatches; CRC errors are layer 1/2 issues, not related to packet size.

The interface is configured with an incorrect encapsulation type.

Why wrong: The output shows 'Encapsulation ARPA', which is the standard Ethernet encapsulation. If the wrong encapsulation were configured, the interface would likely go down or show encapsulation mismatches, not high CRC counts.

A duplex mismatch exists between the connected devices.

Why wrong: The interface is running at full-duplex and shows zero collisions, late collisions, or runts. A duplex mismatch would typically exhibit collisions, late collisions, or runts on the half‑duplex side, none of which appear.

The interface is assigned to the wrong VLAN.

Why wrong: VLAN assignment errors cause connectivity failures, not physical‑layer errors. The output shows no VLAN-specific counters like 'unknown protocol drops' related to VLAN mismatches, and the interface is otherwise passing traffic.

Disable port security on the interface.

Why wrong: This would restore connectivity but removes the beneficial security control. It is a drastic step that should only be considered after tuning the security parameters has failed, and it does not investigate the root cause.

Enter the shutdown and no shutdown commands to recover the port, then enable port security with sticky MAC learning.

Why wrong: Recovering the port immediately without changing the violation mode or max MACs will likely cause another err-disable when the PC tries to communicate again. Sticky MAC learning converts dynamically learned addresses to static entries, but if the maximum is still 1 and a second MAC appears, the shutdown will still occur. This step does not prevent the recurrence.

Verify the spanning-tree portfast configuration on the interface.

Why wrong: Spanning-tree PortFast enables faster forwarding when a device connects, but it does not cause err-disabled due to security violations. The err-disabled state here is clearly caused by port security, so troubleshooting spanning tree would target the wrong layer and waste time.

Verify that both switches are using the same EtherChannel protocol (LACP or PAgP).

Why wrong: This is unnecessary because both switches are already configured with channel-group 1 mode active, which explicitly enables LACP. They are using the same protocol; a protocol mismatch cannot be the cause.

Check that the speed and duplex settings match on all member interfaces.

Why wrong: While speed/duplex mismatch is a valid cause of the 'I' state, it is not the most targeted next step after confirming LACP mode. The technician should first rule out VLAN configuration mismatches, which are equally likely and require immediate inspection when trunk ports are involved.

Determine whether Spanning Tree Protocol is blocking one of the ports.

Why wrong: STP blocking state does not affect EtherChannel negotiation. A port that is part of a bundle will be shown in the 'P' (bundled) state regardless of STP status. The 'I' state indicates the port is not even joining the bundle, so STP is not the cause.

The VLAN 10 SVI has been administratively shut down.

Why wrong: An administratively shut down SVI would show 'administratively down' as the Status, not 'down'. The exhibit shows 'down', so this is not the cause.

The IP address configured on the VLAN 10 SVI is incorrect for the subnet.

Why wrong: An incorrect IP address would not cause the SVI to be down/down. It would still show up/up (or possibly up/down if there were a Layer 2 issue), but the IP-related problem would only affect reachability, not interface status.

The switch ports assigned to VLAN 10 are all configured as trunk ports.

Why wrong: Trunk ports can still carry VLAN 10 traffic and provide an active member port for the VLAN, provided they are up/up and the VLAN is allowed and active on the trunk. This would not prevent the SVI from coming up if those trunks are functioning.

There is a native VLAN mismatch between the two switches.

Why wrong: A native VLAN mismatch does not prevent a trunk from forming. DTP negotiates trunking irrespective of native VLAN assignment. A mismatch will allow the trunk to come up but cause CDP/STP notifications and possible untagged traffic leakage, yet the trunk interface appears in show interfaces trunk.

The connecting cable is a straight-through Ethernet cable rather than a crossover cable.

Why wrong: Modern Cisco switches support auto-MDIX, which automatically adjusts the interface to work with either a straight-through or crossover cable. A cable type mismatch would not prevent the link from coming up or forming a trunk. The link is already up, so this is not the cause.

One switch lacks a VLAN that exists on the other switch.

Why wrong: Trunk formation does not require identical VLAN databases. Trunk negotiation uses DTP, not VLAN presence. A missing VLAN would result in traffic for that VLAN being discarded or not forwarded, but the trunk itself would still be established and shown as a trunk port.