Tuesday, August 18, 2026

From Empty Canvas to 10,000 Simulated Devices in Minutes

 
A network simulation worth testing against is more than just fifty devices in 
a row.  It should reflect your production network, usually consisting of a core, a
distribution layer, an access layer and the end  systems hanging off it -- each device
with the right interface count, each link connected to something real, and not one 
duplicated IP address anywhere in it. Built by hand that is days of data entry, and 
by the time the topology is right the thing you wanted to test has moved on.

If you have used the Topology Wizard in MIMIC Simulator, you already have most 
of this solved. Configuration->Auto builds a large topology from a description, 
Configuration->Manual connects ports one at a time, and Replicate stamps out
copies. The MIMIC Topology Designer is its successor, and the difference is what 
happens after generation.
 
The Wizard is a sequence of dialogs: you answer them, it produces a topology, and
to change anything you go back through the dialogs or edit connections one port at
a time. The Designer puts the whole topology on an interactive canvas.  Generation
is one thing you can do there, not the only thing.
 

 
 

Two ways to build: generate it, or draw it

Most large topologies start generated and end up edited, so the Topology Designer 
does both on the same canvas.
 
GENERATE. Describe the shape you want -- how many devices, how many levels, 
which device types at each level, and the address space to draw from -- and the 
Auto Topology Wizard builds it: agents created, interfaces wired, addresses 
assigned, laid out and ready to inspect. The device types come from the Device 
Library, so every generated agent arrives with the right simulation, scenario and 
interface set already on it.

DRAW. The canvas is where the rest of the work happens -- adjusting what was 
generated, or building what the generator has no shape for. Drag a device in to 
place it. Select one device and click another to link them. Change any agent's 
addressing, simulation or management interface afterwards and every connection
that depends on it follows.
 

Additionally, interactive connection of imported topologies allows Lego-style 
build-up of your simulated network.

Sanity-checking what you asked for

Three of the wizard's inputs are not independent of each other: the total device 
count, the number of levels, and the port density of the device types you assigned 
to each level. Together they decide whether the network you described can exist 
at all -- a shallow tree of four-port devices cannot hold ten thousand nodes no 
matter how firmly you type the number.

If the shape you specified cannot hold the count you asked for, generation does 
not start. You get the exact maximum that shape will hold, and four ways to 
change the answer: fewer devices, another level, higher-port devices at the inner 
levels, or more end systems. Adding a higher-port device type to a level is usually 
the cheapest fix, because the generator picks the best fan-out available at each 
level.

Dealing with scalability

Generating ten thousand agents is one problem; visualizing them afterwards is 
the one that makes large test networks unusable.

Submaps collapse a set of agents -- or an agent and its whole subtree -- to a single
icon. Past roughly a hundred agents they stop being a convenience and start 
being the reason the canvas is still readable. The Submap Manager handles 
nesting, dissolving and editing.
 

 

Search finds any device in a ten-thousand-agent topology in seconds. Duplicate-IP
protection refuses a collision as you make it, rather than reporting it to you later.

Seven layouts arrange the canvas for you: grid, hierarchical top-down or left-to-
right, circular, star -- which suits generated topologies -- and force-directed or 
spring when you want to see how the graph really connects.

Replicate Topology is still the fastest route to scale: get one branch office exactly
right, then stamp out twenty with fresh IP subnets per copy.

Past a point, drawing the canvas stops being useful, and there the Designer offers
to generate straight to a configuration file instead. The limit on what you can 
build is not the limit on what your screen can show you.

From configuration to a running network

What the Designer saves is a standard MIMIC lab configuration -- the same .cfg 
the rest of MIMIC already consumes. The topology you just designed loads and
starts exactly like any other MIMIC configuration, in the same workflow you use 
today.

Load it, start the agents, and the network is live: every device answering SNMP 
on its own IP address, with the interface tables, the system descriptions, and the 
connectivity you laid out on the canvas. Point your management application at it 
and it discovers a ten-thousand-device network that does not exist.
 

 

That is the whole point of the exercise. The topology is not the deliverable -- the 
test bed is. What you can now do to your NMS, on demand and without a lab full 
of hardware:


  - run discovery against ten thousand devices and find out how long it
    actually takes, and what it does to your database;
  - see whether the topology map your product draws matches the topology you
    designed -- you have the ground truth, which you never do with real
    equipment;
  - break links, take devices down, change interface state, and watch how the
    application reacts;



The network you could not justify building

Every test network is a compromise between the one you need and the one you 
can afford to build. Fifty devices because that is what the lab holds. One vendor 
because that is what you have. A flat topology because wiring a realistic one by 
hand was going to take a week you did not have.

Those compromises are what the MIMIC Topology Designer removes. The network 
is described rather than assembled, so its size is a number you type; it is a file, 
so it costs nothing to keep, version, hand to a colleague, or rebuild identically in 
six months; and it is simulated, so the ten-thousandth device is as cheap as the 
first.

The question stops being "what can we build?" and becomes "what should we test
against?" -- which is the question you wanted to be asking.

If you have a test network you have been putting off building, tell us what it looks like.