Back to Blogs

CCNP Interview Questions and Answers Part 1: Questions 1 to 50

Prepare for CCNP interviews with questions 1 to 50 covering OSPF, BGP, EIGRP, redistribution, campus switching, STP, HSRP, and enterprise routing decisions. This part keeps the original interview-style structure and includes the "what the interviewer is actually testing" notes so you can prepare both the answer and the intent behind it.

CCNPInterview PrepRoutingSwitchingPart 1
CCNP Interview Questions and Answers Part 1: Questions 1 to 50 cheat sheet: use this quick map before reading the detailed sections.
3-part learning path

CCNP Interview Question Series

Work through 150 practical networking interview questions in three ordered sets.

Part 1 of 3
Lesson overview

In This Lesson

Work through the first 50 CCNP interview questions with explanations you can adapt to real conversations. Focus on explaining behavior, verification, and trade-offs rather than reciting definitions.

  1. Questions 1 to 10
  2. Questions 11 to 20
  3. Questions 21 to 30
  4. Questions 31 to 40
  5. Questions 41 to 50
From concept to practice

Quick Learning Map

Keep this three-step view in mind as you work through the detailed lesson.

1

Explain the concept

State what the technology does and why a network uses it.

2

Show operational depth

Add a command, packet flow, or design example.

3

Close with verification

Describe how you would prove the network is working.

Fast orientation

CCNP Interview Questions and Answers Part 1: Questions 1 to 50 at a Glance

Use this summary before moving into the detailed explanations, examples, commands, and checks.

Core focus

Work through the first 50 CCNP interview questions with explanations you can adapt to real conversations.

Key connection

Explain the concept → Show operational depth → Close with verification

Practical outcome

Focus on explaining behavior, verification, and trade-offs rather than reciting definitions.

Questions 1 to 10

Q1. Explain how OSPF neighbor adjacency is formed and what conditions must match for a full adjacency. How would you troubleshoot if neighbors are stuck in INIT or EXSTART state?

In OSPF, neighbor adjacency formation starts with the exchange of Hello packets. These Hello packets must match on key parameters such as area ID, subnet, hello and dead intervals, authentication type, and network type. Once Hellos are exchanged successfully, routers move through states like INIT, 2-WAY, EXSTART, EXCHANGE, LOADING, and finally FULL. In broadcast and NBMA networks, DR and BDR election also influences whether a full adjacency is formed.

If neighbors are stuck in the INIT state, it usually means Hellos are being received but not acknowledged back. This often points to issues like unidirectional communication, ACLs blocking multicast traffic (224.0.0.5/6), or incorrect network type. EXSTART issues are commonly caused by MTU mismatches, duplicate router IDs, or issues during master-slave negotiation for database exchange.

From a troubleshooting perspective, I would first verify interface parameters using show ip ospf interface, check MTU consistency, confirm router IDs, and validate that no intermediate firewall or ACL is blocking OSPF packets. Packet capture using Wireshark can also help identify whether DBD packets are being dropped during EXSTART.

What the interviewer is actually testing:

They want to see if you understand OSPF as a state machine, not just configuration. They are checking whether you can logically narrow down failures instead of randomly changing configs.

Q2. Differentiate between OSPF Stub, Totally Stub, NSSA, and Totally NSSA areas. Where would you use each in a real enterprise network?

OSPF special area types are primarily used to reduce routing table size and LSA flooding. A Stub area blocks Type 5 external LSAs and relies on a default route from the ABR. Totally Stub goes one step further by also blocking Type 3 summary LSAs, leaving only intra-area routes and a default route. This is useful in branch locations where full routing visibility is unnecessary.

NSSA is designed for areas that need limited external connectivity. It allows external routes to be injected as Type 7 LSAs, which are then translated to Type 5 by the ABR. Totally NSSA further restricts inter-area routes, similar to Totally Stub, while still allowing limited external injection.

In real enterprise networks, I've seen Totally Stub used in small branch offices and NSSA used in DMZ or edge segments where limited redistribution from firewalls or legacy routers is required without exposing the entire network routing table.

What the interviewer is actually testing:

They're testing whether you can map theory to topology design decisions, not just recite LSA types.

Q3. Explain OSPF LSA types and their role in route calculation. Which LSAs would you expect in a multi-area enterprise network?

OSPF uses LSAs to describe network topology. Type 1 (Router LSA) and Type 2 (Network LSA) exist within an area and describe routers and broadcast segments. Type 3 (Summary LSA) is generated by ABRs to advertise inter-area routes, while Type 4 advertises ASBR reachability.

Type 5 LSAs carry external routes redistributed into OSPF.

In a multi-area enterprise design, you would commonly see Type 1 and 2 LSAs within each area, Type 3 LSAs between areas, and possibly Type 5 LSAs if redistribution from BGP or static routes is involved. In NSSA areas, Type 7 LSAs would replace Type 5 internally.

Understanding LSA scope is critical during troubleshooting because excessive LSAs can cause CPU spikes or slow convergence. Tools like show ip ospf database help identify abnormal LSA flooding.

What the interviewer is actually testing:

They want to confirm you understand why OSPF scales and how LSA control affects performance and stability.

Q4. How does OSPF calculate cost and how would you manipulate path selection in an enterprise environment?

OSPF cost is derived from interface bandwidth using the formula reference-bandwidth divided by interface bandwidth. By default, the reference bandwidth is 100 Mbps, which is insufficient for modern networks. In enterprise environments, this is usually adjusted to 10G or 100G to ensure proper path differentiation.

Path manipulation can be done by changing interface bandwidth, adjusting OSPF cost manually, or modifying reference bandwidth consistently across routers. In critical links like data center uplinks or WAN paths, manual cost tuning ensures predictable routing behavior.

During troubleshooting, inconsistent reference bandwidth across routers can lead to asymmetric routing or unexpected path selection. This is a common but often overlooked issue.

What the interviewer is actually testing:

They are checking whether you understand design consistency, not just cost commands.

Q5. Explain OSPF DR/BDR election and its impact on convergence and scalability.

In broadcast and NBMA networks, OSPF elects a DR and BDR to reduce adjacency count. The election is based on interface priority first, then router ID. Once elected, the DR remains unless it fails, even if a higher-priority router joins later.

DR/BDR reduces LSA flooding overhead but introduces convergence dependency on the DR.

In large VLANs or poorly designed segments, DR failure can temporarily impact convergence.

Best practice is to control DR election using interface priorities and avoid unnecessary large broadcast domains in enterprise networks.

What the interviewer is actually testing:

They want to see if you understand OSPF behavior under failure, not just elections.

Q6. What is OSPF route summarization and where should it be implemented?

OSPF supports summarization only at ABRs and ASBRs. At ABRs, inter-area routes can be summarized, while ASBRs summarize external routes. Summarization reduces routing table size, LSA flooding, and SPF calculations.

In enterprise networks, summarization is typically implemented at distribution or core boundaries. Poor summarization design leads to route flaps propagating across the network.

During troubleshooting, missing specific routes due to over-aggressive summarization is a common issue.

What the interviewer is actually testing:

They're checking if you understand hierarchical OSPF design.

Q7. Explain how BGP path selection works and which attributes are most critical in enterprise networks.

BGP selects paths based on attributes like weight, local preference, AS path length, origin, MED, eBGP over iBGP, and IGP metric. In enterprises, local preference and AS path are the most commonly manipulated attributes.

Local preference controls outbound traffic, while AS path prepending influences inbound traffic. MED is typically less reliable unless coordinated with ISPs.

During outages, incorrect attribute tuning can cause suboptimal routing or blackholing.

What the interviewer is actually testing:

They want to see if you understand traffic engineering, not just attribute order.

Q8. How do you troubleshoot BGP session flaps in an enterprise edge network?

BGP flaps are commonly caused by physical instability, MTU issues, aggressive timers, or routing loops. The first step is to check interface stability and error counters, followed by BGP logs and timers.

MTU mismatches affect TCP sessions silently, so enabling PMTUD or adjusting MSS is important. Route churn can also cause CPU spikes leading to session resets.

Stabilizing BGP often requires coordination between network, firewall, and ISP teams.

What the interviewer is actually testing:

They're evaluating your methodical troubleshooting approach.

Q9. Explain the difference between iBGP and eBGP and how split-horizon affects design.

iBGP requires full mesh or route reflectors because of split-horizon rules, while eBGP does not. In large enterprises, route reflectors are essential to maintain scalability.

Improper RR design can cause suboptimal routing or loops if cluster IDs are misconfigured.

Understanding iBGP behavior is critical during multi-site enterprise deployments.

What the interviewer is actually testing:

They want to see if you understand BGP scalability challenges.

Q10. How would you migrate from EIGRP to OSPF or BGP in a live network?

Migration requires careful redistribution planning to avoid loops. Route tagging, administrative distance tuning, and phased cutover are essential.

During coexistence, metrics must be normalized to avoid traffic shifts. Testing in isolated segments is critical before full migration.

This process requires both technical and change-management discipline.

What the interviewer is actually testing:

They are testing real-world migration experience, not theory.

Questions 11 to 20

Q11. What causes OSPF route flapping and how do you stabilize it?

Route flaps are often due to unstable links, aggressive timers, or frequent topology changes.

Suppressing flaps requires link stabilization, SPF tuning, and sometimes summarization.

Ignoring root cause leads to chronic instability.

What the interviewer is actually testing:

They want to know if you fix root causes, not symptoms.

Q12. How does ECMP work in OSPF and BGP?

OSPF supports equal-cost paths automatically, while BGP requires additional configuration.

ECMP improves utilization but complicates troubleshooting.

Asymmetric routing must be considered when firewalls are involved.

What the interviewer is actually testing:

They're checking your awareness of real-world side effects.

Q13. Explain OSPF authentication and its role in enterprise security.

OSPF authentication prevents unauthorized adjacency. MD5 or SHA is preferred over plain text.

Misconfigured auth often causes silent adjacency failure.

What the interviewer is actually testing:

Security + troubleshooting awareness.

Q14. How do you troubleshoot asymmetric routing in a multi-protocol network?

Asymmetry is caused by mismatched metrics, ECMP, or policy routing. Traceroutes and flow analysis help identify it.

Firewalls amplify the issue.

What the interviewer is actually testing:

End-to-end thinking.

Q15. What are common routing mistakes that cause enterprise outages?

Inconsistent metrics, uncontrolled redistribution, and poor summarization are top causes.

Documentation and change discipline prevent most outages.

What the interviewer is actually testing:

Experience and maturity.

Q16. Explain OSPF network types and how incorrect network type selection impacts adjacency and convergence.

OSPF network types define how neighbors are discovered and how adjacencies are formed.

Common types include broadcast, point-to-point, point-to-multipoint, and NBMA. Each network type controls hello behavior, DR/BDR election, and LSA flooding. In enterprise networks, incorrect network type selection is a frequent cause of partial adjacency or slow convergence.

For example, using broadcast on a hub-and-spoke WAN can cause unnecessary DR elections and excessive LSA flooding. Similarly, NBMA networks require manual neighbor configuration, and missing this leads to silent adjacency failure. Point-to-point is often the safest option for WAN links because it simplifies adjacency and avoids DR complexity.

From a troubleshooting perspective, mismatched network types between neighbors will prevent adjacency from reaching FULL. Commands like show ip ospf interface quickly expose these mismatches.

What the interviewer is actually testing:

They're checking whether you understand OSPF behavior beyond LANs, especially in WAN and service-provider-connected enterprise environments.

Q17. What is OSPF SPF calculation and how does frequent SPF impact network performance?

OSPF uses the Dijkstra SPF algorithm to calculate shortest paths based on LSDB information.

Every topology change triggers SPF recalculation, which consumes CPU and can impact convergence time. In large enterprise networks, frequent SPF runs can cause noticeable routing instability.

SPF throttling mechanisms like SPF timers and incremental SPF are used to reduce CPU impact. Without tuning, unstable links can cause continuous recalculation, leading to packet loss and high CPU utilization on routers.

When troubleshooting performance degradation, checking SPF logs and CPU history often reveals excessive recalculations caused by unstable interfaces or poor summarization.

What the interviewer is actually testing:

They want to know if you understand control-plane performance, not just routing outcomes.

Q18. Explain EIGRP metric calculation and how it differs from OSPF cost.

EIGRP uses a composite metric based on bandwidth, delay, reliability, load, and MTU (though MTU is not used in calculation). By default, only bandwidth and delay are active.

This allows more granular path selection compared to OSPF's single-cost metric.

In enterprise environments, improper bandwidth settings cause incorrect metric calculation, leading to suboptimal routing. This is especially common on WAN links where bandwidth is left at default values.

During troubleshooting, mismatched EIGRP metrics often explain unexpected traffic paths even when the topology appears correct.

What the interviewer is actually testing:

They're checking if you understand metric integrity and path predictability.

Q19. What is EIGRP Stuck-in-Active (SIA) and how do you resolve it?

SIA occurs when an EIGRP router does not receive a reply to a query within the active timer.

This usually happens in large or poorly designed EIGRP domains with excessive query propagation.

Resolution involves limiting query scope using summarization, stub routing, or redesigning the topology. Increasing timers only masks the problem and does not fix the root cause.

In real networks, SIA indicates architectural weakness rather than a simple misconfiguration.

What the interviewer is actually testing:

They want to see if you understand why EIGRP scales or fails to scale.

Q20. Explain route redistribution and the risks involved in multi-protocol enterprise networks.

Route redistribution allows routes from one protocol to be injected into another. While powerful, it is one of the most dangerous operations in enterprise routing because it can easily create routing loops.

Proper redistribution requires route tagging, filtering, and careful metric control. Without this, feedback loops can cause traffic blackholing or route flapping.

Most enterprise outages during migrations occur due to poorly planned redistribution.

What the interviewer is actually testing:

They are evaluating your risk awareness and discipline in live networks.

Questions 21 to 30

Q21. How do administrative distance values influence routing decisions during protocol coexistence?

Administrative Distance (AD) determines which routing source is trusted when multiple protocols advertise the same prefix. During migrations or coexistence phases, AD manipulation controls traffic flow.

Incorrect AD tuning can cause unexpected routing changes or override intended paths. AD should be adjusted cautiously and documented clearly.

In troubleshooting, AD conflicts often explain why a router is ignoring an expected route.

What the interviewer is actually testing:

They're checking if you understand decision hierarchy, not just metrics.

Q22. What is BGP route dampening and why is it rarely used today?

Route dampening suppresses unstable prefixes to protect routing stability. However, it can unintentionally penalize legitimate routes and delay recovery.

Modern networks prefer stability through better design rather than dampening. Many ISPs have disabled it due to its negative side effects.

Understanding dampening is still important when troubleshooting unexplained route suppression.

What the interviewer is actually testing:

They're checking legacy knowledge + modern judgment.

Q23. Explain BGP prefix filtering and why it is critical at enterprise edges.

Prefix filtering prevents incorrect or malicious route advertisement. Without filters, enterprises risk leaking private or full routing tables to ISPs.

Filters should be applied both inbound and outbound. Relying solely on the ISP is a design mistake.

Most real-world BGP incidents are caused by missing or incorrect filters.

What the interviewer is actually testing:

They're assessing your operational hygiene and responsibility.

Q24. How does BGP handle scalability in large enterprise networks?

Scalability is achieved using route reflectors, confederations, and policy control. Route reflectors reduce full-mesh requirements but introduce hierarchy and dependency.

Improper RR placement can lead to suboptimal routing or convergence delays.

Design validation is critical before deployment.

What the interviewer is actually testing:

They want design thinking, not just protocol knowledge.

Q25. What is BGP convergence and how do you improve it?

BGP convergence is inherently slower than IGPs due to path exploration. Techniques like prefix aggregation, faster IGP convergence, and optimal timer tuning improve it.

Over-tuning timers risks instability.

Convergence optimization is always a balance.

What the interviewer is actually testing:

They're testing real-world expectations, not ideal theory.

Q26. Explain route leaking and how it affects enterprise security.

Route leaking occurs when routes are advertised beyond intended boundaries. This can expose internal networks or cause traffic misdirection.

Most leaks occur due to missing filters or incorrect redistribution.

Security incidents often start as routing mistakes.

What the interviewer is actually testing:

They're checking security awareness through routing.

Q27. How do you troubleshoot missing routes in a multi-area OSPF network?

Missing routes can be caused by area type restrictions, summarization, or redistribution issues. Checking LSDB contents and ABR behavior is key.

Blindly checking the routing table is insufficient.

Understanding where the route should exist is critical.

What the interviewer is actually testing:

They want logical fault isolation, not command memorization.

Q28. Explain policy-based routing (PBR) and its risks in enterprise networks.

PBR overrides routing decisions based on policies. While useful, it bypasses routing intelligence and can cause asymmetric routing.

Improper PBR often breaks failover scenarios.

PBR should be used sparingly and documented thoroughly.

What the interviewer is actually testing:

They're checking maturity and restraint.

Q29. What causes routing loops and how do you detect them?

Loops are caused by redistribution errors, inconsistent metrics, or policy mistakes.

Symptoms include TTL expiry and high CPU.

Traceroute and packet capture are key diagnostic tools.

Prevention is better than detection.

What the interviewer is actually testing:

They want to see problem recognition under pressure.

Q30. From experience, what routing design mistakes cause the biggest enterprise outages?

The biggest issues are uncontrolled redistribution, lack of summarization, and inconsistent configuration standards. Most outages are human-caused, not protocol-caused.

Good documentation and change control prevent most failures.

Experience matters more than configuration skill.

What the interviewer is actually testing:

They're judging seniority and ownership mindset.

Questions 31 to 40

Q31. Explain how VLANs work at scale in an enterprise campus and common design mistakes that cause outages.

VLANs logically segment Layer-2 networks to control broadcast domains and improve performance and security. In enterprise campuses, VLANs are typically aligned with function, department, or trust boundary and extended only as far as required. Poor VLAN planning leads to excessive broadcast traffic and difficult fault isolation.

A common mistake is stretching VLANs across multiple buildings or data centers for "convenience." This increases STP complexity and blast radius during failures. Another frequent issue is inconsistent VLAN databases across switches, especially when VTP is misused.

When troubleshooting VLAN issues, I verify VLAN existence, trunk allowance, native VLAN consistency, and MAC learning behavior. Most VLAN outages are configuration-drift problems rather than hardware failures.

What the interviewer is actually testing:

They want to know if you design VLANs for containment and stability, not just segmentation.

Q32. How does trunking work and what are the most common trunk-related failures in enterprise networks?

Trunking allows multiple VLANs to traverse a single physical link using 802.1Q tagging. In enterprise environments, trunks are typically statically configured to avoid negotiation issues. Dynamic Trunking Protocol (DTP) is often disabled for security and predictability.

Common failures include VLANs not allowed on trunks, native VLAN mismatches, and incorrect encapsulation. Native VLAN mismatch can silently cause traffic leaks or STP instability, making it difficult to detect without careful inspection.

Troubleshooting involves checking trunk status, allowed VLAN lists, and CDP/LLDP outputs.

Packet captures also help identify tagging issues.

What the interviewer is actually testing:

They are checking if you understand silent Layer-2 failures, which are harder than routing issues.

Q33. Explain STP and why loops are still a major cause of enterprise outages.

Spanning Tree Protocol prevents Layer-2 loops by blocking redundant paths. Despite its maturity, loops still occur due to misconfiguration, unmanaged switches, or improper port settings. A single loop can bring down an entire campus.

Common causes include missing BPDU Guard on access ports, incorrect root bridge placement, or connecting switches via access ports instead of trunks. Rapid STP variants help convergence but do not prevent bad design.

During troubleshooting, MAC flapping, high CPU, and broadcast storms are key indicators.

Immediate isolation is critical before root-cause analysis.

What the interviewer is actually testing:

They want to see if you can recognize and stop a Layer-2 meltdown quickly.

Q34. Differentiate STP, RSTP, and MST. When would you choose MST in an enterprise campus?

STP provides basic loop prevention but converges slowly. RSTP improves convergence by introducing faster state transitions. MST allows multiple VLANs to be mapped to different spanning-tree instances, improving load balancing and scalability.

MST is chosen in large campuses with many VLANs to reduce STP instance overhead.

However, it requires strict configuration consistency across the region, making it operationally sensitive.

Troubleshooting MST issues often involves region mismatches, which silently break STP optimization.

What the interviewer is actually testing:

They're testing design trade-off awareness, not just protocol knowledge.

Q35. How do you design root bridge placement and why is it critical?

Root bridge placement determines traffic flow in a Layer-2 topology. Best practice is to manually set root bridges at the distribution layer for predictable behavior.

If left to default election, an access switch can become root, leading to suboptimal paths and instability during failures. Root placement must align with physical topology and traffic patterns.

During outages, unexpected root changes often explain sudden traffic shifts or congestion.

What the interviewer is actually testing:

They want to see intentional design thinking, not reactive configuration.

Q36. Explain inter-VLAN routing options and when L3 switches are preferred.

Inter-VLAN routing can be done using router-on-a-stick or Layer-3 switches. In enterprise campuses, L3 switches are preferred due to higher throughput and lower latency.

SVIs provide scalable gateway services and integrate directly with routing protocols like OSPF. Misconfigured SVIs often cause "VLAN up but no connectivity" issues.

Troubleshooting focuses on SVI state, routing table entries, and ARP resolution.

What the interviewer is actually testing:

They're checking campus scalability and performance understanding.

Q37. What is HSRP/VRRP and how do gateway redundancy failures impact users?

HSRP and VRRP provide default gateway redundancy for VLANs. Without proper tuning, failover can cause noticeable packet loss.

Common issues include mismatched priorities, authentication mismatch, or preemption misbehavior. Asymmetric routing can also occur if redundancy is not aligned with routing design.

Troubleshooting involves verifying active/standby roles and tracking failover events.

What the interviewer is actually testing:

They want to know if you can protect end-user experience, not just redundancy.

Q38. Explain ARP and how ARP-related issues cause network outages.

ARP resolves IP addresses to MAC addresses. ARP storms or spoofing can overload switches and disrupt traffic.

Issues arise from duplicate IPs, misconfigured devices, or malicious activity. ARP tables filling up cause packet drops and latency.

Troubleshooting uses ARP inspection, MAC tables, and packet capture.

What the interviewer is actually testing:

They are testing Layer-2/Layer-3 interaction understanding.

Q39. What is DHCP snooping and why is it important in enterprise switching?

DHCP snooping prevents rogue DHCP servers by controlling trusted ports. It also builds a binding table used by other security features.

Without it, attackers or misconfigured devices can hijack IP assignments. Incorrect snooping configuration can break legitimate DHCP.

Troubleshooting involves validating trust settings and relay behavior.

What the interviewer is actually testing:

They're testing security awareness at Layer-2.

Q40. Explain port security and real-world limitations.

Port security limits MAC addresses on access ports. While useful, it can cause outages if devices change frequently.

Violations can shut ports unexpectedly, impacting users. Sticky MACs help but require maintenance.

Troubleshooting involves balancing security and operational flexibility.

What the interviewer is actually testing:

They're checking practical security judgment, not rigidity.

Questions 41 to 50

Q41. How do you troubleshoot MAC flapping in a campus network?

MAC flapping indicates loops or miswired links. It causes instability and high CPU usage.

Identifying the flapping MAC and tracing its movement across ports helps isolate the issue.

Immediate shutdown of suspected links may be required.

Root cause is often unmanaged switches or cabling errors.

What the interviewer is actually testing:

They want calm, decisive incident handling.

Q42. What causes intermittent packet loss in switched networks?

Packet loss can be due to congestion, duplex mismatch, or microbursts. These issues are hard to detect without proper monitoring.

Interface counters, buffer drops, and QoS behavior must be examined.

Intermittent issues require trend analysis, not instant fixes.

What the interviewer is actually testing:

They're testing patience and analytical troubleshooting.

Q43. Explain QoS at the switching layer and common misconfigurations.

QoS prioritizes traffic such as voice or video. Misconfigured QoS can starve critical traffic or drop packets.

Trust boundaries must be clearly defined. End-to-end consistency is essential.

Troubleshooting focuses on queue drops and policy alignment.

What the interviewer is actually testing:

They want to see end-to-end thinking, not isolated configs.

Q44. How do you secure access layer switches in an enterprise?

Security involves port security, DHCP snooping, DAI, BPDU Guard, and storm control. No single feature is sufficient.

Misconfiguration can block legitimate traffic, so staged deployment is important.

Monitoring and logging are as important as enforcement.

What the interviewer is actually testing:

They're checking defensive depth understanding.

Q45. What switching mistakes most commonly cause enterprise outages?

Common mistakes include unmanaged loops, default STP settings, VLAN sprawl, and lack of documentation. Most outages are preventable.

Change control and validation are critical.

Experience reduces mistakes more than certifications.

What the interviewer is actually testing:

They're judging seniority and ownership mindset.

Q46. How does Spanning Tree interact with Layer-3 boundaries and why is this important in enterprise campus design?

Spanning Tree operates strictly at Layer-2, while Layer-3 boundaries eliminate STP influence.

In enterprise campuses, best practice is to push Layer-3 as close to the access layer as possible to limit STP domains. This reduces the impact of loops and speeds up convergence during failures.

When Layer-2 domains are extended unnecessarily, STP failures can propagate across large parts of the network. This often results in broadcast storms, MAC table instability, and widespread outages. L3 boundaries provide natural fault isolation.

During troubleshooting, understanding where STP ends and routing begins helps isolate whether the issue is control-plane (routing) or data-plane (switching) related.

What the interviewer is actually testing:

They're checking if you understand failure domain containment, not just protocol boundaries.

Q47. Explain how SVIs participate in routing protocols and common mistakes that cause "VLAN up but no connectivity." SVIs act as Layer-3 interfaces for VLANs and can participate in routing protocols like OSPF or EIGRP. For an SVI to be operational, the VLAN must exist and at least one access or trunk port must be active in that VLAN.

A common mistake is configuring the SVI correctly but forgetting to allow the VLAN on uplink trunks. Another frequent issue is missing routing protocol configuration on the SVI, resulting in reachability only within the local switch.

Troubleshooting involves verifying VLAN state, trunk propagation, SVI status, and routing table entries.

What the interviewer is actually testing:

They want to see if you understand Layer-2 dependency of Layer-3 services.

Q48. How do multilayer switches handle hardware vs software forwarding, and why does this matter during outages?

Multilayer switches use hardware ASICs for fast forwarding (CEF) and the CPU for controlplane operations. During high CPU utilization, control-plane tasks like routing updates and STP recalculations can be delayed, even if forwarding continues.

Certain traffic types, such as packets destined to the switch itself or malformed packets, are punted to the CPU. During attacks or misconfigurations, this can overload the control plane.

Understanding this distinction helps explain situations where "traffic flows but management is unreachable."

What the interviewer is actually testing:

They're checking platform awareness, not just configuration knowledge.

Q49. What is a broadcast storm, how do you detect it, and how do you stop it without bringing down the campus?

A broadcast storm occurs when excessive broadcast traffic overwhelms the network, often due to loops. Symptoms include high CPU, slow network response, and flapping MAC tables.

Detection involves checking interface counters, CPU utilization, and CAM table logs. Storm control can help mitigate impact but does not fix the root cause.

Stopping the storm requires isolating the offending link or device quickly, sometimes by shutting down entire access blocks to stabilize the network first.

What the interviewer is actually testing:

They want to see crisis handling ability under pressure.

Q50. Explain storm control and why it is not a replacement for proper STP design.

Storm control limits broadcast, multicast, or unknown unicast traffic rates. It acts as a safety net, not a primary prevention mechanism.

Improper thresholds can cause legitimate traffic drops, impacting applications. Relying solely on storm control hides design flaws instead of fixing them.

In troubleshooting, storm control counters help identify abnormal traffic sources.

What the interviewer is actually testing:

They're testing design maturity vs quick fixes.