NacTrack
FRGet the demo
Why

Built by field engineers, and corrected by the ones who use it

NacTrack was not designed in a meeting room and then sold to network teams. It came out of what engineers were already doing by hand, on real estates, at operators, industrial sites and public administrations. It carries on being written the same way.

Supported vendors
Where the product comes from

Three sources, and none of them is a meeting room

The team

Software architecture and cybersecurity on one side, network engineering on the other: operator cores, MPLS, campus, datacentre, access, on hardware from every vendor. Decades in the field, not in a lab. That is what decides what the product reads, what it refuses to assert, and what it never lets out of your building.

The engineers who run it

The product runs every day in the hands of engineers working on client estates. They are the ones who find the unexpected command output, the platform that names things differently, the case no specification anticipated. Every one of those cases comes back into the product.

Customers, through support

Our customers, across very different industries, open a ticket to ask for a platform to be parsed, or to propose an improvement. Those requests are not a queue: they are the roadmap. A vendor enters the product because somebody has it in production and sent us what their devices actually answer.

The cycle

Continuous improvement, as it actually turns here

Six stages, and the last one produces the first. That is what makes it a cycle rather than a list.

A six stage continuous improvement cycle: field, request, design, code and security, release, productionSix stages arranged in a ring, joined by arrows in reading order. The field produces an unforeseen case. The case becomes a request, carrying the device's real output. The design decides what will be read and what will not be asserted. The code is written and tested against that real output, with security checks on every build. The release ships a version on the channel the customer chose. Production puts the product back on real estates, where the next case appears, which returns to the field. At the centre: continuous improvement, every lap starting from a real device.Continuous improvementevery lap starts from a realdevice1In the fielda case no specificationanticipated2The requesta ticket, with what the deviceactually answers3The designwhat will be read, and whatwill not be asserted4Code and securitytested on real output,security on every build5The releasea version, on the channel youchose6In productionthe estate runs, and the nextcase appears

Continuous improvement every lap starts from a real device

  1. In the fielda case no specification anticipated.
  2. The requesta ticket, with what the device actually answers.
  3. The designwhat will be read, and what will not be asserted.
  4. Code and securitytested on real output, security on every build.
  5. The releasea version, on the channel you chose.
  6. In productionthe estate runs, and the next case appears.

The cycle does not start with a product idea, it starts with a device that answered something unexpected. It is also why a platform enters the matrix when a real device has answered, and not before.

This is concentrated field experience

So that what is hard becomes simple to get. The shortest way to check that is to look at the product.

Request accessSupported vendors