Architecture practice questions

Static default route with a floating static

Why wrong: A static default route with a floating static is a router-level failover mechanism, not a first-hop redundancy protocol. It relies on a higher administrative distance for a backup route, but hosts are still configured with a single default gateway IP address. If the active router fails, that gateway IP becomes unreachable until the host is manually reconfigured or a dynamic protocol like ICMP redirects takes over, so it is not transparent to hosts. Additionally, floating static routes cannot provide sub-second failover because they depend on recursive routing table changes.

GLBP

Why wrong: GLBP (Gateway Load Balancing Protocol) does provide first-hop redundancy and automatic failover, but its primary feature is load balancing across multiple routers that all forward traffic for the same virtual IP. While GLBP uses an active virtual gateway (AVG) to assign virtual MAC addresses to hosts, it introduces more operational complexity than HSRP for simple failover scenarios. In a campus network where the design goal is high availability without the need for load sharing, HSRP is traditionally preferred because it offers a straightforward active/standby model with deterministic behavior, making GLBP less appropriate for this specific requirement.

VRRP

Why wrong: VRRP (Virtual Router Redundancy Protocol) is an open standard FHRP that functions very similarly to HSRP by sharing a virtual IP and MAC between multiple routers. However, VRRP is not Cisco proprietary, and in a campus network built entirely with Cisco equipment, HSRP is the native, best-integrated choice. Additionally, VRRP's failover behavior is based on priority and the master router's hello advertisements, but it lacks some of the Cisco-specific enhancements like the ability to track interface states with the same granularity as HSRP. Since the question likely expects a Cisco-centric answer, VRRP, while technically valid, is not the intended solution.

Mesh networking

Why wrong: Mesh networking is designed for outdoor or hard-to-wire environments where Ethernet backhaul is unavailable, but in a high-density indoor office it introduces a wireless backhaul that competes for the same RF spectrum as client traffic. This shared medium increases airtime utilization and latency, and mesh APs often suffer from a throughput penalty known as the 'half-backhaul' effect. Since seamless roaming requires stable, low-latency links between APs and a wired connection, the unpredictable mesh topology and reduced capacity make it a poor fit for this deployment.

Autonomous APs

Why wrong: Autonomous APs operate as standalone devices with independent configuration, lacking any centralized controller to coordinate RF parameters, security policies, or client roaming. While they can forward traffic locally, they rely entirely on the client to initiate 802.11 reassociation, which often results in sticky clients and disconnects during movement between APs. Without support for fast roaming mechanisms like 802.11r/k/v (which require controller-based key caching and neighbor lists), autonomous APs cannot provide the smooth, low-latency handoff necessary for high-density indoor roaming and real-time applications.

Centralized switching with a WLC

Why wrong: Centralized switching with a WLC tunnels all client data traffic over CAPWAP to the controller, which then bridges it onto the wired network. This hairpin design adds a round-trip latency to every packet and makes the controller a single point of congestion, especially problematic for voice and video in dense environments. Even though the WLC can orchestrate fast roaming and coordinate channels, the data plane latency inherent in centralized switching negates many benefits, and traffic that could be locally exited must unnecessarily traverse the core for every flow, making this architecture less efficient for high-capacity indoor offices.

Type 1, Type 2, Type 3, Type 5

Why wrong: Type 5 LSAs advertise routes from outside the OSPF autonomous system, such as redistributed static or RIP routes. Both stubby and totally stubby areas filter these external LSAs to reduce routing table size and prevent external route flapping from affecting internal routers. Since a totally stubby area blocks all Type 5 LSAs, listing Type 5 in the allowed set is factually wrong.

Type 1, Type 2, Type 4, Type 5

Why wrong: Type 4 LSAs are generated by ABRs to advertise the location of an ASBR to other areas, and Type 5 LSAs carry the actual external routes. A totally stubby area prevents external routes from being learned, which also makes Type 4 LSAs irrelevant because there is no ASBR reachability to advertise. Both Type 4 and Type 5 are filtered at the ABR, so an option that includes either is incorrect.

Type 1, Type 2, Type 3 (including default), Type 4

Why wrong: Although a totally stubby area does permit Type 1, Type 2, and a default Type 3 LSA, it explicitly blocks Type 4 LSAs. The ABR does not forward ASBR-summary LSAs into a totally stubby area, even though it injects the default inter-area route. Including Type 4 in the allowed LSA list is therefore inaccurate; only the default Type 3 summary is permitted as the sole inter-area route.

Split horizon

Why wrong: Split horizon prevents routing updates from being sent back out the same interface on which they were received. While EIGRP does honor split horizon on many interfaces, it only blocks immediate re-origination of a learned route and does not guarantee a loop-free alternate path in a more complex topology, so it is not the key mechanism preventing the routing loop in question.

Route poisoning

Why wrong: Route poisoning marks a route as unreachable by setting its metric to infinity, which in EIGRP is 4,294,967,295 (compared to RIP's 16). This tells neighboring routers to invalidate the route, but it does not itself verify whether an alternative path is loop-free; DUAL's feasibility condition performs that verification, making route poisoning insufficient on its own and not the correct answer.

Hold-down timers

Why wrong: Hold-down timers are a RIP-specific convergence feature that forces routers to ignore new route information for a period after a route is withdrawn. EIGRP does not implement hold-down timers; instead, DUAL relies on a query/reply process and the feasibility condition to recompute paths, so hold-down timers would be irrelevant when troubleshooting an EIGRP routing loop.

Random Early Detection (RED)

Why wrong: RED (Random Early Detection) is a congestion avoidance mechanism that monitors the average queue depth and probabilistically drops packets before the queue overflows. It does not classify traffic or reserve bandwidth, and voice packets are dropped just as readily as data packets when congestion develops, which directly degrades voice quality. RED is therefore a drop policy, not a queuing or scheduling mechanism, so it cannot provide the strict delay and loss guarantees that voice needs.

First In First Out (FIFO)

Why wrong: FIFO (First In First Out) creates a single shared queue and transmits packets in arrival order, applying no classification or differentiation whatsoever. Voice packets are therefore placed behind whatever bulk data, transactions, or overhead traffic arrived earlier; during congestion, latency and jitter grow unpredictably and the voice stream can be starved. Since FIFO cannot offer any priority or bandwidth guarantee to real-time flows, it is unsuitable for voice deployments that need consistent low-latency treatment.

Class-Based Weighted Fair Queuing (CBWFQ)

Why wrong: CBWFQ (Class-Based Weighted Fair Queuing) allocates a proportionate weight/bandwidth to each configured traffic class and schedules them fairly according to those weights, so it cannot guarantee a voice class an immediate service advantage. A voice class in CBWFQ still has to 'take its turn' alongside other classes' queues based on the weighted fair scheduler, and under overload the voice queue can experience queuing delay. It provides per-class bandwidth management but lacks the strict priority scheduling that real-time audio needs, which is why LLQ extends CBWFQ with an explicit priority queue.

interface vlan 100

Why wrong: interface vlan 100 creates a switched virtual interface (SVI), which is a Layer 3 logical interface used for routing or management of a VLAN. It does not create the VLAN itself; rather, it references an existing VLAN ID. If VLAN 100 has not been created in the switch's VLAN database, the SVI will remain in a down/down state and cannot be used. This command is intended for inter-VLAN routing or remote access, not for defining the VLAN's existence.

name VLAN100

Why wrong: name VLAN100 is an administrative command that assigns a descriptive label to an already-existing VLAN. It is executed from VLAN configuration mode, which is entered after the VLAN has been created with the vlan 100 command. Without a pre-existing VLAN, this command has no effect because there is no VLAN to name. Naming does not create or modify the VLAN's Layer 2 properties; it simply provides a human-readable identifier for network administrators.

switchport access vlan 100

Why wrong: switchport access vlan 100 is an interface configuration command that assigns a switchport as an access port in VLAN 100. It only maps a physical port to an existing VLAN identifier; it does not create the VLAN in the switch's VLAN database. If VLAN 100 has not been created first, the port will be associated with a non-existent or inactive VLAN, and traffic will not be forwarded. The correct sequence is to create the VLAN with vlan 100 and then assign ports using this command.

Dead timer mismatch

Why wrong: An OSPF router declares a neighbor dead when no Hello is received within the dead interval, which is typically four times the hello interval. If timers differ, the peer with the shorter dead timer ages out the adjacency and brings it down, but the state machine resets back to DOWN and then attempts to re-establish, causing persistent flapping rather than a stable stuck-in-EXSTART condition. EXSTART is only reached after a two-way state, so timer mismatches manifest as repeated state resets and neighbor loss, not as an inability to transmit database description packets.

Authentication misconfiguration

Why wrong: When OSPF authentication keys or types differ, an interface silently discards incoming Hello packets before they can be processed at the OSPF protocol level. Without a valid Hello from the peer, the neighbor is never accepted, so the adjacency remains in the INIT state (or the neighbor is not even listed) and cannot progress to EXSTART. This failure mode occurs earlier in the neighbor state machine, whereas an MTU problem only becomes apparent after two-way communication is established and database description packets are exchanged.

Mismatched OSPF area IDs

Why wrong: A Hello packet carries the originating router's area ID, and a receiving router will only form an adjacency if that area ID matches one of its own configured OSPF areas. If the area IDs differ, the Hello is deemed invalid and is silently ignored, so the routers never reach even the two-way state that precedes EXSTART. Therefore, area ID mismatch prevents the neighbor relationship from ever being established, making it impossible to be stuck at the DB description exchange stage.

VLAN tagging

Why wrong: VLAN tagging operates at Layer 2 by inserting a 12-bit tag into the Ethernet frame header to segment broadcast domains on a local switch. In an MPLS VPN core, VLAN IDs are only relevant on access or trunk links to the PE (Provider Edge) router and do not extend across the provider backbone. Because VLANs don't create separate Layer 3 routing tables, they cannot isolate routing information between VPN customers in the MPLS core. Even if customer edges are on different VLANs, the PE still uses a single global routing table unless VRF is explicitly configured, so VLAN tagging alone is insufficient for ensuring inter-customer isolation.

MPLS labels

Why wrong: MPLS labels are fixed-length shim headers appended between the Layer 2 header and the IP packet, used solely for forwarding decisions along label-switched paths. The label is swapped by each LSR (Label Switch Router) based on the LIB (Label Information Base) and does not carry any routing or VPN membership information. All VPN customers share the same MPLS core infrastructure and label space, meaning labels do not separate routing tables or filter route advertisement between different VPNs. While labels enable traffic forwarding to the correct CE (Customer Edge), they provide no mechanism to prevent one customer's routes from leaking into another's routing table; that isolation is a function of VRFs at the PE.

IPsec tunnels

Why wrong: IPsec tunnels deliver security services through Authentication Header (AH) or Encapsulating Security Payload (ESP) protocols, providing data integrity, origin authentication, and optionally confidentiality. However, IPsec operates at the network layer in terms of encryption and does not influence how routing tables are constructed or how routes are shared between customers. An IPsec VPN can protect traffic between sites, but if the underlay or overlay uses a shared routing protocol without VRF, routes from different customers could still intermingle. Thus, IPsec only secures the transport path; it cannot create separate routing instances or enforce routing isolation between customers in an MPLS L3VPN service.

Each member switch must have the same hardware model.

Why wrong: INCORRECT: StackWise Virtual allows mixed hardware models, unlike physical StackWise which requires identical models.

It requires dedicated stacking cables for interconnectivity.

Why wrong: INCORRECT: StackWise Virtual uses regular Ethernet links, not dedicated stacking cables.

It supports up to 9 member switches in a stack.

Why wrong: INCORRECT: StackWise Virtual supports only 2 member switches, not 9.

Enable OSPF Fast Hello on all interfaces.

Why wrong: Fast Hello changes only the hello transmission interval, not the dead timer itself. In Cisco OSPF, the dead interval remains at its configured value (or defaults to multiple seconds), so a router still waits the full dead period before declaring a neighbor down. Therefore, while Fast Hello increases hello frequency, failure detection remains the bottleneck, and the outage is not significantly reduced—both hello and dead timers must be lowered together to achieve sub-second convergence.

Implement OSPF LSA throttling with a minimum interval of 0 ms.

Why wrong: OSPF LSA throttling controls the rate at which link-state advertisements are generated and flooded after a change is recognized, with a minimum interval of 0 ms merely eliminating the hold-down delay. However, this feature takes effect only after the router has already detected the topology change; it does nothing to accelerate the hello/dead timer process that identifies the failure. The 30-second outage is dominated by failure detection, so even instant LSA propagation leaves the detection wait untouched, and aggressive throttling can actually cause unnecessary CPU load.

Use OSPF incremental SPF (iSPF).

Why wrong: Incremental SPF (iSPF) is a post-detection optimization that reduces the CPU work during the Dijkstra calculation by recalculating only the affected branch of the shortest-path tree. It does not shorten the time needed to discover that a neighbor has failed; the router still must wait for the OSPF dead timer to expire before triggering any SPF computation. Since the dead timer is the bottleneck in a 30-second outage, iSPF offers no improvement to the detection phase and is therefore not a solution for this problem.

Configure the port as a routed port.

Why wrong: A routed port is a Layer 3 interface created with the no switchport command and is designed for point-to-point routed links, not for carrying multiple VLANs. Because it operates at Layer 3, it strips any 802.1Q VLAN tags and cannot deliver tagged frames to router subinterfaces. As a result, subinterfaces configured for VLANs would receive no tagged traffic, and inter-VLAN routing over that link would fail.

Configure the port as an access port in VLAN 1.

Why wrong: An access port in VLAN 1 assigns all inbound and outbound frames to a single untagged VLAN, removing any VLAN tag before sending frames to the router. Router subinterfaces using encapsulation dot1Q rely on receiving 802.1Q-tagged frames to identify which VLAN each frame belongs to; with only untagged VLAN 1 traffic, all other VLAN subinterfaces remain silent. This confines routing to one VLAN, defeating the purpose of supporting multiple VLANs on the single router link.

Configure the port as a dynamic desirable port.

Why wrong: Dynamic desirable mode uses DTP (Dynamic Trunking Protocol) to actively offer and negotiate trunking with the neighboring device, but it is a negotiation mechanism rather than an operational interface state. A Cisco router does not run DTP, so the negotiation will not succeed unless the router is manually configured to trunk, and the link may remain an access port. Even when negotiation works, relying on DTP is not deterministic; the switch port should be explicitly configured as a trunk to guarantee 802.1Q tagging.

Use a single distribution switch to simplify management.

Why wrong: In a campus network, the distribution layer aggregates access switches and enforces policy, so a single distribution switch becomes a single point of failure. If that switch fails or reboots, every connected access switch loses connectivity to the rest of the network, directly violating high-availability requirements. A resilient design requires at least two distribution switches using HSRP/VRRP for first-hop gateway redundancy or stacking/VSS to provide active-active forwarding.

Configure the core layer for Layer 2 switching only.

Why wrong: A Layer 2-only core requires inter-VLAN routing to happen at the distribution or access layers, forcing traffic to take suboptimal paths and increasing latency. Since a Layer 2 core relies on spanning tree for loop prevention, one of any redundant uplinks is always blocked, wasting bandwidth and extending failover times when the active path fails. In modern campus network designs, the core should perform Layer 3 routing to provide equal-cost multipath load balancing, fast convergence via protocols like OSPF or BGP, and to contain broadcast domains.

Use spanning-tree PortFast on all core switch ports.

Why wrong: Spanning-tree PortFast bypasses STP listening/learning states for access ports to speed up host link-up, but it is not a redundancy feature. Applying PortFast to core ports connecting to other switches or the distribution layer removes spanning tree protections on those links, so if any redundant path exists, a temporary Layer 2 loop can form and cause a broadcast storm. The core should instead use STP features like LoopGuard or root guard, or better, use VSS/StackWise to avoid STP blocking altogether; PortFast alone never provides failover.

Auto-negotiation is disabled on both ends.

Why wrong: Incorrect. Auto-negotiation disabled on both ends is typical for fiber links and does not cause packet loss.

Spanning-tree BPDU guard is enabled on the port-channel.

Why wrong: Incorrect. BPDU guard prevents spanning tree BPDUs from being received, which can cause port shutdown but not intermittent packet loss in a normal spanning-tree environment.

One switch is configured with active LACP and the other with passive LACP.

Why wrong: Incorrect. Active/passive LACP is a valid configuration; the passive side will respond to LSAP messages from the active side. This does not cause packet loss.

Implement PIM-SM for multicast routing in the underlay.

Why wrong: PIM-SM is unnecessary and even harmful in an SD-Access underlay because multicast traffic is handled in the overlay via VXLAN encapsulation, typically with head-end replication. The underlay is intentionally an IP-only fabric that must not maintain multicast group state, since doing so adds control-plane complexity and introduces a dependency on a multicast Rendezvous Point. In a properly designed fabric, the overlay control plane (LISP) maps multicast receivers and sources, and the underlay simply forwards the encapsulated unicast copies, so enabling PIM-SM in the underlay would violate the architecture's scalability principles.

Preserve existing VLANs across the fabric to minimize changes.

Why wrong: Preserving existing VLANs across the fabric is a misunderstanding of the underlay/overlay boundary in SD-Access. The underlay is a routed L3 fabric where no L2 broadcast domain exists; VLANs are only locally relevant at each Fabric Edge node. Attempting to stretch VLANs across the fabric would force spanning-tree into the path, reintroduce L2 loops, and cap the fabric's scale at the size of a broadcast domain. In SD-Access, VLANs are mapped to overlay VNIs, and Layer 2 extension happens only where explicitly required, not as a default mode.

Deploy VRF-lite on all edge nodes to isolate tenants.

Why wrong: Deploying VRF-lite on all edge nodes is a throwback to a manual, device-centric segmentation model that does not align with SD-Access intent. The overlay uses LISP to maintain VRFs centrally and VXLAN VNIs to segregate tenants, providing end-to-end segmentation without requiring per-device VRF provisioning. VRF-lite would also be unable to span sites or enforce network-wide policy consistently, and it adds operational overhead precisely where SD-Access aims to eliminate it. Thus, VRF-lite should not be substituted for the fabric's overlay segmentation.

Configure marking only at the core layer to simplify policy.

Why wrong: Configuring marking only at the core layer is ineffective because by the time packets reach the core, they have already traversed lower layers where congestion and queuing decisions have occurred. The core's primary role is high-speed forwarding, not deep packet inspection, and any marking applied there cannot influence how access and distribution switches handled the traffic. This approach fails to provide end-to-end QoS, as upstream prioritization must be set at the edge to benefit all subsequent hops.

Trust only the distribution layer switches to mark traffic.

Why wrong: Trusting distribution layer switches to mark traffic is flawed because packets have already passed through access switches where oversubscription and queuing on access links may cause drops before any marking is applied. Additionally, distribution switches aggregate traffic from many sources, making source-based re-marking coarse and operationally complex, while also shifting the trust boundary away from the actual endpoint. QoS policies should be enforced as close to the source as possible, not after the traffic has already been subjected to network conditions.

Trust the DSCP values set by IP phones and workstations.

Why wrong: Trusting DSCP values set by IP phones and workstations is risky because these end devices are not under administrative control and can be misconfigured, compromised, or intentionally spoofed to gain unwanted priority. End-user applications may also set arbitrary DSCP values that conflict with network policy, leading to bandwidth abuse or ineffective queuing. The network must re-mark at the access switch to establish a trusted boundary and enforce a consistent classification based on the device and application type, not on potentially untrustworthy labels.

Reduces the amount of cabling required.

Why wrong: Incorrect. Spine-leaf actually increases the amount of cabling required, not reduces it. In a spine-leaf design, every leaf switch must be physically connected to every spine switch to form a full mesh, resulting in N x M cable runs (where N is leaf count and M is spine count). This is a higher cable count than a traditional hierarchical design that aggregates uplinks, making cabling more extensive and structured, not less.

Eliminates the need for firewall appliances.

Why wrong: Incorrect. Spine-leaf is a network fabric topology and does not replace security functions such as firewalls. Firewall appliances are still required to enforce security policies, segment workloads, and filter traffic between tenants or zones, whether deployed physically or virtually. The fabric's routing and connectivity patterns do not provide stateful inspection or access control, so firewall appliances remain a necessary component of a secure data center design.

Increase AP transmit power to maximize coverage.

Why wrong: Raising transmit power to cover a wider area increases cell size and, critically, the number of clients contending for each channel. This excessive overlap creates more co-channel interference, degrades throughput, and causes hidden-node problems, particularly in dense deployments. In modern Wi-Fi design, coverage range is rarely the bottleneck; instead, capacity and interference management drive the design, so increasing power is counterproductive.

Enable 2.4 GHz band only to maximize range.

Why wrong: While 2.4 GHz does propagate farther and penetrates obstacles better, enabling it as the only band to maximize range creates a severe capacity bottleneck. The band offers only three non-overlapping channels, so in any multi-AP deployment, co-channel interference becomes unavoidable, and external interference from Bluetooth and other devices compounds the problem. This approach sacrifices the entire 5 GHz capacity and is therefore not a valid consideration for high-density design.

Increase the shaping rate to 60 Mbps to allow for burst.

Why wrong: Raising the shaping rate to 60 Mbps would exceed the provider’s 50 Mbps committed rate, causing the provider’s shaping/policing at the edge to drop all excess packets—including voice—instead of allowing a controlled burst. Burst tolerance should be managed with the shaper's Bc/Be parameters, not by increasing the shaper's token bucket rate. This approach does not solve voice drops; it simply shifts the drop location from the local router to the provider edge.

Replace shaping with policing to drop non-voice traffic.

Why wrong: Policing is a token-bucket mechanism that immediately drops or re-marks packets that exceed a configured rate; it does not provide a buffer or queue. Unlike shaping, which holds excess traffic and allows deferred forwarding, policing will drop any burst that exceeds the rate—including short bursts of DSCP EF voice packets. Moreover, policing applies the same drop action across all classes unless complex hierarchical policies are used; it cannot perform per-class differential prioritization like a priority queue within a shaper.

Change the marking to use CoS instead of DSCP for better QoS.

Why wrong: CoS is a Layer 2 marking field in the 802.1Q VLAN header, only trusted on switchports and typically reset when frames traverse a Layer 3 routed WAN interface. The router's egress queuing decisions are based on the Layer 3 DSCP value (or the internal QoS class mapped from it), so switching to CoS would not change which queue the voice traffic uses. The reported drops are caused by the shaper's queue depth and the lack of priority treatment for EF, not by the marking type; therefore, changing from DSCP to CoS is irrelevant.

Specify the destination network and subnet mask, then enter global configuration mode, then specify the next-hop IP address or exit interface.

Why wrong: This sequence is invalid because the first step requires global configuration mode to be active, yet the second step enters it. While in privileged EXEC mode, you cannot issue the 'ip route' command for a destination; the router will reject it as an invalid input or ambiguous command. Therefore, specifying the network before entering global configuration mode is not a legal operation, even though the network, mask, and next-hop order would otherwise be correct.

Specify the next-hop IP address or exit interface, then specify the destination network and subnet mask, then enter global configuration mode.

Why wrong: This ordering fails the command syntax of 'ip route', which mandates destination network and mask before the forwarding address. Additionally, putting global configuration mode last means the first two actions would be attempted before the router even accepts 'ip route' commands. The next-hop IP or exit interface can only appear after the prefix is defined, so placing it first is fundamentally wrong.

Enter global configuration mode, then specify the next-hop IP address or exit interface, then specify the destination network and subnet mask.

Why wrong: Although entering global configuration mode is the correct first step, the subsequent ordering inverts the 'ip route' command fields. The command must list the destination network and subnet mask immediately after 'ip route', then optionally specify the next-hop IP address or exit interface as the forwarding instruction. Inverting that order will generate a syntax error or cause the router to misinterpret the next-hop as a network address.

Step 1: Root port selection, Step 2: Root bridge election, Step 3: Designated port selection, Step 4: Blocking of alternate ports

Why wrong: Root ports cannot be selected before a root bridge exists because a root port is defined as the best path to the root bridge. In the 802.1D algorithm, the root bridge is elected via the lowest bridge ID (priority plus MAC address) and then every non-root bridge evaluates the root path cost on each port to pick its root port. Without a known root, there is no reference for computing costs or comparing BPDUs.

Step 1: Root bridge election, Step 2: Designated port selection, Step 3: Root port selection, Step 4: Blocking of alternate ports

Why wrong: The correct sequence places designated port selection after root port selection on non-root bridges. Each LAN segment's designated port is chosen as the port advertising the lowest root path cost to the root bridge, but that cost is known only after each bridge establishes its own root port and its resulting root path cost. Attempting to designate ports first would produce inconsistent decisions because switches would not yet have resolved their best path toward the root, making the segment-level comparison invalid.

Step 1: Blocking of alternate ports, Step 2: Root bridge election, Step 3: Root port selection, Step 4: Designated port selection

Why wrong: Blocking alternate ports is the final outcome of successful STP convergence, not a preliminary action. Switches begin in the blocking state and migrate to listening and learning while exchanging BPDUs; only after the root bridge is elected and root and designated ports are assigned can a switch decide that a port is an alternate and keep it in discarding state to prevent loops. If blocking occurred first, the topology would never form because essential BPDU exchanges would be silenced.