INET is the protocol library that turns OMNeT++ into a network simulator

A model library, not a simulator

The INET framework is an open source communication networks simulation package, written for the OMNEST and OMNeT++ simulation system. The homepage is inet.omnetpp.org and the primary language is C++.

The distinction between the framework and the simulator matters for anyone new to this area. OMNeT++ is the discrete event simulator: it provides the event loop, the kernel, the NED topology language and the runtime. INET is the model library that sits on top of it, supplying the things you would otherwise have to write: models for numerous wired and wireless protocols, a detailed physical layer model, application models and more.

So INET is a large set of reusable components rather than an application. A researcher building a study of congestion control behaviour, a student learning how a routing protocol interacts with a wireless channel, or a vendor checking a protocol implementation against a scenario would all use it the same way, by composing modules into a topology.

The readme also notes that the CREDITS file carries the names of the people who have contributed, which for a project of this size is a substantial list and a fair signal of the effort involved.

The warning the project puts above everything else

There is a block of text in capital letters near the top of the readme, and it is the most important paragraph in the repository.

It says the INET Framework is continuously being improved: new parts are added, bugs are corrected, and so on. It says they cannot assert that any protocol implemented here will work fully according to the specifications. And then it says in capitals that you are responsible yourself for making sure that the models you use in your simulations work correctly, and you are getting valid results.

That is a stronger warning than a typical disclaimer, and it is the one to internalise before you quote a number from a simulation. A discrete event simulation of a protocol is a model of that protocol, written by people, containing approximations, and the framework moves under you continuously. A result is evidence about the model unless you have checked the model.

The practical reading is that INET results need the same scrutiny as any other implementation you did not write, and the project is unusually direct about saying so rather than letting a simulation output look more authoritative than it is.

The path from clone to running simulation, in seven steps

The getting started section is a sequence, and it is worth following in order because each step depends on the previous one.

You start by downloading and installing the INET framework, reading the INSTALL file for further information. Then you gather initial experience by starting some examples, or by following a tutorial or a demo in the examples, showcases and tutorials folders. After that you learn the NED language from the OMNeT++ manual and sample simulations.

Then you may write your own topologies using the NED language, assigning some submodule parameters in NED files and leaving others unassigned. Then you assign the remaining unassigned module parameters in omnetpp.ini of your simulation, referring to the sample simulations and the manual for the content of that file. And finally you run your simulation.

The step that is most often skipped is the third one. Learning NED before writing a topology is what makes the later steps make sense, because a NED file is a module description with parameters, gates and connections, and a parameter left unassigned is a parameter you set in omnetpp.ini.

And the last observation of the section is the payoff for people who do not want to write C++: you may use the INET framework without writing any C++ code at all, as long as you use the available modules.

When you do need to write C++, and how the build notices

The moment you leave the pure NED world, the repository structure changes the shape of your work.

To implement new protocols or modify existing ones, you add your code somewhere under the src directory. If you add new files under the src/inet directory you need to regenerate the makefiles, using the make makefiles command. If you want to use external interfaces in INET, you enable the Emulation feature, either in the IDE or using the inet_featuretool, and then regenerate the INET makefile with the same command.

So the build is generated rather than written, and the generator is the OMNeT++ IDE toolchain. The Makefile at the root shows how that works:

makefiles:
	@$(info *** CREATING Makefile with:)
	@$(info opp_makemake $(MAKEMAKE_OPTIONS))
	@cd src && opp_makemake $(MAKEMAKE_OPTIONS)

The options come out of a file called .oppbuildspec, and the Makefile extracts them with sed, adding the include path and the deep option in the right places so that the generated makefile matches what the IDE would produce. That is the important detail: the generated makefile and the IDE's are the same makefile, so a developer can switch between the two without a surprise.

Features work the same way. The enabled feature set is turned into a header of WITH_FEATURE macros:

$(FEATURES_H): $(wildcard .oppfeaturestate) .oppfeatures
	@$(FEATURETOOL) defines >$(FEATURES_H).tmp
	@mv $(FEATURES_H).tmp $(FEATURES_H)

The feature state lives in a file called .oppfeaturestate, the declarations in .oppfeatures, and the tool that turns them into defines is the inet_featuretool. The default build target depends on the makefiles and on that generated header, so a fresh checkout configures itself before compiling.

What the example simulations cover

The examples directory is the best catalogue of what INET actually models, because each folder is a working scenario rather than a feature list.

The visible set includes adhoc, aodv, bgpv4, clock, communicationcache, dhcp, diffserv, eigrp, empty, emulation, ethernet, geometry, gptp, ieee8021as, ieee8021d, inet, internetcloud, ipv6, manetrouting, mobility, mpls, mrp, neighborcache and objectcache.

Read that as a list of protocols and layers. Routing is covered by aodv, bgpv4, eigrp and manetrouting, with mrp for multicast. The link layer has ethernet, and the wireless side has gptp for time synchronisation and the two IEEE 802.1 layers for bridging and link aggregation. QoS appears as diffserv, and the internetcloud example is the classic routed network with an interior and an exterior router. There are also building-block examples for the mechanisms a protocol relies on: neighborcache, objectcache and communicationcache for the state a routing protocol keeps.

The empty and clock examples are the ones to look at first when learning the framework, because they are the smallest complete simulations and the difference between them is the whole point: a topology with no traffic versus one that generates it.

The test suite is organised by what it validates

The badge row at the top of the readme is a good guide to how the project proves itself, because the CI is split into a set of named test categories rather than a single suite.

There are chart tests, feature tests, fingerprint tests, module tests, packet tests, protocol tests, queueing tests, statistical tests, unit tests and validation tests, each with its own workflow. There are also build workflows for Linux, Mac OS and Windows.

The names describe what is being checked rather than where the code lives. Fingerprint tests are about the model's observable behaviour, since a change to a protocol's timing or its defaults changes its output in a way a unit test would not catch. Packet tests are about the wire format. Statistical tests are about distributions, which matters for a simulator where a queueing model has to produce the right delay distribution and not just the right mean. Validation tests are about the models agreeing with something outside the simulation.

The speed test workflow is present but commented out, which is a small and honest detail: a test that is too slow to run on every push is not run on every push.

Where the changes live, and how current the branch is

The repository tells you where to look for what is changing.

The WHATSNEW file records recent changes, and the doc/whatsnew folder holds the changes of the version in development. So there is a distinction between what has shipped and what is in flight, and a user who cares about a specific model can read that folder before deciding which version to pin.

The releases are v4.7.0 from 2026-07-07, v4.6.0 from 2026-02-20 and v3.8.5 from 2024-11-05. The jump from the 3.8 line to 4.x is a major version change, and the gap between the 3.8.5 release and the 4.6.0 release is where the framework changed substantially.

The last push was on 2026-10-20, so the branch is current with the releases, and the project is not archived. The homepage is inet.omnetpp.org and the repository carries an AGENTS.md, a .agent directory, a doxygen configuration and a .readthedocs.yaml, so the documentation is built in several places: the doxygen target for the API, the neddoc target for the NED reference, and a self-documenting fingerprint tool that turns model definitions into XML.

Editorial conclusion

Adopt INET if you are already using OMNeT++ and need realistic protocol models rather than hand written queueing abstractions, because the value is in the models and the NED topologies that come with them. Do not treat simulator output as a measurement of a real system, since the project explicitly refuses to assert that any protocol implemented there works fully according to the specifications. Before you rely on a result, check three things: which INET version matches your OMNeT++ install, since the releases track the simulator, whether the model you need is in the version you are pinning, and that you have read the WHATSNEW file for the changes between versions, because the framework is continuously being changed.

Frequently asked questions

Official sources

1. inet-framework/inet on GitHub
2. Issues
3. Project website
4. README
5. Releases