FastNetMon is a flow sensor that reacts by blackholing, and that is the design

Detection ends in an action, not an alert

The what-do-we-do paragraph is two sentences and both matter. It detects hosts in the deployed network that are sending or receiving large volumes of traffic, measured in packets, bytes or flows per second, and then performs a configurable action to handle that event. The configurable actions are listed as three: notifying you, calling a script, or making a border gateway announcements. That third option is the difference between this being a monitoring tool and this being a mitigation tool, and it is why the readme carries integration instructions for specific router vendors further down. A detector that can withdraw a route for an offending address is closer to an automatic firewall than to a dashboard.

Eight capture backends, two of them deprecated with conditions

The backend list is the most technical part of the readme and it is worth reading closely. It starts with three flow protocols: three versions of one flow export format, the internet protocol flow information export, and its own version five. Then packet capture from a file, and three live kernel interfaces, one of which is marked recommended and one of which is the newest, an eBPF-based one. Then two entries that have been deprecated rather than removed, each with the condition attached: a userspace capture interface supported only on one operating system, and a commercial ring-buffer product available only on a distribution release that is long out of support and only in a particular version of this project. So the list encodes not just what works but what the maintainers will accept bug reports about.

Thresholds can be per subnet, and attacks become routes

Two features determine whether the tool is usable in a real network rather than a lab. The first is that thresholds can be configured on a per-subnet basis through a host-group mechanism, which is the difference between a detector that fires on your biggest customer and one that fires on an anomaly. The second is route announcement, and the readme names the two supported implementations, marking one of them recommended. Both are open source routing daemons rather than features of a commercial switch, which means the announcement path is something you run rather than something you license. That is the integration point with the previous section: the sensor's output is a prefix, and the protocol that carries it is the thing to get right. Announcing a blocked address is only as fast as the routing protocol that carries the announcement, which is why the two supported implementations are named explicitly rather than left as an integration detail.

Where the data goes: metrics, flows, fingerprints, databases

The feature list covers output as well as detection, and it is long. Notifications by email about a detected attack. Metrics exposed in the Prometheus text format, covering both system metrics and total traffic counters. Flow and packet export to a message broker in two serialisations. An API. Integration with a document store, a time-series database and a graph database, all three named with links. Then two capture-side features that are easy to miss: VLAN untagging in mirror and flow modes, which matters if your mirror port carries tagged traffic, and the ability to capture attack fingerprints as packet files, which is what turns a detection into something you can hand to someone else. So the design assumes the detection is the start of an investigation rather than the end of it, and the fingerprint output is the hand-off point between the sensor and whoever reads the packet afterwards.

Three router plugins live in the source tree

There is a short section on router integration with separate instructions for one vendor's routing software, and then a claim of complete integration with three vendors, each linked to a plugin directory inside the source rather than to documentation. So unlike the route announcement feature, which is a protocol choice, the device integration is code, and the code is in the tree. That matters for anyone planning to run this: the plugin set is three vendors, and a fourth family of device is handled through the protocol route rather than through a plugin. The readme also separates the two by phrasing, calling one an integration and the other complete, which is a distinction worth preserving when you evaluate a device you already own.

The edition boundary is stated in the readme

Four of the links near the top exist to draw a line. There is an official site, a commercial edition, a free trial of that edition, and a table comparing the advanced and community editions. The legal section then states that installing or using the software constitutes agreeing to the community edition terms and a privacy notice, and that the project is a product of a company registered in the United Kingdom with a registered trademark. So the community edition is not a community fork that happens to be free; it is the free tier of a commercial product, which explains both the feature list stopping where it does and the presence of a privacy notice alongside the terms. It also means the terms are a dependency of the installation, not an optional read. The comparison table being hosted rather than reproduced is the other half of that arrangement: the boundary between the two editions is defined by the vendor and can move, which is worth remembering before building a monitoring workflow around a feature that might move across it.

Seven support channels and a usage-analytics disclosure

The support section lists a mailing list, a chat platform, an IRC channel over TLS with a web client, a messenger app, and a second chat platform, which is a lot of channels for one project and suggests an international user base with different preferences for where to ask questions. Above them there is a sentence that deserves more attention than it gets: the project tracks platform and environment specific metrics to understand how the product is being used and to prioritise development accordingly. That is a usage-analytics disclosure in the middle of a feature list, and it is the one line in the readme that tells you the free edition phones home. Whether that matters to you depends on your environment and your threat model, and the disclosure at least lets you decide.

Editorial conclusion

FastNetMon Community suits a network operator who already has an upstream provider and wants detection plus a response they control, and who can accept the terms of a community edition maintained by a company selling a commercial one. It does not suit someone looking for an application-layer defence. Before deploying, read the edition terms the installation itself is gated on, pick a capture backend from the list rather than the default, and confirm your router speaks one of the two supported route announcement protocols.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. pavel-odintsov/fastnetmon on GitHub
4. README
5. Releases