A usable Cisco ISE 3.x lab on EVE-NG is absolutely worth building for CCIE Security, because ISE shows up in authentication, policy, TrustSec, and operational troubleshooting far more often than most candidates expect. According to Cisco’s ISE 3.3 Installation Guide (2026), the evaluation baseline is 4 vCPU, 16 GB RAM, and 300 GB disk, but in real EVE-NG use most candidates should allocate 8 vCPU if they want the GUI, policy changes, and endpoint tests to feel responsive instead of miserable.
Key Takeaway: If you build one clean single-node ISE lab with correct DNS, NTP, storage, and one working 802.1X plus MAB access port, you will cover far more exam-relevant ground than a larger but unstable topology.
If you are still mapping the overall blueprint, start with our CCIE Security v6.1 ISE lab prep guide, then come back here to build the environment. This lab also pairs well with our FTD and FMC EVE-NG firewall lab and our ISE plus TrustSec segmentation guide.
What hardware do you actually need for a Cisco ISE lab on EVE-NG?
A realistic Cisco ISE study lab needs more disk and steadier compute than most virtual router labs, because the application stack, database, and GUI are heavy even before you add endpoints. According to Cisco’s ISE 3.3 Installation Guide (2026), an evaluation VM requires 4 CPU cores, 16 GB RAM, and 300 GB disk. According to EVE-NG’s official ISE how-to (2026), the base image is roughly 16 GB, setup adds about 80 GB, and each new lab instance can consume more space again. For a CCIE Security candidate, that means the official minimum is usable, but the practical minimum is higher if you want acceptable boot times and less waiting during policy edits.
| Lab target | vCPU | RAM | Disk | My recommendation |
|---|---|---|---|---|
| Cisco evaluation minimum | 4 | 16 GB | 300 GB | Works for a single-node proof of concept |
| Comfortable CCIE practice node | 8 | 16-24 GB | 300 GB qcow2 | Best balance for most homelabs |
| Multi-node or heavy guest/posture work | 12+ | 24-32 GB | 600 GB+ total host capacity | Use only if your server is strong |
The host matters too. Give EVE-NG SSD or NVMe storage, not slow spinning disks. Cisco’s installation guide recommends storage capable of 50 MB/s write and 300 MB/s read performance. That sounds mundane, but it is the difference between a workable study platform and an ISE box that feels broken.
Should you use EVE-NG or CML for Cisco ISE practice?
EVE-NG is usually the better ISE lab platform for self-directed CCIE Security prep, because it handles appliance-style images, qcow2 disks, and mixed security topologies more flexibly than CML. CML is excellent for IOS XE, IOS XR, NX-OS, and blueprint-adjacent routing and switching work, and our CML vs INE vs GNS3 comparison explains where it shines. But Cisco ISE behaves more like an application appliance than a router, so EVE-NG’s generic KVM workflow is usually less painful.
The tradeoff is operational overhead. EVE-NG gives you more freedom, but you own the image import, disk sizing, permissions, and first-boot cleanup. CML gives you a cleaner experience for supported network images, but it is less convenient when you want to mix ISE, FMC, FTD, guest VMs, and custom security tooling into one exam lab. For most candidates, the winning split is simple: use EVE-NG for your full security stack, and use CML separately when you want fast, repeatable Cisco-only routing labs.
How do you import Cisco ISE 3.x into EVE-NG without wasting a day?
The cleanest ISE import workflow is to download the ISO from Cisco with a valid CCO account, create one qcow2 disk, complete the installer once, then save that baseline as your gold image. According to Cisco’s ISE Licensing Guide (2026), a fresh install includes a 90-day evaluation license for 100 endpoints with all features enabled, so you do not need to overthink licensing for a study lab. According to Cisco Community VIP Arne Bier (2024), “ISE will run under EVE-NG,” but the hard disk must be qcow2 and large enough to grow, which is exactly where many candidates go wrong.
Use this sequence:
- Download the ISO from Cisco Software Central. Stick with a current 3.x release that matches the features you want to study.
- Create the EVE-NG image directory and upload the ISO. The EVE-NG official guide uses a dedicated folder under
/opt/unetlab/addons/qemu/. - Create one qcow2 disk. Even if older EVE examples show 200 GB, follow Cisco’s current evaluation guidance and provision 300 GB for a fresh study build.
- Boot with VNC for the first install. Complete the text installer and let the system finish its first restart.
- Commit the clean disk and remove the ISO. That becomes your reusable baseline image.
- Fix permissions before cloning nodes. Skipping this wastes more time than the install itself.
One important warning, according to Cisco (2026): ISE does not support VM snapshots, and snapshots can corrupt the configuration or database. Save time by making a gold image at the hypervisor file level, not by treating ISE like a lightweight router VM.
What should you enter during the first boot and GUI checklist?
The first boot is where you decide whether the lab will be stable or annoying, because hostname, IP, DNS, NTP, and certificates all affect what happens next. According to Cisco’s support guidance for NTP in ISE (2026), each node should have correct system time and NTP settings, and that advice matters even more in virtual labs where host clock drift and suspended VMs are common. If time is wrong, certificates look invalid, joins fail, and troubleshooting becomes noise.
Use a boring, predictable build sheet:
- Hostname:
ise01.lab.local - Management IP, mask, and gateway on a clean management segment
- DNS that resolves both the ISE FQDN and any AD or repository hosts
- NTP that every lab node can actually reach
- One combined persona for PAN, MnT, and PSN if your server is modest
After the GUI comes up, check these items before touching policy:
- Licensing page to confirm evaluation mode is active.
- Node status to verify all services are healthy.
- System certificates so you understand which warnings are lab-only and which ones are real.
- Repositories and patch path if you plan to update later.
- Time and DNS resolution from both CLI and GUI views.
If you want a broader exam timeline around ISE-heavy study, our CCNP to CCIE Security study plan helps sequence the workload.
How do you connect a switch and test 802.1X with Cisco ISE?
The fastest meaningful validation is one access switch, one endpoint, one simple policy set, and a working RADIUS exchange visible in ISE Live Logs. Do not start with guest portals, posture, or distributed personas. Start with one success path. A test switch guide from Network Journey (2026) uses the same pattern, and it lines up with what CCIE candidates need: verify RADIUS reachability, validate 802.1X, keep MAB as fallback, and inspect both switch-side sessions and ISE-side logs.
A simple Catalyst switch example looks like this:
aaa new-model
radius server ISE1
address ipv4 192.168.10.10 auth-port 1812 acct-port 1813
key MySharedSecret
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting update periodic 5
aaa accounting dot1x default start-stop group radius
dot1x system-auth-control
interface GigabitEthernet1/0/1
switchport mode access
authentication port-control auto
mab
dot1x pae authenticator
spanning-tree portfast
ip radius source-interface Vlan10
Then validate with:
show authentication sessions interface Gi1/0/1
show aaa servers
debug radius authentication
In ISE, add the switch under Administration > Network Resources > Network Devices, match the shared secret exactly, build a small policy set, and watch Operations > RADIUS > Live Logs. Once this works, you can extend the lab into TrustSec segmentation or compare access-control design choices against topics like FlexVPN vs DMVPN.
What breaks most Cisco ISE labs on EVE-NG, and how do you fix it?
Most ISE lab failures are not deep security bugs. They are hygiene failures, especially time drift, DNS mistakes, storage shortcuts, shared-secret mismatches, and unrealistic expectations about what one small host can run. According to Cisco’s installation guide (2026), under-reserved CPU and memory can significantly affect ISE stability. According to EVE-NG’s official ISE guide (2026), storage growth is substantial. Those two facts explain most “ISE is broken” complaints.
Use this checklist when something fails:
| Symptom | Most likely cause | Fastest fix |
|---|---|---|
| GUI loads slowly or services flap | Under-sized CPU/RAM or slow storage | Reduce topology size, move to SSD/NVMe, increase vCPU |
| Certificates look invalid | Wrong clock or broken NTP | Fix host time first, then node NTP |
| Switch cannot authenticate | Wrong shared secret or wrong source interface | Recheck RADIUS config and Live Logs |
| AD join fails | Broken DNS or time skew | Verify forward and reverse resolution, confirm NTP |
| Lab corrupts after rollback | VM snapshots used on ISE | Rebuild from a clean gold image instead |
My favorite practical rule is this: if DNS and NTP are not clean, do not trust any higher-layer symptom yet.
What should CCIE Security candidates practice, and what can they skip?
For CCIE Security prep, the highest-value ISE lab is the one that teaches authentication flow, policy logic, and troubleshooting discipline, not the one with the most personas. The exam value is in understanding how supplicant, switch, RADIUS, policy set, authorization result, profiling signal, and logs fit together under pressure. That is why a small but reliable ISE lab gives more return than a bloated build that barely boots.
Prioritize these first:
- Single-node install and recovery workflow
- Network device registration and RADIUS reachability
- 802.1X plus MAB policy testing
- Authorization profiles, VLAN assignment, and dACL basics
- TrustSec and SGT flow after basic auth is stable
- Failure analysis from Live Logs and switch CLI
You can skip or delay these until the core is solid:
- Full distributed personas on weak hardware
- Fancy guest portals before base access works
- Large AD integrations if local users already prove the flow
- Massive endpoint simulations that hide simple mistakes
If your longer-term goal is the full certification path, keep this lab alongside your CCIE Security pillar work and your firewall labs. ISE is not the whole blueprint, but it is one of the easiest places to lose time if you never build it yourself.
Frequently Asked Questions
How much RAM does a Cisco ISE lab on EVE-NG need?
Cisco’s evaluation baseline is 16 GB RAM, but most CCIE Security candidates should treat that as the floor, not the comfort level. If your host allows it, 8 vCPU and at least 16 GB assigned to the node gives a much smoother first experience than the official minimum.
Can I run Cisco ISE in EVE-NG instead of CML?
Yes. EVE-NG is usually the easier platform for ISE because it supports the qcow2 appliance workflow cleanly and mixes well with security appliances like FMC and FTD. CML is still excellent for supported Cisco routing and switching nodes.
Do I need a production license for an ISE study lab?
No. According to Cisco’s ISE Licensing Guide (2026), a fresh install includes a 90-day evaluation license for 100 endpoints with all features enabled, which is enough for most exam-focused labs.
What is the first thing to test after installing ISE?
Test one switch, one endpoint, and one policy set using 802.1X and MAB. If RADIUS reachability, authentication success, and Live Logs all work, your lab foundation is healthy.
What breaks Cisco ISE labs most often?
Clock drift, DNS mistakes, unsupported snapshots, and mismatched shared secrets cause most failures. In practice, infrastructure hygiene is the real prerequisite for ISE learning.
Ready to fast-track your CCIE journey? Contact us on Telegram @firstpasslab for a free assessment.