CCNA sample questions — 25 answered and explained

Oversized received frames are counted as giants.

The switch port accepts standard Ethernet frames sized for a 1500-byte payload. When the server sends 9000-byte frames, the port receives frames larger than its maximum and discards them, incrementing the giants counter (part of input errors). Runts are undersized frames, late collisions need half duplex, and output drops concern the switch's own transmit queues. The fix is to match the MTU on both ends.

1. Note the size difference: 9000-byte frames into a 1500-byte port.
2. Recall that oversized received frames are giants.
3. Reject undersized (runts), half-duplex (late collisions) and transmit-side (output drops) counters.
4. Align the MTU on the NIC and the switch.

Exam tip: Giants rising on a port usually means a neighbour is sending bigger frames than the port's MTU allows.

Collisions are normal on half-duplex shared Ethernet.

A hub creates one collision domain, and every device on it runs half duplex using CSMA/CD: when two transmit at once a collision occurs, both back off and retry. A slowly rising collisions counter on such a segment is expected. Problems are indicated by late collisions (a duplex mismatch or an over-length segment) or CRC errors (cable or interference), and both are zero here.

1. Identify the media: hub, so shared half duplex.
2. Recall that CSMA/CD expects collisions there.
3. Check the warning counters: late collisions and CRC are zero.
4. Conclude normal behaviour.

Exam tip: Ordinary collisions on half duplex are normal; late collisions never are.

Late collisions: a collision detected after the first 64 bytes of a frame, which a correctly built half-duplex segment never produces.

A late collision is a collision detected after the first 64 bytes of a frame have been sent. Cisco's troubleshooting guidance lists its causes as a duplex mismatch, cabling that exceeds Ethernet length limits, and faulty hardware. The stem rules out a duplex mismatch (both ends fixed at half duplex), and the run is about 160 m, beyond the 100 m limit for a twisted-pair segment, so the cabling is the first thing to fix. Interference would show as CRC errors, and ordinary collisions are not late collisions.

1. Separate late collisions from ordinary collisions.
2. Recall the causes of late collisions: duplex mismatch, over-length cabling, faulty hardware.
3. Eliminate the duplex mismatch using the stem's configuration.
4. Compare 160 m with the 100 m twisted-pair limit and fix the cabling.

Exam tip: Late collisions with matched duplex point to over-length cabling (or faulty hardware).

Twisted-pair Ethernet is limited to 100 m per channel at every speed and category.

The 100 m limit applies to twisted-pair Ethernet regardless of category or speed: 100BASE-TX, 1000BASE-T and 10GBASE-T on Cat6a all stop at 100 m. A 140 m run is therefore out of specification on any copper option, which explains the CRC errors and flapping. With no active device allowed mid-run, the fix is fiber: 1000BASE-SX on multimode fiber is rated for hundreds of metres at 1 Gb/s.

1. Compare the 140 m run with the 100 m twisted-pair limit.
2. Note the constraint: one direct run, no repeater or switch.
3. Eliminate every copper option because the limit does not change with category, shielding or speed.
4. Choose a fiber medium whose reach covers 140 m.

Exam tip: Beyond 100 m, copper needs an active device in the path or the run moves to fiber.

Cable category determines which twisted-pair speed is supported at what length.

10GBASE-T needs Cat6a (or better) for a full 100 m channel; on Cat6 it is supported only over a short distance (about 55 m), so an 80 m Cat6 run produces errors at 10 Gb/s even though 1000BASE-T ran cleanly. Recabling the whole channel with Cat6a fixes it. Cat5e is lower grade, forcing speed and duplex does not change the cable, and replacing only the patch cords leaves the long Cat6 segment in place.

1. Note the symptom appears only after moving to 10 Gb/s.
2. Recall that Cat6 supports 10GBASE-T only over a short run.
3. Recall that Cat6a supports 10GBASE-T to 100 m.
4. Choose recabling the full channel with Cat6a.

Exam tip: 10GBASE-T to 100 m needs Cat6a; Cat6 stops far short.

Twisted-pair Ethernet has a 100 m channel limit.

Copper twisted-pair Ethernet (10BASE-T, 100BASE-TX, 1000BASE-T, 10GBASE-T on Cat6a) is specified for a 100 m channel, typically 90 m of fixed cabling plus patch cords. At 120 m the signal is too weak and delayed, which shows up as errors and link drops. The other figures belong to coax, multimode fiber and Cat6 at 10 Gb/s.

1. Note the medium: Cat6 twisted pair.
2. Recall the 100 m twisted-pair channel limit.
3. Compare: 120 m exceeds it.
4. Shorten the run, add an access switch closer, or use fiber.

Exam tip: Twisted pair: 100 m, whatever the category.

When an SVI is up/up

An SVI is up/up when its VLAN exists and is active, the SVI is not shut down, and at least one Layer 2 port carrying the VLAN (an access port in it, or a trunk allowing it) is up and in spanning-tree forwarding. Here the VLAN is active and the SVI is not shut (status up). No access port is listed for VLAN 30 (show vlan brief never lists trunk ports), and with the line protocol down no up trunk is forwarding it either, so autostate keeps the SVI down until a host or trunk carrying VLAN 30 comes up.

1. Status up rules out a shutdown SVI.
2. show vlan brief shows VLAN 30 exists but no access port is in it (trunks are not listed there).
3. Recall the SVI needs an up, forwarding port in its VLAN.
4. Assign an access port or allow VLAN 30 on an up trunk.

Exam tip: An SVI's line protocol follows the VLAN: no up, forwarding port in the VLAN means down.

IP routing on a multilayer switch

When IP routing is disabled a Catalyst switch behaves like a host: show ip route displays the default gateway and ICMP redirect cache instead of a routing table. Each SVI still answers pings from its own VLAN, but nothing is routed between the SVIs. ip routing turns on the routing table, and the connected SVI subnets then appear and are routed.

1. Note that each VLAN reaches its own SVI, so Layer 2 and the SVIs work.
2. Read show ip route: a host-style output, not a routing table.
3. Conclude IP routing is disabled and enable it.

Exam tip: No routing table in show ip route on a switch means ip routing is off.

LACP active and passive modes

LACP has two negotiating modes: active, which sends LACPDUs, and passive, which only replies. At least one end must be active. Desirable and auto are PAgP modes, a different (Cisco-proprietary) protocol, so they cannot pair with an LACP port.

1. Identify SW1's mode: LACP passive.
2. Recall that passive never starts negotiation.
3. Choose LACP active on SW2.

Exam tip: LACP needs at least one active end; desirable and auto belong to PAgP.

LACP passive on both ends

show etherchannel summary shows Po1 as Layer 2 down (SD) and both members as stand-alone (I), meaning LACP never negotiated. Both ends are passive, and passive only answers LACPDUs. Setting either end to active starts the negotiation. Port-channel numbers are local, LACP is standard on Cisco switches, and the load-balance method does not affect bundling.

1. Read the flags: Po1 down, members stand-alone.
2. Check the mode: passive on both switches.
3. Recall that passive never initiates LACP.
4. Change at least one end to active.

Exam tip: LACP passive plus passive never forms a bundle.

Static on mode versus LACP negotiation

Mode on bundles ports unconditionally and sends no LACP or PAgP frames. SW2 is active, so it waits for LACPDUs that never arrive and leaves its ports stand-alone. Changing SW1 to either LACP mode fixes it: active and active, or passive answering SW2's active. Desirable and auto are PAgP modes, and lacp rate fast does not take a port out of mode on.

1. Recall that mode on sends no negotiation frames.
2. Note SW2 is LACP active and needs LACPDUs back.
3. Pick the LACP modes that pair with active: active and passive.

Exam tip: Mode on pairs only with mode on; LACP active pairs with active or passive.

EtherChannel member consistency

Members of an EtherChannel must match on speed, duplex, switchport mode, and on trunks the allowed and native VLANs. A port that differs from the bundle is suspended, shown by the lowercase s flag. Gi1/0/3 allows only 10 and 20 while the bundle allows 10, 20 and 30. Configuring trunk settings on interface Port-channel1 applies them to all members, which fixes this port and keeps future members consistent. LACP mode, port priority and the native VLAN do not resolve a parameter mismatch.

1. Read the flags: Gi1/0/1-2 bundled (P), Gi1/0/3 suspended (s).
2. Compare configurations: the allowed VLAN lists differ.
3. Recall that mismatched members are suspended.
4. Configure trunk settings on the port-channel so all members inherit them.

Exam tip: Configure an EtherChannel on its Port-channel interface; a member that differs is suspended.

A static route enters the routing table only when its next hop is reachable.

Configuration and routing table are separate: the route is in the running configuration, but IOS installs it only when it can resolve the next hop. 10.0.24.4 belongs to the subnet on Gi0/0/1, and an administratively down interface removes that connected route, so the static route cannot be resolved and stays out. Running no shutdown on Gi0/0/1 brings the connected network back, and the static route is installed with it.

1. Confirm the route exists in the configuration.
2. Confirm it is missing from the routing table.
3. Find the interface that would reach the next hop and check its status.
4. Fix the interface; the route follows.

Exam tip: Configured is not installed: a static route needs a reachable next hop.

Static routing must be configured in both directions.

The echo requests reach PC-B because R1 has a route to 10.3.3.0/24, but PC-B's replies go to R3, and R3 has no route to 10.1.1.0/24 and no default route, so it drops them. Static routes are one-way: each router needs its own route toward the remote network. On R3 the next hop is R1's address on the shared link, 10.0.13.1.

1. Trace the request: R1 has a route, so it reaches PC-B.
2. Trace the reply: R3 needs a route to 10.1.1.0/24.
3. Use R1's address on the shared link as R3's next hop.

Exam tip: A ping needs a route there and a route back.

A static route that names only an Ethernet exit interface makes the router ARP for every destination.

With only an exit interface, IOS treats 10.50.0.0/16 as directly connected on Gi0/0/1 and ARPs for each destination, such as 10.50.1.10. Those addresses are not on the segment, so the route works only if R2 answers with proxy ARP, which is disabled here, hence the incomplete ARP entry. Giving a next hop, either alone or together with the exit interface, makes R1 ARP once for 10.0.12.2 and forward every packet to R2. A distance value or a host route to R2 leaves the interface-only route in charge.

1. Read the incomplete ARP entry: R1 is ARPing for a remote host.
2. Link that to the interface-only static route on a multi-access segment.
3. Note that R2's proxy ARP is off and must stay unchanged.
4. Choose routes that include R2's address as the next hop.

Exam tip: On Ethernet, give a static route a next hop (optionally with the interface), not just an interface.

An IPv6 network route names the remote prefix and a next hop.

The syntax is ipv6 route <prefix>/<length> <next hop>. The prefix is the remote LAN, 2001:db8:cafe:10::/64, and the next hop is R2's address on the link that R1 shares with it. A /128 would cover one address, swapping the fields points at the wrong network, and ip route is for IPv4.

1. Identify the destination prefix: the remote LAN /64.
2. Identify the next hop: R2's address on the shared link.
3. Use ipv6 route with the prefix first.

Exam tip: ipv6 route <remote prefix>/<len> <neighbour's address>.

IOS routes IPv6 only when ipv6 unicast-routing is enabled.

Two symptoms point to one cause: no default gateway from SLAAC and no transit forwarding. Both depend on the global command ipv6 unicast-routing, which is off by default on IOS. The static route and addresses can be correct while the router still behaves like an IPv6 host. A global next hop is fine, the interface is clearly IPv6-enabled, and the distance defaults to 1.

1. Note that R5 itself answers, so addressing works.
2. Note that transit traffic fails and no RAs are seen.
3. Recall that both need ipv6 unicast-routing.
4. Enable it globally.

Exam tip: No IPv6 forwarding and no RAs? Check ipv6 unicast-routing.

Inside a server group, a non-responding server makes IOS try the next server; a reject from any server ends the method list.

Two rules combine here. First, when ISE1 does not answer, IOS tries the next server in TAC-SERVERS, ISE2, before it gives up on the group, so asmith is authenticated by ISE2 after a delay. Second, ISE2 answers bkhan with a reject, and a reject is a fail rather than an error: the list stops there and local is never tried, so her local password does not help. Local would be used only if no server in the group answered.

1. Classify ISE1's silence: an error, so try the next server in the group.
2. Classify ISE2's answer for each admin: accept or reject.
3. Remember that a reject ends the list; only errors move on to local.
4. Check each statement against these two rules.

Exam tip: Silence moves on (next server, then next method); a reject stops everything.

Method order decides both which source is primary and what the fallback is.

Putting group RAD-GRP first makes RADIUS authoritative whenever a server answers, because a reject is final. Local is used only after an error, when no server responds, which is exactly the outage case. Reversing the order makes local accounts valid at all times. Ending the list with line or enable falls back to a shared password rather than named accounts with a username.

1. Pick the primary source: RADIUS first.
2. Recall that the second method runs only on error.
3. Check the fallback against 'username and password': local fits, line and enable do not.

Exam tip: Put the server group first and local second, so named local accounts are the outage fallback.

TACACS+ encrypts the entire payload over TCP 49; RADIUS encrypts only the password over UDP 1812/1813.

TACACS+ encrypts the full body of each packet, leaving only the header readable, and uses TCP port 49. RADIUS uses UDP 1812 and 1813 and protects only the User-Password attribute, so usernames and other attributes appear in clear text. The pairings with the wrong transport or port are near-twins built from these facts.

1. Match 'hide everything, not only the password' to TACACS+.
2. Recall that TACACS+ runs over TCP 49.
3. Reject options that pair a protocol with the other's port.

Exam tip: TACACS+ = TCP 49, whole body encrypted. RADIUS = UDP 1812/1813, password only.

TACACS+ keeps authentication, authorization and accounting separate, which enables per-command authorization.

TACACS+ was designed for device administration and handles authentication, authorization and accounting as separate exchanges. With aaa authorization commands, the router sends each command to the server before it runs. RADIUS combines authentication and authorization in a single Access-Accept and cannot authorize individual commands, which is why it is preferred for network access rather than device administration.

1. Note the need for a check on each command after login.
2. Recall which protocol separates authorization from authentication.
3. Reject options that mix one protocol's messages with the other.

Exam tip: Per-command authorization for device admins needs TACACS+.

RADIUS server definitions include ports; they must match the ports the server listens on.

The radius server entry sends authentication to UDP 1645 and accounting to 1646, the legacy RADIUS ports, while the server listens only on the IANA-assigned 1812 and 1813. Nothing reaches the server, so it logs nothing; the requests time out, which is an error, and the list falls back to local. The port order in the entry is correct for the legacy pair, and a key mismatch would still reach the server and be logged. Setting auth-port 1812 and acct-port 1813 resolves it.

1. Note that the server logs nothing, so the packets never arrive.
2. Recall the standard RADIUS ports, 1812 and 1813, and the legacy pair, 1645 and 1646.
3. Compare them with the configured ports.
4. Explain the local logins: a timeout is an error, which triggers fallback.

Exam tip: If the AAA server logs nothing, check address and ports first; RADIUS standard ports are 1812/1813.

Human-in-the-loop: the agent recommends, a person approves before anything changes.

The requirement is that an engineer decides on each change. An approval step before the push does exactly that. Temperature and persona change the text the model produces, and autonomous operation with rollback removes the human decision the board asked for.

1. Identify who must decide: a qualified engineer.
2. Find the control that puts that decision before the change.
3. Reject options that only change the model's output or react afterwards.

Exam tip: Agent proposes, human approves, then the change is applied.

Read-only data collection is low risk; anything that changes forwarding, policy or device state, even counters, needs approval.

Teams usually let agents gather data freely and gate actions that change state. Collecting show interfaces and show logging output alters nothing on the device. Shutting an uplink or adding an ACL can cause an outage if the agent's diagnosis is wrong, and clearing counters, though low impact, still changes the device and destroys evidence an engineer may want to see. Only the read-only action is a safe unattended action.

1. Classify each action as read-only or state-changing.
2. Treat 'small' changes such as clearing counters as changes too: they alter the device and remove evidence.
3. Allow only the action that changes nothing.

Exam tip: Let the agent look freely; make it ask before it touches.

Guardrails for agent-driven changes: staged rollout limits blast radius; backup and rollback give fast recovery.

The stem sets two goals. Limiting the number of affected sites calls for a staged rollout: try the change on one router, verify, then continue. Recovering quickly calls for a saved configuration and a tested rollback ready before each push. Extra approvers and a maintenance window are sensible practices, but neither limits how many sites a bad change reaches or makes recovery faster, and an explanation in the ticket helps review only.

1. Write down the two goals: limit how many sites are hit, recover fast.
2. Match one control to each goal.
3. Discard controls that improve review or timing but meet neither goal.

Exam tip: Pilot first to shrink the blast radius; back up first to make rollback fast.