Scenario-Based CCNA Interview Questions

Late collisions usually mean a duplex mismatch, and CRC errors point to bad cabling or interference. I would run show interfaces on the port to see duplex, speed and error counters, check the PC NIC settings, and set both sides to auto or hard-code both identically. Then I would replace the patch cable, clear counters and watch whether errors still increase.

Gateway reachability proves Layers 1 to 3 locally, so I move upward. I ping a public IP address; if that works but names fail, DNS is the problem, so I check the configured DNS server with ipconfig /all and test with nslookup. If the public IP also fails, I check the router's default route, NAT and upstream link. Finally I check proxy settings and any firewall blocking ports 80 and 443.

No link light means a Layer 1 problem. I verify the switch has power and the ports are not administratively shut down with show ip interface brief. I test the cable with a tester, check the patch panel mapping and confirm the NIC is enabled. If the switch uses PoE for phones or access points, I also check the power budget with show power inline.

A branch router or SD-WAN edge for the WAN link and internet, one or two 48-port PoE access switches for PCs, phones and access points, and wireless access points managed by a controller or the cloud. I would add a firewall function, DHCP and DNS settings, VLANs for data, voice, guest and management, and a backup 4G or broadband link for resilience.

I check show interfaces on both ends for input errors, CRC, runts, giants, output drops and resets. Output drops suggest congestion, so I look at utilisation and QoS. CRC errors suggest a bad cable, dirty fiber or faulty SFP, so I check optical levels with show interfaces transceiver. I also confirm both sides agree on speed and duplex and that the MTU matches.

Suspect an MTU mismatch. Small pings fit in one frame, but full-size packets are dropped when one link or the new switch uses a smaller MTU, or when ICMP is blocked so Path MTU Discovery fails. Test with ping using a size of 1472 and the do-not-fragment bit, compare interface MTU on both ends, and check jumbo frame settings. Fix by matching MTU end to end or adjusting TCP MSS on tunnel interfaces.

169.254.x.x is an APIPA address, assigned when the host fails to get a DHCP lease. I would check that the port is up and in the correct VLAN, that the DHCP server has free addresses in the scope, and that the router interface for that VLAN has ip helper-address pointing to the server if the server is remote. Then I run ipconfig /renew and check server logs.

Each host decides local or remote using its own mask. With 192.168.1.10/24 and 192.168.1.200/25, the first thinks .200 is local and ARPs directly, but the second sees .10 as remote and sends replies to its gateway. Traffic can become one-way or asymmetric and may break completely if the gateway does not route it back. Fix the mask so both match the design.

Options: expand to a /23 if the adjacent block is free and update the router and DHCP scope; create a new VLAN and subnet for some users, which also limits broadcast size; shorten DHCP lease times if many guest devices hold leases; and move printers, phones and IoT devices to their own subnets. Long term, plan an addressing scheme with growth headroom and consider dual-stack IPv6.

Overlapping address space means routing alone cannot work. Short term, use NAT on the interconnect so each side sees the other as a different translated range, for example twice NAT or policy NAT. Long term, renumber one network into a free range, which is cleaner but needs planning for DHCP, DNS, firewall rules and static IPs. I would also document the IP address management plan to prevent repeats.

With a /26 the block size is 64, so 192.168.5.64 is the network address of the subnet .64 to .127 and cannot be assigned to a host or interface. IOS reports a bad mask or overlap error. Use a usable address such as 192.168.5.65 instead. Similarly .127 would be the broadcast. Always calculate the subnet boundary before configuring addresses.

First I check each PC has the correct IP, mask and gateway for its VLAN. Then I confirm the switch ports are in the right VLANs with show vlan brief, and that the trunk to the Layer 3 device allows both VLANs using show interfaces trunk. On the Layer 3 device I check the SVIs or subinterfaces are up and have the right IPs, and that no ACL blocks the traffic.

The most likely cause is the trunk to that switch does not allow the new VLAN, because someone configured an explicit allowed list. Check show interfaces trunk and add it with switchport trunk allowed vlan add 50, not without add, which would replace the list. Also confirm the VLAN exists on that switch with show vlan brief, especially if VTP is transparent.

An SVI comes up only if the VLAN exists in the VLAN database and at least one access or trunk port in that VLAN is up and forwarding, and the SVI is not shut down. So I check show vlan brief for the VLAN, check that at least one port in it is connected, check trunks allow it, and run no shutdown on the SVI. On Layer 3 switches, ip routing must be enabled for routing.

I check show interfaces trunk and show interfaces switchport on both sides. Common causes are mismatched modes (both dynamic auto), one side hard-coded as access, encapsulation not set on older switches, or the port being err-disabled. Native VLAN mismatch and allowed list differences do not stop the trunk but break traffic. Best fix is switchport mode trunk on both ends with nonegotiate.

I would split users into VLANs by function or floor, each with a /24 or smaller, put voice, wireless, printers, servers and management in their own VLANs, and route between them on a Layer 3 core with SVIs. DHCP scopes and helper addresses would be added per VLAN. I would migrate in phases with a rollback plan and move VLAN 1 out of use for both users and the native VLAN.

MAC flapping means the switch sees the same source MAC arriving on two ports, which usually points to a Layer 2 loop, a misconfigured server NIC team, or a virtual machine host bridging two uplinks. Check show mac address-table for the MAC, trace both ports, verify STP state and look for unmanaged switches or hypervisor teaming in active-active mode without a matching port channel. Fix the loop or teaming, and keep BPDU Guard on access ports.

Two wall ports patched to the same switch formed a loop. To stop it now, I find the port with rising broadcast counters and shut it. To prevent repeats, enable PortFast with BPDU Guard on all access ports, keep Rapid PVST+ running everywhere, add storm-control broadcast thresholds on access ports and enable errdisable recovery with a sensible interval.

The old switch has the lowest MAC with default priority, so it won the election. I set the core or distribution switch as root with spanning-tree vlan 1-4094 priority 4096, or root primary, and the secondary with 8192. I add Root Guard on distribution downlinks so access switches can never become root again. Then I verify with show spanning-tree root.

Suspended (s) usually means a configuration mismatch between members or with the far end. I compare speed, duplex, trunk mode, native VLAN and allowed VLANs on each member and the port-channel with show run interface, check LACP modes on both sides, and look at logs. I fix the config on the port-channel, then shut and no shut members so they rejoin. show etherchannel summary should show P flags.

Load balancing is per flow based on a hash. If the method is src-mac and most traffic comes from one router MAC, all flows hash to one link. I change port-channel load-balance to src-dst-ip or src-dst-mixed-ip-port so many flows spread across members. If the traffic is a single large flow, it can never exceed one member, so faster links would be needed.

Frequent TCNs flush MAC tables and cause flooding. I run show spanning-tree detail to find the port and switch originating topology changes, then follow it hop by hop. Common causes are a flapping link, a host port without PortFast that changes state each time a PC reboots, or a failing NIC. I fix the link and enable PortFast on edge ports so they do not generate TCNs.

EXSTART or EXCHANGE stuck usually means an MTU mismatch, because database description packets larger than the neighbour's MTU are dropped. I compare MTU with show interfaces and set ip mtu to match on both sides. As a temporary workaround, ip ospf mtu-ignore can be used, but fixing the MTU is better. Duplicate router IDs can also cause odd adjacency behaviour, so I check those too.

I check that the interfaces are up and in the same subnet, then show ip ospf interface to compare area, hello and dead timers, network type and authentication. I make sure the interface is not passive and that the network statement or ip ospf area command covers it. Finally I check that no ACL blocks protocol 89 or multicast 224.0.0.5, and use debug ip ospf adj if needed.

Another source with a lower AD may be providing the same prefix, such as a static route, so the OSPF route is not installed. Or a more specific route wins by longest match. The next hop may also be unreachable, or a distribute-list may filter it. I check show ip route for the prefix, show ip ospf database, and compare administrative distances.

Run OSPF over MPLS for the primary path. For the backup, use a floating static default route via the broadband link with AD higher than OSPF, for example 250, or run an IPsec tunnel with OSPF at a higher cost. Track the primary with IP SLA if the provider does not drop the link on failure, so the backup activates even when the interface stays up.

Both paths must have equal total cost to be installed as ECMP. I check show ip route for two next hops. If only one shows, I compare interface costs, which differ if bandwidth or the reference bandwidth differs. I also check maximum-paths. Even with ECMP, load sharing is per flow using CEF, so a single large flow uses one link only.

This is asymmetric routing: the firewall sees only one direction of the flow and drops it. Make the path symmetric by using one active exit per prefix, for example HSRP or a higher OSPF default-route cost on the backup, and advertise inbound routes consistently with the same preference. If both links must be active, pair the firewalls with state sharing or use NAT per exit so return traffic comes back to the router that sent it.

I check show ip nat translations to see whether translations appear when users browse. If none, I verify ip nat inside and ip nat outside on the correct interfaces, that the ACL used by NAT matches the user subnets, and that the overload interface has an IP. I also check the default route and run show ip nat statistics for hits and misses.

I check that the SVI for the new VLAN is up and has ip helper-address pointing to the DHCP server, that the server has a scope for that subnet with the right gateway, and that the scope is activated. I confirm the VLAN is allowed on trunks. If DHCP snooping is enabled, I check the uplink is trusted, otherwise offers from the server are dropped.

Choppy voice under load means congestion on the WAN. I make sure phones mark RTP as EF and the access switches trust phone markings, then on the WAN router create a policy with a low latency priority queue for EF limited to the needed bandwidth, CBWFQ for other classes, and shaping to the real carrier rate so queuing happens on my router, not the provider's.

Clocks are not synchronised. I configure all devices to use the same internal NTP servers with ntp server, set the timezone with clock timezone IST 5 30, add service timestamps log datetime msec localtime, and enable NTP authentication. Then I check show ntp associations and show ntp status to confirm synchronisation. This makes future incident timelines reliable.

Use static NAT or port forwarding so the public IP maps to the server's private IP, for example ip nat inside source static tcp 192.168.1.20 443 203.0.113.10 443. Add an ACL or firewall rule allowing only port 443 inbound, put the server in a DMZ VLAN, and create a public DNS record. Ideally place a firewall or reverse proxy in front instead of exposing the server directly.

The phones need extra DHCP options that were probably not copied, such as option 150 or option 66 for the TFTP or call server and sometimes a voice VLAN option. Check the scope options on the new server, confirm the relay on each SVI points to it, and capture the DHCP offer to see which options arrive. Also verify the voice VLAN scope exists and that ACLs allow TFTP from the phone subnets to the call server.

Most likely the ACL lacks a permit for normal traffic, so the implicit deny dropped everything, or the order put a broad deny above the specific permits. It may also be applied in the wrong direction or on the wrong interface. I check show access-lists for hit counts, fix the sequence by inserting lines, and add a final permit or the needed entries. I always test ACLs with a rollback timer.

I run show interfaces status err-disabled and show errdisable recovery to see the cause, such as psecure-violation, bpduguard or link-flap. If it is port security, the user may have plugged in a small switch or a docking station with an extra MAC, so I check show port-security interface. I fix the cause, then shut and no shut the port, or set the max MAC count appropriately.

A rogue DHCP server, often a home router plugged into a wall port, is answering requests. I find it by checking the DHCP server IP on an affected client with ipconfig /all, then tracing its MAC with show mac address-table. I shut that port, and prevent it permanently by enabling DHCP snooping on user VLANs with only uplinks trusted.

Put guests in their own VLAN and subnet, ideally terminating on a firewall or a separate VRF. Apply an inbound extended ACL on the guest SVI that permits DHCP and DNS to the allowed servers, denies all RFC 1918 destinations, and then permits any to the internet. Enable client isolation on the wireless side and rate limit the guest SSID so it cannot consume the WAN.

Disable Telnet with transport input ssh, enable SSH v2, and move admin login to AAA with TACACS+ so each engineer has a personal account with command authorisation and accounting logs. Keep one local fallback account in a password vault. Restrict VTY access with an ACL to the management subnet. Roll out with automation, test on a pilot, then document it for the audit.

Move management to a dedicated VLAN or out-of-band network, ideally in a management VRF. Apply an access-class ACL on VTY lines allowing only the jump host subnet, disable Telnet and HTTP, keep SSH version 2 and HTTPS only if needed, and use AAA with TACACS+ for per-user login and logging. Add control plane policing, block management subnets at the user VLAN gateways and rescan to confirm the fix.

This is usually a capacity, not a coverage, issue. I check client count per AP and channel utilisation on the controller. Fixes include adding APs with lower transmit power, steering clients to 5 or 6 GHz with band steering, disabling low data rates such as 1, 2 and 5.5 Mbps, using 20 or 40 MHz channels in dense areas, and limiting per-client bandwidth on the SSID.

I check the AP gets a DHCP address and can reach the WLC management IP. It discovers the controller through DHCP option 43, the standard CAPWAP controller DNS name, broadcast or a primed controller IP, so I verify one of these. Then I check UDP 5246 and 5247 are not blocked, the AP's clock and certificate are valid, the country code matches, and the WLC has AP licences available.

Association works, so the issue is between the AP or WLC and DHCP. I check the WLAN is mapped to the right dynamic interface and VLAN, that the VLAN is allowed on the WLC and AP trunks, and that DHCP relay or helper is set on the VLAN gateway. In FlexConnect local switching, I check the AP switchport trunk and VLAN mapping. Finally I check the DHCP scope.

I would start with a source of truth for devices and variables, then use Ansible playbooks with Jinja2 templates to generate and push standard configs over SSH, keeping them in Git with peer review. A controller such as Catalyst Center could handle day-0 provisioning and compliance. I would start with read-only tasks like backups and audits, then move to small, tested change automation.

401 Unauthorized means authentication failed. I check the username and password or API key, whether a token must first be requested from an auth endpoint and sent in a header like X-Auth-Token, whether the token expired, and the exact header name and format. I test the same call with curl or an API client to separate script bugs from credential issues.

First stop the job, then recover through out-of-band console or a management network, using configuration archive rollback or a saved backup. In future, run changes with commit confirmed or reload in as a safety timer, test in a lab, use a dry run or check mode, deploy to one canary switch, then in small batches with automatic post-checks. Store templates in Git with peer review so every change is visible and reversible.