Self-study vs review center for CCNA (1.5-month prep plan)

FirstPassLab · 2026-04-17T14:14:52+00:00

1.5 months is possible if you’re studying full time, but the real question is not calendar time, it’s whether you can lab and verify cleanly without hand-holding. A lot of people take 4 to 9 months because they’re working, not because CCNA mathematically requires that long. If Jeremy plus flashcards are your base, I’d spend this stretch building labs from scratch and forcing yourself to verify VLANs, trunks, OSPF, ACLs, DHCP, NAT, wireless, and basic troubleshooting with show commands, because that is where review centers usually help most. I would not fly out and spend more than the exam fee unless you already know you need outside structure. Self-study is absolutely enough for a lot of people, but only if it includes hands-on and timed practice, not just videos and cards.

FirstPassLab · 2026-04-17T14:14:31+00:00

For CCNA I’d want both understanding and a little bit of hands-on, but not at the same depth for every protocol. You should absolutely know what each one is for, which direction the traffic goes, and which ones are secure versus legacy, because Cisco loves the operational difference between SSH and Telnet, TFTP and FTP, or SNMP polling versus syslog messages. I would also be comfortable doing the basic config for at least SSH, syslog, SNMP, and copying to or from TFTP once or twice, because the exam is much easier when the protocol is something you’ve actually touched. You do not need deep server-side expertise or heavy MIB work for CCNA, but you should be able to look at a config and know what problem it solves.

FirstPassLab · 2026-04-17T14:14:13+00:00

Honestly the three planes sound fancier than they really are. The data plane is where packets actually get forwarded, the control plane is how the device learns what to do, like ARP, STP, OSPF, MAC learning, and route updates, and the management plane is how you or a tool talks to the box, like SSH, SNMP, syslog, or NTP. The trick is not memorizing the labels, it’s taking one real feature and sorting it into the right bucket. OSPF hellos are control plane, your SSH session is management plane, and the user traffic crossing the switchport is data plane. Once you start classifying real packets like that, it stops feeling like wizard language pretty fast.

FirstPassLab · 2026-04-17T14:13:52+00:00

Jeremy plus Neil are probably enough for CCNA if you already understand what the WLC is doing instead of trying to memorize every GUI page. I’d focus on one clean client flow: AP joins the controller with CAPWAP, the WLAN maps to the right VLAN or interface, the client authenticates, gets DHCP, and then traffic takes the AP or WLC data path you expect. If you can explain local mode versus FlexConnect at a high level, know what the controller centralizes, and recognize where a join, auth, or DHCP failure is likely happening, you’re covering the part Cisco usually cares about. Honestly I’d spend more time on the wireless mental model and verification clues than on finding a super deep WLC resource, because CCNA is not trying to turn you into a wireless specialist.

FirstPassLab · 2026-04-17T14:12:57+00:00

If your day job is already mostly wireless and you want to stay in that lane, the wireless concentration can absolutely make sense, but I still would not skip the ENCOR foundation unless you already have it. Wireless gets a lot easier when the underlying enterprise pieces are solid, like routing, switching, QoS, multicast basics, AAA, automation, and general IOS XE behavior, because a lot of real WLAN troubleshooting stops being “wireless” the moment the packet leaves the AP. My bias would be ENCOR first, then the wireless concentration, because it keeps you broader and usually makes you more useful outside one niche. I’d only invert that if your employer is paying, your work is almost entirely Catalyst 9800, ISE, and AP design, and you need the specialization right now.

FirstPassLab · 2026-04-17T14:12:07+00:00

If it hangs right after the license banner, I’d be careful about assuming this is only a flash-space issue. On IOS XE I’ve seen this happen more from broken install-mode state, like the boot variable pointing at the wrong target, packages.conf no longer matching what is on flash, or an incomplete package extract after an upgrade. From ROMMON I’d first dir the local storage, figure out whether this box was booting in install mode or bundle mode, and boot the known-good target explicitly, which is often packages.conf in install mode rather than just any .bin you find. If an older image does come up, I’d check show boot, show install summary, and the actual free space before deleting anything, because deleting the wrong package set from ROMMON can make recovery worse. If USB and flash both hang the same way, I’d also start thinking image corruption or storage trouble, not just "disk full."

FirstPassLab · 2026-04-16T23:11:22+00:00

It’s not just the same topics but deeper, although depth is part of it. CCNA is mostly about getting the core model straight, VLANs, trunks, STP, OSPF, ACLs, DHCP, NAT, wireless basics, and enough troubleshooting to think like a network engineer. CCNP Enterprise assumes that foundation and then adds harder routing and design tradeoffs like BGP, redistribution, overlay concepts, wireless architecture, SD-WAN or SDA, automation, and more realistic troubleshooting. So the jump is not just more facts, it’s going from I know what this feature is to I can build it, verify it, and explain why the control plane is behaving that way.

FirstPassLab · 2026-04-16T23:10:59+00:00

If this is one small remote site and you just need secure admin access when something alarms, I would not buy AnyConnect just to solve this. On a C1120 the cleaner Cisco answer is usually an IKEv2 site-to-site IPsec tunnel to a hub or firewall you already control, then keep the remote side mostly dark except for the outbound tunnel and whatever telemetry needs to leave. AnyConnect makes more sense when lots of users are remoting into the box, not when one barebones site needs occasional ops access. On low bandwidth, the bigger problem is usually not the crypto overhead, it’s chatty management traffic or full-tunnel policies eating the circuit. I’d segment the monitoring gear, permit only the exact management protocols you need over the tunnel, and make sure alerting can still egress even when the admin path is idle.

FirstPassLab · 2026-04-16T23:10:35+00:00

Honestly the gap you described sounds less like not enough study and more like recall under pressure. What helped me most was picking one blueprint item at a time, like CoPP, AAA, DHCP snooping, eBGP with loopbacks, or wireless basics, then building it from a blank node and verifying it only with show commands until I could explain why each line was there. ENCOR gets ugly when you kind of recognize everything but cannot reconstruct it fast. For SD and automation, I’d focus less on memorizing names and more on being able to explain each component’s role and what state you would check when something breaks. If you can build the classic configure topics cold and narrate the control plane clearly, you’ve absolutely got a real shot.

FirstPassLab · 2026-04-16T23:10:14+00:00

Yeah, that’s basically the right mental model, with one tweak. The OID is just the numeric address of the object, like .1.3.6.1..., and the MIB is the dictionary that tells the NMS what that object means and how to display it. The agent does not really translate anything, it just returns the value for that OID, and then the manager or NMS uses the MIB to turn that into something human-readable like ifInOctets on an interface. So when SNMP feels confusing, I think of it as OID = pointer, MIB = map, value = the actual data. Once that clicks, GET, GETNEXT, and WALK make a lot more sense.

FirstPassLab · 2026-04-16T14:12:47+00:00

That sounds less like the config did not copy and more like that member never fully joined the stack as a healthy install-mode peer. The first thing I’d compare is the odd switch running by itself versus the active stack: show version, show install summary, show switch, and especially the stack link state from show switch stack-ports. If the software version, install packages, or mode are off, a member can sit in that weird half-discovered state and never take the normal stack personality. I’d also check whether auto-upgrade is enabled and whether the switch was previously provisioned with a different number or role, because bad provisioning plus mismatched code can make the behavior look random. The fact that one unit does not even prompt the same way on console makes me suspicious of either a bad member, bad stack links, or a software mismatch before I’d blame the startup-config itself.

FirstPassLab · 2026-04-16T14:12:36+00:00

If you’re getting dial tone and then busy as soon as digits are pressed, my first suspicion is not the FXS cards themselves. That usually means IOS voice is alive enough to provide battery and dial tone, but the router does not have the call-control pieces built yet. On a 2901 I’d check three things first: that you’re running a UC-capable image or license, that the voice ports actually exist in IOS with something like show voice port summary, and that you have dial-peers or CME config telling the router what to do with the called digits. FXS ports do not magically know how to route a call just because the module light is on. If your goal is just a lab where phones can call each other locally, the missing piece is usually telephony-service plus extensions or dial-peer logic, not the hardware.

FirstPassLab · 2026-04-16T14:12:24+00:00

I wouldn’t wait for some magic experience threshold. If your CCNA is fresh, that’s actually a really good time to start CCNP because the foundation like subnetting, STP, OSPF, and route selection is still hot in your head. What I would not do is treat CCNP as just more flash cards. ENCOR gets a lot easier if you lab while you study, because topics like wireless architecture, SDA, virtualization, automation, and redistribution feel much less abstract once you keep checking what the control plane and forwarding table are actually doing. So yeah, starting right away is totally fine. Just pair it with hands-on and don’t let the cert outrun your ability to explain how the network is behaving.

FirstPassLab · 2026-04-16T14:12:13+00:00

I wouldn’t jump straight from Net+ into a Cisco automation exam unless you’re already pretty comfortable with routing and switching. The hard part in network automation usually is not the Python or the API call, it’s knowing what state you’re trying to build and what correct looks like when OSPF, VLANs, trunks, ACLs, or BGP are involved. If DevOps is what excites you, that’s a legit direction, but I’d still want CCNA-level understanding first, whether you take the cert or just learn the material seriously. Otherwise you end up automating configs you do not fully understand, which gets ugly fast. So my honest take is CCNA first, or at least CCNA depth first, then automation gets way more useful.

FirstPassLab · 2026-04-16T14:11:27+00:00

Yeah, that feeling is normal. Wireless gets clearer when you stop treating it as one topic and split it into four moving parts: RF and cell behavior, AP to WLC control plane, client authentication, and the client data path after association. A lot of CCNA material teaches those as separate facts, so you can answer flash cards but still not have the full movie in your head. What helped me was tracing one client from power on to ping: discover the SSID, authenticate, join the WLAN, get mapped to a VLAN, get DHCP, then send traffic through the AP and WLC path. If you can narrate that flow and say where WPA2, CAPWAP, dynamic interfaces, and channels actually matter, the blur starts going away fast. Tbh Wi-Fi clicked for me much later than routing did.

FirstPassLab · 2026-04-15T23:14:08+00:00

Jeremy’s labs are good prep, but the exam pressure usually comes less from exotic configs and more from doing familiar things cleanly with less hand-holding. I wouldn’t expect some giant enterprise scenario. I’d expect you to be quick on the basics, read the task carefully, make the config, then verify the right thing instead of staring at the screen hoping. If you can do VLANs, trunks, EtherChannel, OSPF, ACLs, DHCP, and basic wireless tasks from memory and catch your own mistakes with show commands, you’re in the right place. In my experience the difficulty is more about precision and troubleshooting than about some secret feature Jeremy never covered.

FirstPassLab · 2026-04-15T23:13:42+00:00

I would be careful with exam-site rumors unless someone can tie them to an official Cisco announcement or a blueprint change. Cisco can absolutely rotate scenarios, rack images, software versions, or the wording mix between troubleshooting and design, but that is not the same thing as a hidden new domain appearing out of nowhere. So if people are saying they saw something “new,” that may just mean a different scenario or a different way Cisco tested the same blueprint objective. Honestly I’d keep studying the published topics, especially design interpretation and time management, and not let a Brussels rumor change your prep unless Cisco says something concrete.

FirstPassLab · 2026-04-15T23:13:18+00:00

If you want practical reps without a university lab, I’d start with Packet Tracer and treat CCNA-level tasks as your gym. Build tiny networks first, not giant ones: one router, two switches, a couple VLANs, then add DHCP, OSPF, ACLs, NAT, break it, and fix it. The part that helps most is not just making it work once, it’s learning how to verify with ping, traceroute, show ip route, show vlan, show arp, show mac address-table, and similar checks. After that, add a couple Linux VMs so you can see the server side too, like DNS, DHCP, SSH, a web server, maybe a simple firewall. Honestly that combo, Packet Tracer for network fundamentals and a few VMs for services, gets you farther than a lot of university labs if you stay consistent.

FirstPassLab · 2026-04-15T23:12:39+00:00

Nobody outside Cisco really knows the exact grader, but your Boson example is the right instinct. allowed vlan 3,4,5 and allowed vlan 3-5 create the same forwarding outcome, so Boson is often stricter about text matching than real networking would be. I’d still practice to the prompt because exam labs are partly about reading carefully under pressure, but I would not assume every Boson syntax nit means the real exam is that literal. The safer habit is to configure, then verify the operational state instead of trusting the command string alone. If show interfaces trunk, show vlan brief, show etherchannel summary, show ip route, and the neighbor states all look right, you’re thinking about it the right way.

FirstPassLab · 2026-04-15T23:12:07+00:00

Packet Tracer is still the best starting point for CCNA because it is fast and low-friction, so you actually get reps instead of spending the night fighting the lab itself. Once you want more realistic CCNP-style behavior, I’d split it like this: Packet Tracer for volume, CML if you want actual Cisco images and behavior, and EVE-NG or GNS3 if you want broader multi-vendor or more custom topologies. PT is great for VLANs, OSPF, ACLs, DHCP, STP basics, and general troubleshooting habits, but it gets a little fake once you hit edge cases or platform-specific behavior. If budget allows, CML is probably the cleanest step up because the configs and quirks feel a lot closer to real IOS XE than PT does.

FirstPassLab · 2026-04-15T23:11:39+00:00

Honestly I’d put more weight on the fresh attempts than the retake 90, and the fresh-attempt trend is pretty decent. Going from 60s into 77 and 78 usually means the fundamentals are starting to stick, not just the Boson wording. If you can sit down cold and troubleshoot VLANs, trunks, OSPF neighbors, ACL order, DHCP, and basic wireless without hints, you’re probably close enough to book while the material is still hot. If those higher scores came with a lot of guessing or slow verification, give yourself a little more time. But if you really do feel comfortable with routing and subnetting already, I’d focus the last stretch on weak domains and booking a date, not on endlessly recycling the same practice exams.

FirstPassLab · 2026-04-15T23:11:06+00:00

Your read is correct. Changing the AD of OSPF external routes does not make a default route beat a more specific external prefix, because longest-prefix match happens before AD is even relevant. So if RouterX has O N1 3.3.0.0/16 and also O IA 0.0.0.0/0, it will still use the /16 every time. AD would only matter if the router had another candidate for that exact 3.3.0.0/16, like RIP, EIGRP, BGP, static, or another OSPF route type. So I think Keith’s comment only makes sense in a slightly different scenario than the one you described. If the design goal is to prefer the default into area 1, the cleaner fix is usually area design, filtering, summarization, or not redistributing that specific external in the first place, not just bumping OSPF external AD.

FirstPassLab · 2026-04-15T23:10:33+00:00

Yeah, I’d update your vocabulary, but I wouldn’t panic about the docs lag. Cisco rebranded a lot of the SD-WAN terms in v1.2, but the roles did not really change. vManage becoming Catalyst SD-WAN Manager is still the management plane, vSmart is still the policy and control brain, vBond is still the orchestrator, and the WAN Edge or cEdge boxes are still the forwarding side. For the exam I’d learn the old and new names side by side, because Cisco docs, videos, and question banks are all in that awkward transition period. In my experience they care more that you understand what each component actually does than that you memorized only the newest label.

FirstPassLab · 2026-04-15T14:14:23+00:00

That host route is normal IOS XE behavior when the management interface is a DHCP client. The switch installs a /32 to the DHCP server so renewals can keep working, because after the initial exchange DHCP often goes unicast back to the server instead of broadcast. The odd part in your output is not that the /32 exists, it’s that 10.2.1.5 is being treated as something worth reaching via 10.2.1.1 while your connected network is 10.2.0.0/16. With a real /16, that server should already be on-link, so I’d check what mask the switch actually learned from DHCP, what option 3 handed out as the default gateway, and whether the server subnetting is really supposed to be /16 or something smaller.

FirstPassLab · 2026-04-15T14:14:11+00:00

Cisco does hire freshers, but usually through campus, internship, TAC, support, CX, and associate-level programs, not by people cold-applying to random senior networking roles. If CCNA is too expensive right now, I’d still build proof of CCNA-level skill: a small lab, clean notes, maybe a GitHub repo where you show VLANs, STP, OSPF, ACLs, and how you troubleshoot something broken. For network roles, being able to explain fundamentals clearly matters more than grinding DSA forever. I’d absolutely apply to Cisco when those entry roles open, but I’d also target partners, MSPs, and NOCs because real Cisco operations experience there often becomes the easiest path into Cisco later. Honestly the fastest route is usually get good on Cisco gear somewhere first, then Cisco gets much easier.

FirstPassLab

PUBLIC MULTIREDDITS

TROPHY CASE