Dynamips and Cisco IOL image compatibility results
Whenever someone asks "does netplex support <old Cisco platform>", the honest answer used to be "probably, but we haven't checked that exact image." That's not good enough for a lab tool people plan CCNA/CCNP practice around, so we sat down with everything in our Dynamips and Cisco IOL image library, imported each one, wired it into a real topology, and pinged across the link. No shortcuts, no "it's basically the same binary so it'll be fine."
How we decided "working"
An image only counts as working if it booted, reached its own CLI, joined a netplex. lab over a real link, and a ping actually got a reply. A process staying alive isn't enough - plenty of broken configs still show a green light. When something looked off, we dug further: checking the interface's own packet counters, pinging the device from itself, whatever it took to find out whether the fault was in netplex.'s fabric or baked into the image. One working c2600 doesn't tell you anything about whether a different c2600 build works, so every image on this list got its own pass, not a free ride from its neighbours.
The numbers
40 images went through the campaign. 33 came back working. The other 7 are all C7200 - and that one's not on us: Dynamips itself never wrote support for the NPE-G1/NPE-G2 hardware those images expect, so there's no code path anywhere, on any platform, that can run them. Two more registry entries turned out to be empty metadata stubs with no actual image file attached, so there was nothing to even attempt.
Dynamips: a clean sweep
Every single Dynamips platform we had came up fine - CLI, routing, ping, all of it - across every image variant we had for that platform. That's c1700, c1710, c2600 (five separate builds), c2691, c3640, c3660 (five builds), c3725 (four builds), and c3745 (three builds) - 23 images, 8 platforms, zero exceptions. The exact filename and IOS train for each one is in the Knowledge Base list if you want to check your own image against it.
Cisco IOL: two clean wins and one real gap
IOL split three ways. Three images ran as full routers with nothing to report: i86bi_linux-adventerprisek9-ms, i86bi_Linux-L3-AdvEnterpriseK9, and L3-ADVENTERPRISEK9-M. Two more - both builds of generic:L2-ADVENTERPRISEK9-M (15.2 and 15.2-IRON) - turned out to be full Layer 2 switches too, not just routers; we set up a plain interface Vlan1 and pinged straight across the switched segment to be sure.
Then there's the interesting one. Five images in the i86bi-linux-l2 family boot fine and route fine, but a standard switchport-to-SVI setup never passes a single packet. Before we wrote that down as a limitation we wanted to actually know why, not just shrug. The physical port's packet counters showed frames arriving in real time. Pinging the box from itself worked, so the IP stack was healthy. What wasn't happening was the hop from the switchport into interface Vlan1 - the frames just never crossed that internal bridge. We traced netplex.'s own OVS wiring and TAP interfaces the whole way through and they were doing exactly what they should. The gap is inside this specific IOS build, in how it bridges its own Layer 2 to its own Layer 3 - not something we can patch from our side.
The fix, if you hit this, is simple: skip the switchport entirely and configure the interface as routed instead - no switchport plus a direct ip address. Do that and all five images ping cleanly and work as routers with no other changes.
So, what should you actually use?
Need real Cisco switching? Reach for the generic:L2-ADVENTERPRISEK9-M builds, or any Dynamips platform - both do it properly. Already running an i86bi-linux-l2 image and only need routing? You're fine as-is with the workaround above. Every exact filename and version, plus what's explicitly not supported and why, is on the reference page - worth a search before you spend an evening chasing a switchport that was never going to forward.