Skip to content
Log in Sign up My account

ENARSI Troubleshooting Simulations

Twelve original trouble-ticket labs written against the ENARSI 300-410 v1.1 exam topics. Each one gives you a fully working baseline, a set of faults to inject, the ticket as a user would report it, and a worked root-cause analysis for every fault.

What these are, and what they are not

These are original practice scenarios in the style of a troubleshooting simulation. They are not copies or reconstructions of real exam items. Cisco does not publish how many simulations appear on 300-410 or exactly how they are scored, so treat these as skill builders, not as a preview of specific questions.

How ENARSI troubleshooting simulations work

ENARSI is a troubleshooting exam. Most of the blueprint verbs are "troubleshoot", and the simulation style that suits it is the trouble ticket: a small network that used to work, a short complaint from a user or another team, and access to the device CLIs. Your job is to find what changed and put it right without breaking anything else.

Things that make ticket-style items different from multiple-choice questions:

  • Several faults hide behind one complaint. Fixing the first fault often reveals the second. A ticket is not done until the stated requirement is met end to end.
  • Requirements are part of the ticket. "Branch traffic must prefer ISP-A" is as much a fault as "the neighbor is down". A network that pings but violates the stated policy is still broken.
  • There is no copy and paste of a known-good config. You must read show output, form a hypothesis, test it, and fix it with the minimum change.
  • Restrictions matter. Typical constraints are "do not use static routes", "do not change the IGP on R2", or "do not remove the existing route map". Breaking a restriction to make a ping work is a wrong answer.
  • Time is limited. You do not get extra time for simulations, so a disciplined method beats random poking.

A method for working any ticket

Use the same seven steps every time. It keeps you from fixing symptoms instead of causes.

  1. Read the whole ticket twice. Write down every requirement and every restriction. Note which devices you are allowed to change.
  2. Reproduce the symptom. Run the exact test the user describes (ping, traceroute, show ip route for the prefix). Do not trust the ticket's guess at the cause.
  3. Follow the packet. Start at the source and check the routing decision hop by hop: show ip route <dest>, then show ip cef <dest> if needed, then the same on the next hop. The first device that makes a wrong or missing decision is where you look harder.
  4. Check the control plane at that device, bottom up. Interface up and addressed, neighbor up, routes received, routes accepted by policy, best path chosen, route installed. Each layer has one or two show commands that answer it.
  5. Compare against the requirement and against the other side. Most faults are a mismatch: two ends of a link that disagree, or a policy that does not match what the ticket requires.
  6. Fix with the smallest change, then retest the original symptom. If the symptom changes but does not disappear, you have found one fault of several. Go back to step 3.
  7. Verify every requirement, then save. Re-read the ticket and prove each requirement with a show command. Save the configuration (copy running-config startup-config).

Show commands first, debugs second

Debugs are useful in a lab, but on a real or simulated device a broad debug can flood the console. Prefer targeted show commands, and when you do debug, use conditional or narrow debugs (debug ip ospf adj, debug eigrp packets hello, debug ip bgp updates) and turn them off with undebug all as soon as you have your answer.

How to use these labs

Each lab page has the same sections:

Section What it is for
Topology and addressing A Mermaid diagram with interfaces and subnets, plus an addressing table
Baseline configuration A complete working configuration for every device, in collapsible blocks
Verify the baseline The show commands and output that prove the baseline works. Save it here.
Break it Fault-injection commands in a collapsed block. A study partner or a script applies them.
Trouble ticket What the user reports, including requirements and restrictions
Symptoms What you see when you start the ticket
Root cause and fix One collapsed block per fault: the diagnostic commands, the output lines that reveal it, and the fix

Working alone? Paste the fault-injection block yourself, wait a few minutes, then clear your console scrollback and treat the ticket as new. You will remember roughly what you broke, so focus on proving each fault with show output before you fix it.

All labs follow the lab setup addressing convention: Loopback0 on router N is 10.255.255.N/32, and the point-to-point link between routers A and B is 10.A.B.0/30 with the lower-numbered router taking .1. Where a lab needs something different (Internet-style underlay, VRF subinterfaces), the page says so.

CML images

IOSv interfaces are named GigabitEthernet0/0 to 0/3. Catalyst 8000v interfaces are named GigabitEthernet1, 2, 3 and so on. Sim 12 uses a Catalyst 8000v for Flexible NetFlow; every other lab runs on IOSv alone. LAN segments are modelled as loopbacks where no real host is needed, which keeps each lab under 4 GB of RAM except sim 12.

Ready-made lab files

Every lab page has a Download the lab box with a CML lab file and an EVE-NG lab file that bring up the topology and starting configs in one import. All labs fit the 5-node limit of CML-Free except ENCOR Sim 10 (8 nodes).

The twelve simulations

Sim Title Blueprint Difficulty Time target Faults
01 EIGRP named mode: adjacency, authentication and stub 1.9.a, 1.9.b, 1.9.d Medium 20 min 3
02 EIGRP feasible successor and unequal-cost load balancing 1.9.b, 1.9.c, 1.9.e, 1.9.f Hard 25 min 3
03 OSPF adjacency faults: authentication, network type, MTU 1.10.b, 1.10.c Medium 20 min 3
04 OSPF virtual link and totally NSSA 1.10.c Hard 25 min 3
05 Mutual redistribution OSPF and EIGRP: routing loop and tags 1.1, 1.2, 1.3, 1.4 Hard 30 min 3
06 iBGP with a route reflector and next-hop-self 1.11.b, 1.11.d Medium 20 min 3
07 BGP path selection policy: local preference, prepend, transit 1.2, 1.11.c, 1.11.e Hard 30 min 3
08 PBR, VRF-Lite and BFD 1.6, 1.7, 1.8 Hard 30 min 3
09 DMVPN phase 3 with IPsec 2.3 Hard 30 min 3
10 MPLS LDP and L3VPN 2.1, 2.2 Hard 30 min 3
11 Infrastructure security: CoPP, uRPF and AAA 3.1, 3.2, 3.3, 4.1 Medium 25 min 3
12 Infrastructure services: DHCP relay, IP SLA tracking, SNMPv3 4.2, 4.4, 4.5, 4.6 Medium 25 min 3

The time targets assume you have already built and saved the baseline. On exam day you will have far less time per item, so the goal is to get each lab under its target, then keep cutting.

Show commands worth memorising

Protocol Neighbors Interfaces and settings Routes and policy
EIGRP classic show ip eigrp neighbors show ip eigrp interfaces detail show ip eigrp topology all-links
EIGRP named show eigrp address-family ipv4 neighbors detail show eigrp address-family ipv4 interfaces detail show eigrp address-family ipv4 topology
OSPF show ip ospf neighbor show ip ospf interface brief show ip ospf database, show ip ospf virtual-links
BGP show ip bgp summary show ip bgp neighbors <ip> show ip bgp <prefix>, show ip bgp neighbors <ip> advertised-routes
Redistribution show ip protocols show route-map show ip route <prefix> (look at Tag and Known via)
MPLS show mpls ldp neighbor show mpls ldp discovery detail show mpls forwarding-table, show bgp vpnv4 unicast all
DMVPN show dmvpn show ip nhrp nhs detail show ip nhrp, show crypto isakmp sa, show crypto ipsec sa
Services show track show ip sla statistics show snmp user, show flow monitor <name> cache