Cisco ENNA 300-445 common mistakes
Cisco ENNA 300-445 · Understand the traps and how to avoid them.
Reading a routing table entry and treating the lowest administrative distance as the winner without first checking the longest prefix match, so a /24 learned via OSPF is discarded in favour of a /16 static route to the same destination.
Candidates memorise the AD table (connected 0, static 1, EIGRP 90, OSPF 110, RIP 120) as a single decision rule and apply it across different prefix lengths. AD is only a tiebreaker between routes to the same prefix; longest match is always evaluated first.
What to do instead
Before every routing-table question, restate the order: (1) longest prefix match, (2) lowest AD among routes to that exact prefix, (3) lowest metric among equal-AD routes. Practise by writing a table of destinations and prefix lengths, sorting by prefix length first, then applying AD only within each equal-length group.
Configuring an 802.1Q trunk between two switches and assuming all VLANs pass, without checking that the native VLAN matches on both ends and that the allowed VLAN list includes the VLANs in use.
Lab practice often uses a single VLAN or default settings, so native VLAN mismatch and pruning of the allowed list never surface. In production-style scenarios a mismatch causes CDP/LLDP native VLAN warnings and untagged traffic leaking into the wrong VLAN, while a missing allowed VLAN silently drops user traffic.
What to do instead
Build a trunk checklist: same native VLAN both ends, explicit switchport trunk allowed vlan list verified against the VLANs actually needed, and consistent encapsulation. For troubleshooting questions, check show interfaces trunk for the allowed-and-active list and show interfaces switchport for native VLAN before blaming STP.
Assuming a port in a spanning-tree blocking state is down or faulty and replacing it, rather than recognising it as a normal discarding/blocking role on a redundant link.
Candidates conflate 'not forwarding' with 'broken'. They also mix up RSTP port roles (root, designated, alternate, backup) with port states (discarding, learning, forwarding), so a stable alternate port looks like a fault.
What to do instead
Learn the RSTP mapping explicitly: discarding covers disabled, blocking and listening. When a question shows a port not forwarding, first identify the topology (is there a redundant path?), then the role, then the state. Verify with show spanning-tree and confirm the root bridge and root port before concluding anything is wrong.
Answering subnetting questions by estimating instead of computing, producing an off-by-one error in usable host ranges or broadcast addresses for /30, /31 and /32 prefixes.
Time pressure plus mental arithmetic leads candidates to subtract two hosts from every prefix. /31 point-to-point links (RFC 3021) have two usable addresses and no broadcast, and /32 is a single host route; these exceptions are commonly missed.
What to do instead
Use a fixed written method: block size = 256 minus the interesting octet mask value; network address is the block boundary at or below the address; broadcast is the next boundary minus one. Memorise the /30, /31 and /32 exceptions separately and re-derive the host range for any answer you are unsure of.
Treating a DHCP relay problem as a server problem, or placing the ip helper-address on the wrong interface, so clients on a remote subnet never receive an address.
Candidates remember that helper-address forwards broadcasts but forget it must be configured on the router interface facing the clients (the default gateway), and that the DHCP server needs a route back to that subnet. They also overlook that the relayed packet's source is the client-facing interface address.
What to do instead
Trace the path in order: client broadcasts on its segment, the local router interface with ip helper-address converts it to unicast to the server, the server picks a pool matching the giaddr, and the reply is routed back. Check the helper is on the client-facing SVI or physical interface and verify the server pool matches the relay address, not the server's own subnet.
Configuring an access control list and applying it in the wrong direction or on the wrong interface, then concluding the ACL logic itself is wrong.
Extended ACLs are written from the perspective of the interface they are applied to, and candidates mentally test them from the source host's viewpoint. They also forget the implicit deny any at the end and the fact that a single ACL can be applied to only one interface and direction at a time.
What to do instead
For every ACL question, state the interface, the direction relative to that interface, and the source/destination pair as seen at that point. Test the first few packets mentally against the top-down order, and remember the implicit deny. Verify with show ip interface and show access-lists, which display match counters per line.
Mixing up first-hop redundancy roles, assuming the physical interface with the highest IP is always the active gateway in HSRP, and forgetting VRRP uses the highest priority with preemption enabled by default.
HSRP and VRRP differ in defaults: HSRP priority default is 100 with preemption disabled, VRRP default is 100 with preemption enabled, and VRRP uses the highest IP as tiebreaker whereas HSRP uses the highest IP on the active router as tiebreaker. Candidates learn one protocol and generalise.
What to do instead
Build a comparison table for HSRP, VRRP and GLBP covering default priority, preemption default, virtual MAC format, and tiebreaker. When solving, write out each router's priority and preemption state before deciding the active device, and check whether a tracked object has decremented priority.
Choosing a dynamic routing protocol or path based only on metric values across different protocols, or forgetting that floating static routes depend on AD rather than metric.
Candidates compare OSPF cost with EIGRP composite metric as if they were commensurable, and they forget that a floating static works by setting a higher AD than the primary route. They also miss that OSPF cost is reference bandwidth divided by interface bandwidth, which defaults to 100 Mbps and flattens all links faster than that.
What to do instead
Never compare metrics across protocols; compare AD. For floating statics, state the AD explicitly and confirm it sits between the primary protocol's AD and the backup's. For OSPF, check the reference bandwidth (auto-cost reference-bandwidth) whenever links exceed 100 Mbps, since otherwise a 1 Gbps and 10 Gbps link score identically.
Describing automation or SDN concepts only at the buzzword level, so answers about controller-based architecture, RESTCONF versus NETCONF, or YANG models cannot be distinguished from plausible-sounding alternatives.
Candidates from a traditional routing and switching background skip the programmability domain, learning definitions without the operational distinctions: NETCONF uses SSH port 830 and XML, RESTCONF uses HTTPS and JSON or XML, YANG is the data model not the transport, and a controller centralises the control plane while devices keep the data plane.
What to do instead
Learn each technology by its transport, encoding and purpose as a triple, and practise reading a small JSON payload and a YANG-style tree to identify what is being configured. For architecture questions, draw the control-plane, data-plane and management-plane split and place the controller explicitly.
Answering security-fundamentals questions by naming a feature (port security, DHCP snooping, dynamic ARP inspection) without stating its prerequisites and the direction it protects.
These features are interdependent: dynamic ARP inspection requires DHCP snooping bindings, DHCP snooping requires trusted ports toward the legitimate server, and port security interacts with sticky MAC learning and violation modes. Candidates learn the names but not the dependency chain, so they pick an answer that would not actually function.
What to do instead
For each Layer 2 security feature, memorise three things: what it inspects, which ports must be trusted, and what it depends on. Then rehearse a scenario end to end, for example enabling DHCP snooping, marking the uplink trusted, confirming bindings populate, and only then enabling dynamic ARP inspection on the user VLANs.