CCNA Interview Questions & Answers

The OSI model splits communication into 7 layers, top to bottom:

• 7 Application — PDU: data. HTTP, DNS.
• 6 Presentation — data; encryption/encoding like TLS, JPEG.
• 5 Session — data; manages sessions, e.g. RPC.
• 4 Transport — PDU: segment (TCP) or datagram (UDP); TCP/UDP.
• 3 Network — PDU: packet; IP, the router.
• 2 Data Link — PDU: frame; Ethernet, the switch.
• 1 Physical — PDU: bits; cables, hubs.

Mnemonic: All People Seem To Need Data Processing. Data is encapsulated downward and de-encapsulated upward.

👉 Interview tip: Always pair each layer with its PDU and a device — that proves you understand encapsulation, not just memorization.

TCP is connection-oriented and reliable: it sets up a session (three-way handshake), numbers segments, acknowledges them, retransmits losses, and delivers data in order with flow and congestion control. UDP is connectionless: no handshake, no ACKs, no ordering — just fire-and-forget datagrams, so it has far less overhead.

• TCP example: a web page (HTTPS) or file download. You can't afford missing bytes — every byte must arrive correctly and in order.
• UDP example: a VoIP/video call. Speed matters more than perfection; a retransmitted late packet is useless, so it's better to skip it.

Analogy: TCP is a phone call with confirmations; UDP is shouting across a room.

👉 Interview tip: Frame the choice as reliability vs. latency — interviewers want the trade-off, not just the feature list.

Before any data flows, TCP establishes a connection in three steps, synchronizing sequence numbers in both directions:

1. SYN — the client sends a segment with the SYN flag set and its initial sequence number (ISN). This says "I want to talk; here's my starting sequence number."
2. SYN-ACK — the server replies with both SYN and ACK flags: it acknowledges the client's ISN (client ISN+1) and sends its own ISN.
3. ACK — the client acknowledges the server's ISN (server ISN+1). The connection is now ESTABLISHED and data can flow.

This ensures both sides agree on sequence numbers and confirm two-way reachability before sending data.

👉 Interview tip: Mention that closing uses a four-way handshake (FIN/ACK each direction) — a common follow-up.

A collision domain is a segment where two frames can collide (relevant to half-duplex/shared media). A broadcast domain is the set of devices that receive each other's broadcasts (an L2 boundary).

• Hub (L1): one big collision domain and one broadcast domain — it just repeats bits to all ports.
• Switch (L2): each port is its own collision domain (so collisions effectively disappear with full-duplex), but all ports stay in one broadcast domain per VLAN.
• Router (L3): each interface is a separate collision and broadcast domain — routers do not forward broadcasts.

So switches break up collision domains; routers (and VLANs) break up broadcast domains.

👉 Interview tip: Add that a VLAN on a switch also creates a separate broadcast domain — interviewers love that nuance.

A switch learns by reading the source MAC of every frame that arrives and recording it against the port it came in on, with a timer (Cisco default aging 300 seconds). That's how the MAC address table (CAM table) fills up.

When a frame arrives, the switch looks up the destination MAC:

• Known unicast → it forwards the frame out only the one matching port.
• Unknown unicast (not in the table) → it floods the frame out every port except the one it arrived on, hoping the destination replies so the switch can learn it.
• Broadcast/multicast → also flooded (unknown multicast floods unless IGMP snooping is constraining it).

So switches "learn source, forward destination, flood when unknown."

👉 Interview tip: Summarize it as the three switch functions: learning, forwarding/filtering, and flooding.

ARP (Address Resolution Protocol) maps a known IPv4 address to the MAC address needed to actually deliver a frame on the local LAN. IP gets the packet to the right network, but Ethernet needs a destination MAC to build the frame — ARP fills that gap. (IPv6 does the same job with Neighbor Discovery instead.)

When Host A wants to reach Host B (same subnet):

1. A checks its ARP cache for B's IP. If missing, it sends an ARP Request as a broadcast ("Who has 10.0.0.5? Tell 10.0.0.2").
2. Every host hears it, but only B replies with a unicast ARP Reply containing its MAC.
3. A caches B's MAC and now sends the actual frame as unicast.

👉 Interview tip: Note the request is broadcast but the reply is unicast — and that gratuitous ARP / ARP spoofing are common follow-ups.

OSI is a 7-layer reference model; TCP/IP is the 4-layer model the Internet actually runs on. Mapping:

• TCP/IP Application = OSI Application + Presentation + Session (5–7).
• TCP/IP Transport = OSI Transport (4) — TCP/UDP.
• TCP/IP Internet = OSI Network (3) — IP.
• TCP/IP Network Access/Link = OSI Data Link + Physical (1–2).

OSI is theoretical and vendor-neutral; TCP/IP is the practical implementation. Interviewers keep asking OSI because it's the shared troubleshooting vocabulary — "it's a Layer 2 problem" or "that's a Layer 7 issue" instantly communicates scope across teams, regardless of the real stack.

👉 Interview tip: Say OSI is the common language for diagnosing problems even though TCP/IP is what's running.

TCP windowing lets a sender transmit multiple segments before needing an acknowledgment. The receive window (advertised in every segment) tells the sender how much unacknowledged data the receiver can buffer — that's flow control: it stops a fast sender from overwhelming a slow receiver.

On a high-latency link, throughput is capped by the bandwidth-delay product: roughly throughput ≈ window_size / RTT. With a small window and a large RTT, the sender fires a few segments, then stalls waiting for ACKs — leaving the pipe mostly empty. Example: a 64 KB window over a 200 ms RTT caps you near ~2.6 Mbps no matter how fat the link is.

The fix is the TCP window scale option (defined in RFC 7323, which obsoleted the older RFC 1323), allowing windows beyond 64 KB to keep long, fast pipes full.

👉 Interview tip: Mention bandwidth-delay product and window scaling — that signals real depth.

"Faster" is only half the story — UDP has lower overhead, but it gives up reliability.

• File transfer: UDP is the wrong default. A file must arrive complete and in order; with raw UDP you'd have to rebuild sequencing, retransmission, and congestion control yourself — exactly what TCP already does. So TCP wins (it's why HTTPS/SFTP use it).
• VoIP call: UDP is correct. Voice is real-time; a packet retransmitted 300 ms late is useless and would cause jitter. Dropping a tiny bit of audio is better than stalling, so RTP-over-UDP is the standard.

Connectionless is right when latency and timeliness beat completeness — live media, DNS, gaming — and when the app handles loss gracefully or has its own recovery. Worth noting: QUIC (used by HTTP/3) runs over UDP but rebuilds reliability and ordering in user space, so "UDP" doesn't always mean "unreliable."

👉 Interview tip: Reframe "faster" as "lower overhead but no guarantees" — match the transport to the data's tolerance for loss.

In a classic three-tier campus (access / distribution / core), the modern best practice is to push the L2/L3 boundary down to the distribution layer (a "routed access" design pushes it even to the access layer). Access ports and VLANs stay L2; uplinks to distribution become L3 routed links.

• Broadcast-domain size: terminating VLANs at distribution keeps each broadcast domain small (one or a few access switches), limiting ARP/broadcast flooding.
• Blast radius: L3 boundaries contain L2 failures — a broadcast storm or STP loop is trapped in that segment instead of melting the whole campus.
• Convergence: routed uplinks let you use equal-cost multipath and fast IGP reconvergence instead of relying on slow Spanning Tree; you stop depending on STP for redundancy.

👉 Interview tip: Say "route where you can, switch where you must" — small L2 domains, L3 between them, to shrink failure domains and speed convergence.

DHCP assigns IP configuration automatically in four steps — DORA:

1. Discover — the client broadcasts a DHCPDISCOVER (it has no IP yet, so source is 0.0.0.0, destination is broadcast) looking for any DHCP server.
2. Offer — a server replies with a DHCPOFFER proposing an IP address, subnet mask, gateway, DNS, and lease time.
3. Request — the client broadcasts a DHCPREQUEST formally accepting one offer (broadcast so other servers know their offer was declined).
4. Acknowledge — the server sends a DHCPACK confirming the lease; the client may then ARP-probe to check the address is free.

DHCP uses UDP — server port 67, client port 68.

👉 Interview tip: Remember DISCOVER and REQUEST are broadcasts; knowing ports 67/68 is a frequent follow-up.

ACLs filter traffic by matching packets against an ordered list of rules.

• Standard ACLs match on the source IP address only. Number ranges 1–99 (and 1300–1999 expanded). Because they're so coarse, you place them close to the destination.
• Extended ACLs match on source and destination IP, protocol, and source/destination ports (e.g. permit TCP 80 from one host to a server). Number ranges 100–199 (and 2000–2699). Place them close to the source to drop unwanted traffic early.

Every ACL ends with an invisible implicit deny any — any packet not explicitly permitted is dropped. So an ACL with only permits still blocks everything else.

👉 Interview tip: Always mention the implicit deny and that one explicit permit is needed, or all traffic is dropped.

NAT (Network Address Translation) rewrites private IP addresses into public ones as packets cross a router. It exists mainly to conserve scarce IPv4 public addresses (RFC 1918 private space behind one or a few public IPs) and adds a side benefit of hiding internal addressing.

• Static NAT: a fixed one-to-one mapping — one private IP always maps to the same public IP. Used to publish an internal server.
• Dynamic NAT: private IPs are mapped to public IPs from a pool, first-come first-served; still one-to-one while in use, so you can run out of public IPs.
• PAT / NAT overload: many private IPs share one public IP, distinguished by unique port numbers. This is what home and most enterprise edges use.

Analogy: PAT is an office switchboard — one public number, many extensions.

👉 Interview tip: Stress PAT is the most common form and that it tracks translations by port.

Telnet sends everything — including usernames and passwords — in cleartext, so anyone capturing traffic reads your credentials. SSH encrypts the entire session and authenticates the device, so management is confidential and tamper-resistant. Use SSHv2 and disable Telnet on the VTY lines.

Three other hardening steps I'd always apply:

• Strong local/AAA auth + enable secret: use enable secret (hashed) not enable password, and ideally centralize with TACACS+/RADIUS.
• Restrict and secure management access: apply an ACL to the VTY lines, set exec-timeout, and use a dedicated management VLAN.
• Shut unused ports and services: administratively shut down idle interfaces, disable CDP where not needed, and turn off legacy services.

👉 Interview tip: Add a login banner and service password-encryption as quick wins — interviewers like a layered answer.

Port security restricts which and how many MAC addresses can use a switch access port, stopping unauthorized devices and MAC-flooding attacks. You enable it with switchport port-security and cap learned addresses with switchport port-security maximum N (default 1).

Sticky MAC (switchport port-security mac-address sticky) makes the switch dynamically learn the connected device's MAC and write it into the running config, so you don't type each MAC by hand but it persists like a static entry (you still need to save the running config to keep it after a reload).

The three violation modes (what happens when a non-allowed MAC appears):

• Protect — silently drops offending frames, no log, no counter.
• Restrict — drops frames, logs/SNMP, and increments the violation counter.
• Shutdown (default) — puts the port into err-disabled, blocking everything until reset.

👉 Interview tip: Know that Shutdown is the default and recovery needs shut/no shut or err-disable recovery.

Standard ACLs match source IP only, so placing one near the source could accidentally block that source's traffic to every destination. You put them near the destination so they only filter the intended flow. Extended ACLs match source, destination, protocol and port precisely, so you put them near the source to drop unwanted traffic early and save bandwidth across the network.

A subnet mask uses contiguous 1s to define a network (1 = network bit). A wildcard mask is the inverse: 0 means "must match exactly" and 1 means "don't care." Example: subnet 255.255.255.0 becomes wildcard 0.0.0.255, so 10.1.1.0 0.0.0.255 matches the whole 10.1.1.x range. A single host uses 0.0.0.0 (or the keyword host).

👉 Interview tip: Compute a wildcard as 255.255.255.255 minus the subnet mask — a quick interview shortcut.

The DHCP DHCPDISCOVER is a broadcast (destination 255.255.255.255, source 0.0.0.0). Routers, by design, do not forward broadcasts — they're the broadcast-domain boundary. So a client's discover never reaches a DHCP server sitting on another subnet, and the client gets no address.

The fix is a DHCP relay agent: you configure ip helper-address [server-ip] on the router interface facing the clients. The router catches the broadcast DHCP packet, converts it into a unicast aimed at the configured server (and records the receiving interface/subnet in the giaddr field so the server knows which scope to assign from), then forwards it. The server's replies come back through the relay to the client.

👉 Interview tip: Mention giaddr — it's how the central server picks the correct scope for that subnet, a common deeper follow-up.

An autonomous AP is fully self-contained — each one is configured and managed individually (fine for a few APs, painful at scale). A lightweight AP is managed centrally by a WLC (Wireless LAN Controller); you configure once and push to all APs.

CAPWAP (Control And Provisioning of Wireless Access Points) is the tunnel between the lightweight AP and the WLC, carrying a control channel (UDP 5246) and a data channel (UDP 5247). It uses split-MAC: the AP keeps real-time tasks (beacons, probe responses, ACKs, encryption on the air), while the WLC takes over management — RF management, roaming, security policy, authentication, and client load balancing.

WPA2-PSK uses a 4-way handshake and is vulnerable to offline dictionary attacks if the passphrase is weak. WPA3-SAE (Simultaneous Authentication of Equals / "Dragonfly") resists offline cracking and adds forward secrecy.

👉 Interview tip: "AP handles real-time, WLC handles management" sums up split-MAC.

In traditional networking every device runs its own control plane (it decides paths) and data plane (it forwards) — you configure each box by hand. In SDN / controller-based networking the control plane is centralized in a controller that programs many devices, while each device keeps only its data plane (forwarding). This gives one place for policy and a network-wide view.

APIs sit on each side of the controller:

• Northbound APIs face apps/automation tools (often REST over HTTPS using JSON) — this is where scripts and Ansible talk to the controller.
• Southbound APIs face the devices (NETCONF/RESTCONF, OpenFlow) — the controller programs the switches.

Ansible is agentless because it connects over SSH/APIs with nothing installed on the target, and idempotent because running a playbook repeatedly converges to the same desired state without making redundant changes.

👉 Interview tip: "Northbound = apps, Southbound = devices" is the line that lands.

I'd support the direction but challenge the "faster, simpler, cheaper" framing as oversimplified, and surface real trade-offs as business risk:

• New failure domains: SD-WAN adds a centralized controller/orchestrator and often a cloud broker — a new single point of failure. If it's unreachable, policy changes and onboarding stall. Frame it as availability risk; mitigate with controller redundancy and local fallback.
• Control trade-offs: moving to internet/broadband transport and cloud-delivered security means trusting a vendor's cloud and SLAs over your own MPLS. Frame as vendor lock-in and data-sovereignty risk.
• Operational burden: zero-trust needs continuous identity, device posture, and segmentation — a culture and tooling shift, not a product. Underestimating it causes project and security risk.
• Cost reality: circuit savings can be offset by licensing, security subscriptions, and retraining.

👉 Interview tip: Translate every technical concern into availability, security, lock-in, or cost risk — that's how architects earn leadership's trust.

A VLAN (Virtual LAN) splits one physical switch into multiple logical broadcast domains. Think of one office floor partitioned into separate rooms — devices in different VLANs can't talk directly without a router, even on the same switch.

It solves three problems:

• Broadcast containment — one big flat network floods every broadcast everywhere; VLANs shrink each broadcast domain, reducing noise.
• Security/segmentation — HR, Finance and Guest traffic stay isolated; you control inter-VLAN access with a router/firewall.
• Flexibility — group users logically (by role/department) regardless of physical location or cabling.

Valid IDs run 1–4094. 0 and 4095 are reserved. The normal range is 1–1005 (where 1002–1005 are reserved for legacy Token Ring/FDDI); the extended range is 1006–4094. VLAN 1 is the default VLAN and cannot be deleted.

👉 Interview tip: Say "1–4094 are configurable, VLAN 1 is the default, and 0/4095 are reserved."

An access port belongs to exactly one VLAN and carries untagged traffic for that single VLAN. You connect end devices — PCs, printers, IP phones, APs — to access ports. The device has no idea VLANs exist.

A trunk port carries traffic for many VLANs over one link, tagging each frame with its VLAN ID using 802.1Q. You use trunks between switches, or from a switch to a router/firewall doing inter-VLAN routing.

Analogy: an access port is a single-tenant doorway; a trunk is a multi-lane highway where each car wears a VLAN "license plate" so the far end knows which VLAN it belongs to.

• Access: switchport mode access + switchport access vlan 10
• Trunk: switchport mode trunk (+ optionally switchport trunk allowed vlan to limit which VLANs cross)

👉 Interview tip: "Access = one VLAN to a host; trunk = many VLANs between switches."

802.1Q is the IEEE standard for VLAN trunking. As a frame leaves a trunk, the switch inserts a 4-byte tag (carrying the 12-bit VLAN ID) into the Ethernet frame, between the source MAC address and the EtherType field, so the receiving switch knows which VLAN the frame belongs to. This lets one cable carry dozens of VLANs.

The native VLAN is the one exception: its frames cross the trunk untagged. This was originally for backward compatibility with devices that don't understand tags. Both ends must agree on the native VLAN (default is VLAN 1) — a mismatch is detected and logged by CDP and causes traffic from the two native VLANs to be merged incorrectly.

Set it with switchport trunk native vlan 999. Best practice: change it to a dedicated unused VLAN and avoid VLAN 1, because untagged native traffic is what enables VLAN-hopping (double-tagging) attacks.

👉 Interview tip: Mention that hardening the native VLAN (a dedicated unused VLAN) prevents double-tagging attacks — security awareness scores points.

STP (IEEE 802.1D) exists to prevent Layer 2 loops while still allowing redundant physical links. Switches need redundant cabling for failover, but redundancy plus Layer 2 forwarding creates loops.

Ethernet frames have no TTL field (unlike IP), so a looping frame is never discarded. Without STP, three things go wrong fast:

• Broadcast storm — a single broadcast circulates forever, multiplying until it saturates links and CPUs.
• MAC table instability (flapping) — the same source MAC arrives on multiple ports, so the switch constantly relearns it, corrupting the address table.
• Duplicate/multiplied frames — endpoints receive many copies of unicast frames.

The network effectively melts down within seconds. STP solves this by logically blocking redundant ports, leaving one loop-free active path, and re-enabling backups only when the primary fails.

👉 Interview tip: The killer line is "Ethernet has no TTL, so loops never self-heal."

Switches elect a single root bridge by exchanging BPDUs and comparing each other's Bridge ID (BID). The lowest BID wins.

The BID is 8 bytes:

• Bridge Priority (the high 4 bits of the 2-byte priority field) — default 32768, configurable in multiples of 4096.
• System ID Extension (the low 12 bits of that same 2-byte field) — holds the VLAN number in PVST+.
• MAC address (6 bytes) — the switch's base MAC.

Election logic: compare the priority value first; whoever is lowest becomes root. If priorities tie (common, since everyone defaults to 32768), the tie-breaker is the lowest MAC address. Because older switches usually have lower MACs, the root can land on the weakest box — which is why you tune priority manually.

Analogy: lowest "seniority number" wins; if two people share a number, the older employee (lowest MAC) wins.

👉 Interview tip: Always add "effective priority = configured priority + VLAN ID" (because of the System ID Extension in PVST+).

Legacy 802.1D STP converges slowly — roughly 30–50 seconds (15s listening + 15s learning, plus up to 20s of max-age for indirect link failures). RSTP (802.1w) converges in sub-second to a few seconds by using proposal/agreement handshakes and new port roles (Alternate, Backup) that are pre-computed as backups, plus edge ports that forward instantly.

Where to apply the features:

• PortFast — on access/edge ports facing hosts. Skips listening/learning so PCs/phones get a link immediately. Never on switch-to-switch links.
• BPDU Guard — pair it with PortFast on edge ports. If a BPDU arrives (someone plugged in a switch), the port err-disables — stopping loops and rogue switches.
• Root Guard — on ports facing downstream/peer switches that should never become root. If a superior BPDU arrives, the port goes root-inconsistent (blocking), protecting your chosen root, and recovers automatically once the superior BPDU stops.

👉 Interview tip: "PortFast+BPDU Guard on access edges; Root Guard toward switches that shouldn't be root."

EtherChannel bundles the 4 links into one logical interface (Port-channel), giving up to ~4 Gbps aggregate and redundancy — if one link dies, traffic shifts to the rest, and STP sees one logical link (no blocking). Note: a single flow is hashed onto one member link, so one conversation maxes out at 1 Gbps; the ~4 Gbps is across many flows.

Config per member port: channel-group 1 mode active, then tune the logical interface port-channel 1. All members must match speed, duplex, and VLAN/trunk settings.

• LACP (802.3ad, open standard) — negotiates with active/passive. Preferred today.
• PAgP — Cisco-proprietary, uses desirable/auto.
• Static (mode on) — forces the bundle with no negotiation; risky because a misconfig can cause loops.

A pairing that fails: passive on both ends (neither side initiates), or auto/auto in PAgP. Also mixing on with active fails — one side negotiates, the other doesn't, so the bundle never forms.

👉 Interview tip: Memorize the working combos: active-active, active-passive, desirable-desirable, desirable-auto, and on-on. Passive-passive and auto-auto FAIL.

Router-on-a-stick uses one router physical link as a trunk, split into subinterfaces (one per VLAN, each with encapsulation dot1Q + a gateway IP). Cheap and simple, but every inter-VLAN packet hairpins up and back down the single trunk — that link is both a throughput bottleneck and a single point of failure.

A Layer 3 switch with SVIs creates a virtual routed interface (interface vlan 10) per VLAN and routes in hardware (ASICs) at wire speed. No trunk hairpin, far higher throughput, and you can add redundancy with stacking/HSRP/VRRP.

For a 12-VLAN access layer, pick the Layer 3 switch with SVIs: 12 VLANs of inter-VLAN traffic would crush a single router trunk, whereas hardware routing scales effortlessly and removes the single-link dependency.

Analogy: router-on-a-stick is one cashier for 12 queues; an L3 switch gives every queue its own fast lane.

👉 Interview tip: Say "SVIs route in hardware/ASIC at wire speed" — that phrase wins it.

To force a chosen switch to be root, lower its bridge priority below everyone else's. The clean way: spanning-tree vlan 1-100 root primary (a Cisco macro that sets priority to 24576, or lower if a bridge with an even lower priority already exists), and on the backup switch root secondary. Or set it explicitly: spanning-tree vlan 10 priority 4096 (must be a multiple of 4096). Lowest priority wins the election, so your switch becomes and stays root.

The threat: a rogue/misconfigured switch with an even lower priority would steal the root role, redirecting traffic through it (a possible MITM, or a slow link suddenly becoming the core path).

Protection — Root Guard on the designated ports facing downstream switches: spanning-tree guard root. If a superior BPDU arrives there, the port enters root-inconsistent (blocking) state and recovers automatically once the superior BPDU stops. Add BPDU Guard on access edge ports to err-disable any port where a switch (any BPDU) appears at all.

👉 Interview tip: Root primary/secondary + Root Guard is the textbook pairing.

The decision turns on how much Layer 2 you actually need. Three patterns:

• Traditional STP — simplest to reason about, but ~half your uplinks sit blocked, convergence is slow (seconds even with RSTP), and STP is fragile at scale. Fine for small/legacy sites.
• EtherChannel / MLAG (vPC, StackWise, VSS) — two distribution switches act as one logical peer, so all uplinks forward (no STP blocking), giving full bandwidth and sub-second failover. Best when you need stretched VLANs/L2 mobility. Cost: tighter coupling and more complex peer-link/orphan-port care.
• Routed access — push Layer 3 down to the access switch; STP domains shrink to a single switch. Fastest, most stable convergence (just an IGP reroute), scales hugely. Trade-off: loses the ability to span a VLAN across multiple switches, and needs disciplined IP/subnet planning.

My weighting: prefer routed access for a greenfield campus (stability + scale); use MLAG where L2 adjacency must span the distribution; reserve pure STP for small sites. Always keep STP enabled as a safety net even in routed designs.

👉 Interview tip: "Minimize the STP domain" — leading with that signals senior thinking.

The command on a Cisco IOS router is:

• ip route 0.0.0.0 0.0.0.0 203.0.113.1

This creates a static default route (often called the gateway of last resort) sending any traffic the router doesn't have a more specific route for to next-hop 203.0.113.1.

0.0.0.0/0 means all destinations. The /0 prefix length means zero bits must match, so it matches every possible IP address. Think of it as the "if nothing else matches, send it here" rule — like a mail sorting room where unaddressed letters all go to one default bin.

Because its prefix is /0 (the shortest possible), any more specific route always wins over it via longest-prefix match.

Interview tip: You can also point a static route out an interface (ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0), but on a multi-access link (e.g. Ethernet) that forces the router to treat every destination as directly attached and ARP for each one, which depends on proxy ARP and is fragile. Specifying the next-hop IP is therefore preferred; on a point-to-point link the interface form is fine.

Administrative distance (AD) is a router's measure of how trustworthy a routing source is. When two different protocols offer a route to the same destination, the router installs the one with the lower AD into the routing table. Lower = more believable. Think of it as ranking advisors: you trust the one with the most credibility first.

Standard Cisco AD values:

• Connected: 0 (directly attached, most trusted)
• Static: 1
• eBGP: 20
• OSPF: 110
• RIP: 120

(For reference: EIGRP internal = 90, iBGP = 200, and an unreachable/unusable route shows AD 255.)

AD is local to the router and is only used to choose between different sources — it does not compare routes within the same protocol (metric does that).

Interview tip: Note eBGP (20) is lower than OSPF (110) so external BGP routes beat internal OSPF — a deliberate design choice.

Distance-vector protocols share their entire routing table with directly connected neighbors periodically. Each router only knows direction (vector) and distance (hop count/metric) — it trusts what neighbors tell it ("routing by rumor"). Slower convergence and prone to loops, mitigated by split horizon and hold-down timers. Example: RIP (and EIGRP is an advanced distance-vector protocol).

Link-state protocols flood link-state advertisements (LSAs) so every router builds an identical map of the whole topology, then independently runs the SPF (Dijkstra) algorithm to compute best paths. Faster convergence, loop-free, but more CPU/memory. Example: OSPF (also IS-IS).

Analogy: distance-vector is asking each neighbor "how far to X?" and trusting them; link-state is everyone sharing a full city map so each driver plots their own route.

Interview tip: Say RIP = distance-vector, OSPF = link-state, EIGRP = advanced distance-vector — interviewers love that distinction. (Cisco historically called EIGRP "hybrid," but it is best described as advanced distance-vector.)

The router decides in this strict order:

1. Longest prefix match wins FIRST. The router picks the most specific route — the one with the longest matching subnet mask. A /24 beats a /16 beats a /0 for an address inside it, regardless of protocol or metric.
2. Administrative distance (AD) — used only when two routes have the same prefix length but come from different sources (e.g. OSPF vs static). Lower AD wins.
3. Metric — used only to break ties between two routes from the same protocol with the same prefix and AD (e.g. two OSPF paths). Lower metric wins.

So the question's order is correct: longest prefix → AD → metric. Prefix length is checked before AD ever matters.

Analogy: first match the most specific address on the envelope; only if two are equally specific do you compare how trustworthy the source is, then the cost.

Interview tip: A common trap — a more specific route with a HIGHER AD still wins, because prefix length is evaluated first.

A floating static route is a static route configured with an artificially raised administrative distance so it is not used while a better (lower-AD) route exists. It "floats" unused in the background and only installs into the routing table when the primary route disappears.

Its main use is backup/failover — for example a static route backing up a primary OSPF/EIGRP path, or a backup ISP link that only activates if the main link fails.

You create one by appending an AD value higher than the primary route's AD. To back up an OSPF route (AD 110):

• ip route 0.0.0.0 0.0.0.0 198.51.100.1 130

The trailing 130 sets this static route's AD to 130, so OSPF (110) is preferred; if OSPF withdraws the route, the floating static activates.

Analogy: a spare tyre in the boot — present but only used when the main tyre fails.

Interview tip: The backup AD must be HIGHER than the primary's AD, not lower — getting that backwards breaks failover. Also note the route only withdraws when the next-hop/route is actually lost; pair it with IP SLA tracking if you need failover on a link that stays "up" but is black-holing.

Router-ID: a unique 32-bit ID (written in dotted-decimal like an IP) identifying each OSPF router. By default it is the highest configured loopback IP, else the highest active interface IP, unless set manually with router-id (manual/loopback is recommended for stability).

SPF/Dijkstra: routers flood LSAs to build an identical link-state database (the topology map), then each independently runs the Dijkstra SPF algorithm to compute the lowest-cost (shortest) path tree to every destination. OSPF cost is derived from interface bandwidth (cost = reference-bandwidth / interface-bandwidth).

Area 0 (backbone): OSPF is hierarchical — all other areas must connect to Area 0, which carries inter-area traffic. This limits LSA flooding and SPF scope to within an area, aiding scalability.

DR/BDR election: on multi-access segments (e.g. broadcast Ethernet), routers elect a Designated Router (DR) and Backup (BDR) by highest OSPF interface priority, then highest router-ID as the tiebreaker. All routers form full adjacencies only with the DR and BDR.

Why a DR? Without it, n routers on the segment would form n(n-1)/2 full adjacencies and flood LSAs redundantly. The DR centralizes LSA exchange (others talk to it via 224.0.0.6), slashing adjacencies and flooding.

Interview tip: Priority 0 means a router never becomes DR; DR/BDR election is NOT preemptive, so a higher-priority router added later won't take over until the current DR fails.

OSPF — open-standard link-state IGP. Choose it for internal routing in a multi-vendor enterprise: fast convergence, hierarchical areas, and vendor-neutral. Best when you need an open standard.

EIGRP — Cisco's advanced distance-vector IGP (published as informational RFC 7868, so other vendors can implement it). Choose it in a Cisco-centric network for simple config, fast convergence via feasible successors (DUAL), and unequal-cost load balancing.

BGP — the path-vector protocol of the internet. Choose it for inter-domain/edge routing between autonomous systems — connecting to ISPs, multihoming, and applying policy on huge route tables. It scales to internet size but converges slowly; it's a policy tool, not an IGP.

Combined scenario: An enterprise runs OSPF internally for fast, dynamic reachability between its own sites/subnets. At the edge it runs eBGP to two ISPs for redundancy and to control inbound/outbound path policy (AS-path prepending, local preference). You don't run BGP internally as your IGP (overkill, slow to converge) nor share OSPF with the ISPs (you don't expose your internal topology/IGP to another organisation). Each protocol does the job it's built for.

Interview tip: Frame it as "IGP inside (OSPF/EIGRP) for reachability, EGP outside (BGP) for policy."

Traffic to 10.1.1.5 uses the 10.1.1.0/24 connected route.

Why: the address 10.1.1.5 falls inside all three routes, but the router applies longest prefix match first. /24 is more specific than /16, which is more specific than /8, so the /24 wins outright. Prefix length is decided before AD or metric is even considered.

AD vs metric:

• Administrative distance (AD) ranks different routing sources for the same prefix. Here connected = 0, static = 1, OSPF = 110 — but AD never gets compared in this case because the prefixes differ.
• Metric ranks multiple routes from the same protocol with the same prefix and AD (e.g. two OSPF paths of differing cost). It also isn't used here.

So the deciding factor is purely specificity (prefix length), not AD or metric. AD and metric only become tiebreakers when prefix lengths are equal.

Interview tip: Even though connected happens to have the lowest AD, that's a coincidence — the /24 would win on prefix length even if its AD were higher.

Route summarization (aggregation) combines many specific subnets into one advertised supernet — e.g. 10.1.0.0/24 through 10.1.255.0/24 advertised as a single 10.1.0.0/16. In OSPF this is done at ABRs (inter-area) or ASBRs (external); in EIGRP it can be done on any interface.

Why it matters: it shrinks routing tables, reduces LSA/update flooding, and localizes failures — a flapping subnet behind the summary boundary doesn't trigger SPF recalculation everywhere. This improves stability and scales the design.

Risk of wrong-boundary summarization: if you advertise a summary covering addresses that don't all live behind that router, you create a blackhole — the router attracts traffic for the whole block but silently drops packets for the missing/unreachable subnets, since the specific routes no longer propagate. (Cisco mitigates this by automatically installing a Null0 discard route for the summary on the advertising router, which prevents loops but still drops the traffic — the blackhole remains for genuinely misplaced subnets.)

Convergence interaction: summarization hides specific changes, so the rest of the network doesn't reconverge on every internal flap (good for stability) — but it also means the network is slower to notice a genuinely dead subnet inside the summary, prolonging the blackhole.

Interview tip: Summarize at hierarchy boundaries with contiguous addressing; bad IP planning makes clean summarization impossible.

Protocol boundaries: Run an IGP (OSPF or EIGRP) inside each data centre and the core/WAN for fast internal convergence. Use BGP at the edges — eBGP to ISPs/internet, and BGP (often over the SD-WAN or MPLS overlay) between regions and to branches, so policy and scale live in BGP while reachability lives in the IGP. Redistribute carefully and in a controlled direction where the two meet, using route tags and filtering to prevent loops or route feedback.

Addressing & summarization: Give each DC and each region a contiguous block so you can summarize at region boundaries — shrinking tables and localizing flaps across 30+ sites.

Failover & asymmetry: Make one DC primary per service using BGP local-preference (controls outbound) and AS-path prepend / MED (influences inbound) so traffic is deterministic and symmetric — critical because stateful firewalls drop asymmetric flows. Use consistent metrics and summarization so both directions prefer the same path, and track liveness with BFD for sub-second failover detection.

Supportability for L1/L2: Standardize one branch template, consistent naming/IP scheme, documented "primary/backup" intent, and heavy use of summarization so the routing table stays small and readable. Prefer SD-WAN centralized policy and dashboards over hand-tuned per-device CLI, and provide runbooks for the common failover scenarios.

Interview tip: Stress symmetric routing for stateful firewalls, and "keep it boring and templated" so junior staff can operate it.

RFC 1918 reserves three IPv4 blocks for use inside private networks. They are not routable on the public internet, so anyone can reuse them without conflict.

• Class A: 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
• Class B: 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
• Class C: 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

They exist to conserve scarce public IPv4 addresses. Internal hosts share a few public IPs through NAT/PAT at the router. Think of it like office extension numbers: everyone has a short internal number, but the building shares one public phone line outward.

Interview tip: Mention NAT in the same breath - private ranges only work because NAT translates them to a public IP at the edge.

Working it out loud: /26 means 26 network bits, so 6 host bits remain. The mask is 26 ones = 255.255.255.192 (the last octet 192 = 11000000).

• Block size: 256 - 192 = 64, so subnets step in 64s: .0, .64, .128, .192.
• This subnet: network 192.168.10.0, next boundary is .64.
• Broadcast: one below the next subnet = 192.168.10.63.
• Valid host range: 192.168.10.1 to 192.168.10.62.
• Usable hosts: 2^6 - 2 = 62 (minus network and broadcast).

Interview tip: Always say the block-size method out loud (256 - mask) - it shows you can subnet without a calculator.

A subnet mask marks which bits of an IP are the network portion and which are the host portion. The 1-bits = network, 0-bits = host.

When a host wants to send a packet, it does a bitwise AND of its own IP with its mask to get its own network ID, then ANDs the destination IP with the same mask. It compares the two results:

• Same network ID -> destination is local; the host ARPs for the destination directly and delivers on the LAN.
• Different network ID -> destination is remote; the host sends the frame to its default gateway to route onward.

Analogy: the mask is like reading a postal code - same code means hand-deliver next door, different code means drop it at the post office (gateway).

Interview tip: Stress it is a local decision the host makes before sending - not the router's job.

Starting address: 2001:0db8:0000:0000:0000:00ff:0000:0001.

Rule 1 - drop leading zeros in each hextet: 0db8->db8, 0000->0, 00ff->ff, 0001->1. That gives 2001:db8:0:0:0:ff:0:1.

Rule 2 - replace ONE run of consecutive all-zero hextets with ::. The longest run is the three middle zeros, so collapse them: 2001:db8::ff:0:1.

• You may use :: only once per address (otherwise it is ambiguous).
• The trailing single 0 stays - it is isolated, not part of the collapsed run.

Interview tip: If two zero-runs tie in length, collapse the left-most; never use :: twice.

A link-local IPv6 address is valid only on the single local link/segment - routers never forward it off the subnet. Every IPv6-enabled interface gets one automatically.

• Prefix: fe80::/10 (in practice addresses look like fe80::/64, with the interface ID typically from EUI-64 or randomized).
• When generated: automatically the moment IPv6 is enabled on the interface - no DHCP, no router, no manual config needed.

It is essential plumbing: hosts use it for Neighbor Discovery (NDP), and routers use their link-local address as the next-hop in routing and as the source of Router Advertisements.

Analogy: it is like a room-only intercom - works inside one room but the message never leaves the building.

Interview tip: Note OSPFv3 neighbors form using link-local addresses, not global ones.

With VLSM you allocate largest-first, choosing the smallest prefix that fits each site:

• 500 hosts -> /23 (510 usable): 172.16.0.0/23 (range .0.0 - .1.255)
• 200 hosts -> /24 (254 usable): 172.16.2.0/24
• 60 hosts -> /26 (62 usable): 172.16.3.0/26
• 10 hosts -> /28 (14 usable): 172.16.3.64/28

Why VLSM wins: fixed-length subnetting forces every subnet to the size of the largest (/23 here), so the 10-host site would waste ~500 addresses. VLSM right-sizes each block, conserving address space and leaving room to grow.

Interview tip: Always allocate largest subnet first - doing small ones first fragments the space and causes overlaps.

EUI-64 turns a 48-bit MAC into a 64-bit interface ID in three steps:

1. Split the MAC and insert FFFE in the middle (e.g. 00:1A:2B:3C:4D:5E -> 001A:2BFF:FE3C:4D5E).
2. Flip the 7th bit of the first byte (the universal/local bit): 00 -> 02.
3. Result: interface ID 021A:2BFF:FE3C:4D5E, appended to the /64 prefix.

SLAAC (stateless): the host learns the /64 prefix from a Router Advertisement, then self-generates the host bits (via EUI-64 or random/privacy). No server, no per-host tracking.

DHCPv6 (stateful): a server hands out the full address and tracks leases - and crucially also delivers DNS/options, which classic SLAAC lacks.

Interview tip: Many networks run SLAAC for the address plus stateless DHCPv6 just for DNS. Note that modern OSes often prefer randomized/privacy interface IDs over EUI-64.

Dual-stack runs IPv4 and IPv6 simultaneously on the same interfaces - each host has both an IPv4 and IPv6 address, and apps pick a protocol per connection. It is the recommended migration path because there is no translation in the data path.

Operational headaches to call out:

• DNS: A and AAAA records both exist; clients try IPv6 first but Happy Eyeballs (RFC 8305) races both and falls back fast. A broken-but-present AAAA record can still cause delays on clients without Happy Eyeballs.
• Troubleshooting: two routing tables, two ARP/NDP planes - you must check both stacks for every issue.
• ACLs/security: every IPv4 rule needs an equivalent IPv6 rule, or you silently open a back door.
• MTU: IPv6 forbids router fragmentation and relies on PMTUD; blocked ICMPv6 breaks it (black-hole connections).

Interview tip: Stress never block ICMPv6 like you might block ICMPv4 - NDP and PMTUD depend on it.

I design hierarchically and on bit boundaries so each region/site summarizes into one route. From 10.0.0.0/8 I carve regional blocks (e.g. 10.0.0.0/13 per region, which holds eight /16 sites), then per-site blocks (e.g. 10.x.0.0/16), then VLSM the VLANs inside each site.

• Reserve generously up front: allocate room for ~double the 40 sites so growth does not force renumbering.
• Keep allocations contiguous and aligned so a region advertises a single summary upstream - shrinking routing tables and speeding convergence.
• Document an IPAM source of truth and standardize VLAN-to-subnet mapping so every site looks the same.

What I refuse to do: hand out random or just-big-enough blocks that cannot summarize, overlap with future M&A or VPN partners, or sit on non-bit boundaries. That guarantees painful renumbering later.

Interview tip: Frame it as 'summarization is a design-time decision, not a config knob.'

I translate the technical into business outcomes. 'IPv4 exhaustion' becomes: 'The world has run out of new internet addresses, so buying more costs real money (a single public IPv4 address now trades for roughly 35 to 55 US dollars) and limits how fast we can grow.'

• Growth & reach: IPv6 lets us scale customers, IoT, and new sites without buying scarce IPv4 or stacking fragile NAT layers.
• Cost: avoid recurring IPv4 lease/purchase costs and CGNAT licensing.
• Risk of inaction: some partners and markets (mobile, regions) are already IPv6-first; lagging risks reachability and compliance.

Costs/risks I flag: staff training, dual-stack run period, ACL/security parity work, and vendor/app readiness testing. I propose a phased dual-stack rollout, not a big-bang cutover, to cap risk.

Interview tip: Lead with revenue/growth and risk, not protocol features - leaders fund outcomes, not headers.

I go bottom-up the OSI model, which maps neatly to a widening ping test:

1. L1/L2 physical & link: is the cable/Wi-Fi up? ipconfig /all (PC) or show ip interface brief (router) - confirm the interface is up/up and has an IP.
2. Loopback: ping 127.0.0.1 - validates the local TCP/IP stack.
3. Own IP / default gateway: ping <gateway> - confirms LAN reachability.
4. Beyond the gateway: ping 8.8.8.8 - tests routing to the internet (L3).
5. DNS: ping google.com / nslookup google.com - if the IP pings but the name fails, it is DNS, not routing.

Each step isolates one layer, so I find the break instead of guessing.

Interview tip: Saying 'if 8.8.8.8 works but the name fails, it is DNS' instantly signals structured thinking.

Administratively down means the interface was manually disabled with shutdown - it is not a fault, it is a config state. Fix it in interface config mode:

• interface gi0/1 then no shutdown.

The two columns in show ip interface brief are Status (Layer 1/2) and Protocol (Layer 2 line protocol). Common combinations:

• up / up: healthy and passing traffic.
• administratively down / down: shut down by config -> no shutdown.
• down / down: physical problem - cable, SFP, dead far end, speed/duplex mismatch.
• up / down: Layer 1 fine but Layer 2 failing - encapsulation mismatch, keepalive/clocking issue, or no clock rate on a serial DCE.

Interview tip: Memorize that 'up/down' usually means a Layer 2 mismatch - it is a classic exam favorite.

A 169.254.x.x address is APIPA (link-local, 169.254.0.0/16). It tells me the PC is set to DHCP but never got a reply from a DHCP server, so it self-assigned. The machine can only talk to other APIPA hosts on the same segment - no gateway, no internet.

What I check first, in order:

• Physical/link: cable plugged in, link light, correct VLAN on the switchport.
• DHCP server/scope: is it running, and is the scope exhausted (no free leases)?
• Path to DHCP: if the server is on another subnet, is the ip helper-address configured on the router/SVI to relay DHCP discovers?

Analogy: the PC called for an address, nobody answered, so it picked a temporary nickname that only the people in the same room recognize.

Interview tip: Mention ip helper-address - it is the top cause when DHCP works on one VLAN but not another.

Ping only tells you pass/fail and round-trip time to the final destination. Traceroute reveals the full hop-by-hop path - every router in between and the latency to each.

It works by sending packets with increasing TTL (1, 2, 3...). Each router that decrements TTL to zero returns an ICMP Time Exceeded, so you learn that hop's address and timing. (Windows tracert sends ICMP Echo probes; classic Unix traceroute uses UDP - either way the TTL trick is the same.)

To localize a drop, I read the hop list:

• Hops respond normally until a point, then show * * * (timeouts) - the break is at or just after the last responding hop.
• A sudden latency jump flags a congested or distant link.
• Repeating/looping hops indicate a routing loop.

Analogy: ping asks 'did the letter arrive?'; traceroute lists every post office it passed through.

Interview tip: Note some firewalls drop the probes/ICMP traceroute relies on, so * * * at the destination can be a filter, not a real outage.

Same-VLAN works, cross-VLAN fails - so Layer 2 within each VLAN is fine; the break is in the routing path between them. I isolate top-down:

1. Gateway first: from each PC, ping <its own default gateway>. If a PC cannot reach its gateway, the SVI/router subinterface is down or the PC has the wrong gateway/mask.
2. Inter-VLAN routing: on the L3 device, show ip interface brief - are both SVIs up/up? Is ip routing enabled on the L3 switch? Check the routing table for both subnets.
3. Trunking: show interfaces trunk - is the uplink a trunk, and are both VLANs allowed and not pruned? A missing VLAN on the trunk allowed-list is a classic cause.

This narrows it to gateway (PC/SVI), routing (L3 config), or trunk (allowed-VLAN list) quickly.

Interview tip: Always verify both SVIs are up and the trunk allows both VLANs - one missing VLAN silently breaks inter-VLAN routing.

Err-disabled is a protective shutdown the switch triggers when it detects a violation. Likely causes:

• Port security violation (too many/wrong MACs).
• BPDU Guard firing on a PortFast port that received a BPDU (rogue switch/loop).
• Storm control, duplex/link-flap (errors), EtherChannel/UDLD misconfig.

Confirm the cause: run show interfaces status err-disabled for the reason, and show logging for the exact event - the syslog line names the trigger (e.g. PSECURE_VIOLATION or BPDUGUARD).

Recover safely: first fix the root cause (remove the rogue device, correct port-security). Then bounce the port: shutdown then no shutdown. Optionally enable errdisable recovery cause <reason> with a timer for auto-recovery.

Interview tip: Always say 'fix the cause before re-enabling' - blindly bouncing the port just re-triggers it.

Symptoms of a broadcast storm/loop: sluggish or unreachable network, switch CPU pegged near 100%, link LEDs blinking in unison, MAC table flapping (same MAC bouncing between ports), and duplicate frames.

Confirm with:

• show processes cpu - high CPU from broadcast/ARP input.
• show interfaces - skyrocketing input/broadcast counters and drops.
• show mac address-table - the same MAC appearing on multiple ports = flapping.
• show spanning-tree - check for an unstable/blocked-port topology.

Immediate containment: shut the looping/suspect port to stop the storm and restore service.

Permanent fix: ensure Spanning Tree (STP/RSTP) is enabled and tuned, and harden edge ports with PortFast + BPDU Guard and storm-control so a future loop is auto-contained.

Interview tip: Separate the two clearly - 'contain by shutting the port, prevent recurrence with STP + BPDU Guard.'

First, do no further harm: I confirm what changed by reviewing the change ticket and configs, and I prepare to roll back if needed rather than improvising new changes on a live outage.

Then I prove it methodically:

• Scope the blast radius: which subnets/VLANs are down vs up - this tells me if one path/uplink failed.
• Trace both directions: traceroute from the affected site outward and from a remote site back in. If forward and return paths differ, that confirms asymmetric routing (often biting stateful firewalls that drop one-way flows).
• Check failover state: show ip route, HSRP/VRRP active-standby (show standby), and routing-protocol neighbors - did the backup path actually take over or black-hole?

I make read-only show/trace calls first, and stage any fix in a maintenance step with rollback ready.

Interview tip: Emphasize evidence-before-action and a rollback plan - that is what separates senior from junior under pressure.

I avoid finger-pointing by leading with shared data, not opinions. I structure it as a hypothesis test:

• Reproduce & timestamp: get exact failing requests, hostnames, and times to correlate with logs.
• DNS hypothesis: nslookup/dig the app's hostnames - check for slow resolvers, stale records, or split-horizon mismatches. Compare resolution time vs connect time.
• MTU hypothesis: test path MTU with ping using the DF (don't-fragment) bit and increasing sizes (large packets fail while small succeed = MTU/black-hole, often a VPN/tunnel reducing MTU and blocked ICMP breaking PMTUD).
• Capture: a packet trace shows whether the SYN/handshake even reaches the server.

I then share a neutral written summary with evidence and a concrete fix (clamp MSS / adjust MTU, fix DNS TTL), framed as 'here's what the data shows,' not 'your app is broken.'

Interview tip: Emphasize evidence + neutral language - collaboration solves intermittent issues faster than blame.

I run two tracks in parallel: the technical fix and executive communication.

Technical track: establish a single incident commander (me), assign clear owners (don't let everyone debug the same thing), scope the blast radius, form a hypothesis, and review the last change for a rollback first. I make read-only diagnostics before any risky change and keep a running timeline.

Executive track: I translate jargon into impact and time:

• Impact: 'Two of five sites can't process orders, affecting roughly X users.'
• Status & ETA: 'We've isolated it to a failed routing change; rollback in progress, expected restore ~20 minutes.'
• Risk: state confidence and the fallback plan plainly, and give a regular update cadence (e.g. every 15 minutes) so leaders aren't refreshing for news.

Interview tip: Show you can shield the working engineers from the bridge while still giving leadership crisp, honest updates - that is the escalation-lead skill.