Dell Networking Associate (D-NWG-FN-23) common mistakes
Dell Networking Associate (D-NWG-FN-23) · Understand the traps and how to avoid them.
Treating the Dell EMC and Dell Technologies product naming as interchangeable and selecting an answer based on the older PowerConnect/Force10 naming rather than the current OS10/OS9/SmartFabric OS split.
Study material written before the rebranding still circulates, and candidates memorize model numbers without mapping each to its operating system and role (fixed-form campus, chassis, leaf/spine, storage fabric).
What to do instead
Build a one-page table with columns for platform family, operating system, typical deployment tier, and management interface, then fill it from Dell's current documentation rather than third-party summaries. Practice classifying each platform by whether it runs OS10, OS9, or SmartFabric OS before memorizing any speeds or port counts.
Answering spanning-tree questions by recalling generic 802.1D behavior when the scenario specifies Rapid PVST+, MST, or a Dell-proprietary loop-prevention feature, and applying the wrong port state or convergence timing.
Most candidates learned one STP flavor in a vendor-neutral course and assume port roles, timers, and per-VLAN behavior are identical across variants.
What to do instead
For each STP variant, write out port roles, port states, which device holds the root per VLAN or instance, and what triggers a topology change. Then work scenario questions where a root bridge election or an edge-port misconfiguration is the deciding factor, and justify the answer by naming the specific variant's rules.
Confusing routed-port and switched-port configuration, or assuming a VLAN interface is required when the design calls for an untagged routed link, and therefore mispredicting whether traffic is bridged or routed.
Candidates memorize command syntax without a mental model of how the forwarding pipeline treats a frame entering a port with no VLAN membership versus a port in access mode.
What to do instead
Draw the packet path for four cases: access port to access port, trunk to trunk, routed port to routed port, and VLAN interface to trunk. For each, state where the Layer 2 lookup ends and the Layer 3 lookup begins. Answer practice questions by tracing the path before reading the options.
Choosing a routing protocol or path based only on administrative distance while ignoring prefix length, metric, and protocol-specific tie-breakers in a multi-protocol scenario.
Administrative distance is the easiest number to memorize, so candidates apply it as a single ranking rule and forget that longest-prefix match is evaluated first.
What to do instead
Work a set of route-table questions where several protocols advertise overlapping prefixes, and for each write the order of evaluation: longest prefix, then administrative distance, then metric, then protocol tie-breakers. Verify each answer against a route table you construct yourself rather than recalling one.
Treating VXLAN as a replacement for the underlay routing protocol, or assuming VXLAN encapsulation removes the need for an IP-routed fabric between leaf and spine.
VXLAN is described as an overlay, and candidates conflate the overlay's job (segment extension and mobility) with the underlay's job (loop-free reachability between tunnel endpoints).
What to do instead
Write two separate diagrams for the same design: one showing the underlay with routed links and loopback endpoints, one showing the overlay with VNIs mapped to VLANs. Explain in your own words what breaks if the underlay is Layer 2 only, and what breaks if the overlay is missing. Answer fabric questions by first identifying which layer the question is about.
Mixing up 802.1X supplicant, authenticator, and authentication server roles, and placing the policy decision on the switch instead of the RADIUS server.
All three roles sit on the same path, and in a single-switch lab the distinction is invisible because one device appears to do everything.
What to do instead
Label each role on a diagram with the protocol each pair speaks (EAPOL between supplicant and authenticator, RADIUS between authenticator and server). Then answer questions by asking which device holds the credential store and which device merely relays. Practice with scenarios where the server is unreachable to confirm which component fails open or closed.
Assuming a monitoring or automation feature is available on every platform in the portfolio, rather than tying it to the operating system, license, or management mode the scenario specifies.
Feature names such as telemetry, RESTCONF, or fabric management appear in marketing material without the platform constraints, so candidates learn the feature and not its prerequisites.
What to do instead
For each management and automation capability you study, record three facts: which operating systems support it, whether a license or mode is required, and what the alternative is on platforms that lack it. When a question names a platform, eliminate options that require an unsupported capability before evaluating the rest.
Diagnosing a high-availability failure by looking only at the redundancy protocol state and not at the underlying link, license, or configuration-synchronization prerequisites that determine whether failover can actually occur.
Failover protocols report a state that looks healthy even when a prerequisite such as matching firmware, synchronized configuration, or a redundant management path is missing.
What to do instead
Build a pre-failover checklist for each redundancy mechanism you study: firmware parity, configuration sync, redundant links, redundant power, and redundant management access. For troubleshooting questions, walk the checklist in order and state which single missing item explains the observed symptom.
Reading a symptom as a single-cause fault instead of isolating the layer, so a duplicate address, an MTU mismatch, or an asymmetric path is misattributed to a hardware failure.
Exam scenarios present a symptom and several plausible causes, and candidates jump to the most familiar cause rather than the one the evidence supports.
What to do instead
Adopt a fixed triage order for every troubleshooting question: physical and link state, then Layer 2 forwarding, then addressing and ARP, then routing, then transport and MTU. State what evidence would confirm or exclude each candidate cause, and choose the option that matches the evidence given rather than the most dramatic cause.
Memorizing port numbers, cable categories, and address ranges as isolated facts without connecting them to the design decision the question is testing, such as why a particular medium or subnet size is chosen.
Fundamentals questions reward recall, so candidates drill trivia lists and then fail questions that ask for the consequence of a choice rather than the definition.
What to do instead
For each fundamental fact you review, write one sentence on the design consequence: what fails, what is limited, or what must be configured differently because of it. Practice explaining choices such as subnet sizing or medium selection to an imaginary colleague, and answer questions by identifying the design constraint first.