CCNA v2.0 expects more than recognizing networking terms. Cisco's published objectives repeatedly use verbs such as diagnose, troubleshoot, configure, validate, interpret, select, and use. A useful study session should therefore end with something you can inspect: interface state, a routing table, a neighbor relationship, a configuration fragment, a packet exchange, a log message, or a failed path you can explain.
The five domains overlap heavily. A trunk problem can appear to be an IP problem. A missing route can look like an access control list (ACL) failure. A Dynamic Host Configuration Protocol (DHCP) relay issue can leave a perfectly healthy switchport attached to a client that still has no usable address. Treat the blueprint as one network rather than five disconnected lists.
Choose the right blueprint for your test date
Cisco has published the 200-301 CCNA v2.0 topics for exams beginning February 3, 2027. The current v1.1 exam remains available through February 2, 2027.
Testing by February 2, 2027? Use the current v1.1 blueprint for exam-specific coverage. Testing February 3, 2027 or later? This guide follows the published v2.0 blueprint.
Many core skills carry across both versions. Subnetting, switching, routing, wireless, security, and network operations remain useful regardless of the test date. The version check matters because the organization and depth of the objectives change.
How to use this guide
For each objective, build four kinds of fluency:
- Explain it. Describe what the technology does and where it fits in the traffic path.
- Configure it. Enter the small set of commands needed when the blueprint expects configuration.
- Verify it. Know which command, table, log, or client-side observation proves the intended state.
- Troubleshoot it. Recognize the symptom produced when one part is wrong and choose the next useful check.
Suppose you are studying DHCP relay. Memorizing ip helper-address is not enough. You should also know why the relay is needed across a routed boundary, which client-facing interface receives the broadcast, how the server identifies the requesting subnet, which command confirms leases on an IOS DHCP server, and what a client looks like when the exchange fails.
The same approach applies to switching and routing. If you configure a trunk, inspect the operational trunk state. If you configure Open Shortest Path First (OSPF), verify the adjacency and then the learned route. If you configure an ACL, check both the rule order and where the ACL is applied.
The five CCNA v2.0 domains
| Domain | Weight | What the work looks like |
|---|---|---|
| 1.0 Network Infrastructure and Connectivity | 25% | Diagnose links and cabling, troubleshoot IPv4 and IPv6, understand virtualization and wireless behavior, isolate client connectivity faults, and troubleshoot Dynamic Host Configuration Protocol version 4 (DHCPv4). |
| 2.0 Switching and Network Access | 25% | Configure physical interfaces, virtual local area network (VLAN) trunks, Link Aggregation Control Protocol (LACP) EtherChannel, switch virtual interfaces, edge ports, and Rapid Per-VLAN Spanning Tree Plus (Rapid PVST+), then validate topology and operations from device evidence. |
| 3.0 IP Routing | 20% | Interpret route selection, troubleshoot IPv4 and IPv6 static routes, configure single-area OSPFv2 and OSPFv3, and interpret first-hop redundancy state. |
| 4.0 Network Services and Security | 20% | Configure management authentication, secure file transfer, Network Address Translation (NAT) and Port Address Translation (PAT), IPv4 access control lists (ACLs), and Layer 2 protections while diagnosing Domain Name System (DNS) and virtual private network (VPN) behavior. |
| 5.0 AI, and Network Operations and Management | 10% | Use sound prompts and judgment with artificial intelligence (AI)-assisted operations, compare management approaches, understand Simple Network Management Protocol (SNMP), execute commands through Ansible, and interpret syslog. |
The weights help allocate study time, but they do not create hard walls. show interfaces can support Domain 1 link diagnosis and Domain 2 device troubleshooting. Syslog belongs in Domain 5, yet a log message may expose a Domain 2 or Domain 3 fault.
Domain 1: Network Infrastructure and Connectivity
Domain 1 begins at the physical link and continues through endpoint connectivity. Cisco expects you to diagnose copper and fiber problems, understand the network role of hypervisors, virtual machines, and containers, troubleshoot IPv4 and IPv6 addressing, reason about wireless radio frequency (RF) behavior and security, and troubleshoot Dynamic Host Configuration Protocol version 4 (DHCPv4) on IOS devices.
A strong Domain 1 workflow answers questions in this order:
- Is the physical or wireless link usable?
- Does the endpoint or interface have the expected address and prefix?
- Is the destination local or remote from the source's perspective?
- Is the default gateway or next hop reachable?
- If addressing is dynamic, did DHCP complete and did the correct scope apply?
- If wireless is involved, did association and authentication succeed before IP troubleshooting begins?
Read the full Domain 1: Network Infrastructure and Connectivity guide for link counters, cabling clues, IPv4 and IPv6 examples, modified Extended Unique Identifier 64-bit (EUI-64), wireless troubleshooting, endpoint commands, DHCP configuration, and an integrated fault-isolation example.
For subnet calculations, use the IPv4 Subnetting Reference and IPv4 Subnet Calculator as supporting tools. Work the calculation manually first, then use the calculator to check it.
Domain 2: Switching and Network Access
Domain 2 moves from a working link to the switching behavior built on top of it. The v2.0 objectives include Layer 2 and Layer 3 physical interfaces, 802.1Q trunks, Layer 2 and Layer 3 Link Aggregation Control Protocol (LACP) port channels, switch virtual interfaces (SVIs), edge-port attributes, Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP) validation, troubleshooting from operational evidence, and Rapid Per-VLAN Spanning Tree Plus (Rapid PVST+).
Build the concepts around observable state:
- A virtual local area network (VLAN) existing in the database does not prove that a host port belongs to it.
- An administratively configured trunk does not prove that the interface is operationally trunking.
- An EtherChannel configuration does not prove that every member joined the bundle.
- A healthy physical link does not prove that spanning tree is forwarding on it.
- Network documentation can be wrong. CDP and LLDP give you live neighbor evidence to compare with the diagram.
Useful verification commands include show vlan brief, show interfaces switchport, show interfaces trunk, show etherchannel summary, show spanning-tree, show cdp neighbors, and show lldp neighbors.
Read the full Domain 2: Switching and Network Access guide for Layer 2 and Layer 3 interfaces, trunk configuration, LACP EtherChannel, SVIs, edge-host ports, neighbor validation, troubleshooting evidence, and Rapid PVST+.
Use the Cisco IOS Verification and Troubleshooting Commands reference to connect each command to the question it answers. The VLANs, Trunks, Spanning Tree Protocol (STP), and LACP quick review is useful when the Layer 2 concepts need a vendor-neutral refresher before you return to Cisco configuration.
Domain 3: IP Routing
Routing questions become much easier when you separate route presence from route selection.
A routing table entry gives you a candidate path. Forwarding still depends on the destination matching that prefix, the next hop or exit interface being usable, and a valid return path existing when the application requires two-way communication.
For every routing table line, practice identifying:
- Route source
- Destination prefix and mask
- Administrative distance when shown
- Metric when shown
- Next hop
- Exit interface
- Whether a more-specific match exists
The longest matching prefix determines the forwarding choice among matching routes. A default route is therefore a fallback, not a command to ignore more-specific entries.
The v2.0 scope also includes IPv4 and IPv6 default, network, host, and floating static routes; single-area Open Shortest Path First version 2 (OSPFv2) for IPv4; version 3 (OSPFv3) for IPv6; and operational interpretation of Hot Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP).
A good routing lab does not end when a route appears. Verify the neighbor when a routing protocol is involved, inspect the routing table, test the path, then deliberately break one condition and use the evidence to locate it.
Read the full Domain 3: IP Routing guide for route-table interpretation, IPv4 and IPv6 static routes, floating statics, single-area OSPFv2 and OSPFv3, broadcast and point-to-point behavior, and HSRP/VRRP operational state.
Domain 4: Network Services and Security
Domain 4 combines services that make the network usable with controls that decide who may manage or cross it.
The v2.0 blueprint includes:
- Local usernames and authentication, authorization, and accounting (AAA) client configuration with Terminal Access Controller Access-Control System Plus (TACACS+) and Remote Authentication Dial-In User Service (RADIUS)
- Secure Shell (SSH) File Transfer Protocol (SFTP) and Secure Copy Protocol (SCP) for secure file transfer
- Network Address Translation (NAT) and Port Address Translation (PAT) on IOS XE routers
- Domain Name System (DNS) record diagnosis for A, AAAA, CNAME, MX, NS, and PTR records
- Remote-access and site-to-site Internet Protocol Security (IPsec) virtual private network (VPN) concepts
- Standard, extended, numbered, and named IPv4 access control lists (ACLs)
- Dynamic Host Configuration Protocol (DHCP) snooping; Address Resolution Protocol (ARP) validation through Dynamic ARP Inspection (DAI); storm control; Router Advertisement guard; and port security
Study these by following traffic. An ACL is an ordered decision applied to traffic at a specific interface and direction. NAT changes address representation at a translation boundary. DHCP snooping builds trust around address assignment. Dynamic ARP Inspection uses trusted information to reject invalid ARP behavior. The control makes more sense when you can describe the packet or frame it is evaluating.
The Common Ports and Protocols Reference is useful for services such as DNS, TACACS+, RADIUS, SSH-based file transfer, and other management traffic.
Domain 5: AI, and Network Operations and Management
The smallest weighted domain still affects how modern networks are operated. Cisco's v2.0 objectives include agentic artificial intelligence (AI), prompt selection for generative AI, device-, cloud-, controller-, automation-, and infrastructure-as-code management approaches, Simple Network Management Protocol (SNMP), Ansible, and syslog.
The AI portion deserves the same evidence discipline as ordinary troubleshooting. A generated recommendation is input to an engineering decision, not proof that the proposed change is correct. A useful prompt should give the system enough context to answer the actual network question while respecting data classification and clearly requesting the needed output format.
For example, compare these two requests:
Why is routing broken?
and:
Analyze the sanitized routing table and interface summary below. Identify the most likely reason 192.0.2.0/24 is unreachable, list the evidence supporting that conclusion, and recommend one verification command before any configuration change.
The second request supplies scope, evidence, a task, and an output expectation. You still verify the recommendation against device state and authorized network information.
For syslog, practice extracting the facility, severity, mnemonic, and message meaning rather than treating the entire line as one string to memorize.
Treat command output as study material
Configuration syntax matters, but troubleshooting depends on recognizing what the device is telling you after the configuration exists.
When reviewing output, ask:
- What state is being shown? Interface, VLAN, route, neighbor, policy, lease, translation, or log event?
- What would healthy look like? Know the expected baseline before deciding the output is wrong.
- Which field is the strongest clue? Avoid reacting to every counter or line equally.
- What check would confirm the theory? Choose the next command before proposing a change.
The CCNA IOS command reference is organized around those questions. It is more useful to know why you need show interfaces trunk than to recite it without knowing what the output proves.
A practical CCNA lab loop
Use the same small loop repeatedly:
1. Build one behavior
Configure a VLAN and access port, a trunk, an EtherChannel, a static route, an OSPF adjacency, a DHCP pool, an ACL, or another single feature.
2. Verify before breaking it
Capture the healthy output. Save the relevant show commands and identify which fields prove success.
3. Break one thing
Change one variable: wrong VLAN, missing allowed VLAN, shutdown interface, wrong prefix, bad static next hop, mismatched OSPF condition, incorrect helper address, or ACL in the wrong direction.
4. Diagnose without looking at the answer
Start from the symptom. Use as few commands as practical to narrow the fault. Record which observation changed your theory.
5. Repair and prove recovery
Restore the intended configuration and run the same verification used in the healthy baseline. A fix is stronger when you can show what changed in the evidence.
Lab habit: save both the healthy and broken output. Learning what normal looks like makes abnormal output much easier to recognize under exam pressure.
Readiness checklist
You are building useful CCNA v2.0 readiness when you can:
- Read an interface summary and distinguish administrative, physical, and protocol state.
- Explain which cable, optic, speed, duplex, or signal clue could cause a link symptom.
- Calculate an IPv4 subnet and explain whether two addresses are local to each other.
- Read and configure basic IPv6 addressing without treating it as oversized IPv4.
- Separate wireless association, authentication, IP assignment, DNS, and routed reachability when a client cannot connect.
- Trace DHCP through a client, relay, and server.
- Verify VLAN membership, trunk state, EtherChannel membership, and spanning-tree roles from output.
- Interpret a routing table by prefix, source, distance, metric, next hop, and exit interface.
- Verify OSPF neighbors before blaming route selection.
- Explain where NAT, ACLs, AAA, and Layer 2 protections affect traffic.
- Read a syslog message and use it as evidence rather than as a configuration instruction.
- Evaluate AI-assisted recommendations against network state before applying a change.