Should you build your own NAT log server or buy one?

For almost every operator running a MikroTik network, buying is the right answer, and the reason is not difficulty. It is that building means taking permanent ownership of a piece of software whose upkeep never ends, paid for with the hours of the one person who keeps your network running.

What are you actually being asked to build?

Far more than a thing that receives records. Receiving them is the part everyone pictures, and it is the smallest part of the job.

• Something listening for records and writing them down without falling behind at peak
• Parsing that copes with every shape of line your equipment produces, including the rare ones
• Storage that keeps growing for years and stays searchable while it does
• Search that takes all three given values at once and answers quickly across a long period
• Retention that removes old material on purpose rather than when a disk fills
• Backups, and a restore somebody has actually carried out
• Access control, so searching does not require the keys to a production router
• Output somebody outside the company will accept, and a record of who searched what
• Documentation good enough for a stranger to run it without the author in the room

None of those nine is research. That is exactly what makes this trap work. Every item looks like an afternoon, so the whole thing looks like a fortnight, and the estimate is wrong by a factor nobody discovers until they are committed.

Why does the first version always look finished?

Because the visible half is the easy half. Records arriving, appearing in a table, searchable by address, satisfies everybody in the room and can be put together quickly by anybody competent.

What is missing at that moment never appears in a demonstration. Nobody demonstrates a restore. Nobody demonstrates behaviour at three times the traffic, a search across eleven months, or a line arriving in a shape the parser has not seen.

So the project gets called done at precisely the point where the interesting work ends and the tedious work starts. The tedious work then happens in fragments, late, in response to something that has already gone wrong, which is the most expensive order to do it in.

Retention, backups and access control are always the three that miss the first release, and they are the three that somebody outside the company eventually asks about. None of them is hard. All of them are dull, and dull work loses every argument against a network fault.

There is a second reason the first version flatters itself. It is tested against the traffic of a quiet week by the person who wrote it, who knows which searches work and does not run the ones that do not. Nothing in that exercise resembles a stranger arriving with a period, a port and a deadline.

Who ends up owning it, and what does that cost the network?

The person who built it, for as long as they stay. That is the real price, and it is charged in the scarcest currency a small operator has.

Whoever is capable of building this properly is the same person who understands your routing, your addressing and your customers. Their attention is the input to everything that earns money. Hours spent maintaining a parser are hours not spent on capacity, on faults, or on the expansion you are actually trying to fund.

Then there is what happens when they leave. Software written in house by one person becomes an unowned dependency the day they hand in notice, and unowned dependencies get replaced under pressure rather than on a plan. You end up buying something anyway, at the worst possible moment, while the records keep arriving.

One question settles this faster than any comparison. Ask who will be maintaining it in three years, by name. Where a real name comes back and that person has time, building is a plan. Where you get a shrug, or somebody already carrying four other jobs, building is a hope.

Does assembling existing components avoid the problem?

Partly, and less than it appears. Established open components handle receiving, storing and searching, which removes the writing but not the owning.

What each route leaves on your desk

Route	What it removes	What stays yours
Write it from nothing	Nothing	All nine items, permanently, including the parsing nobody else understands
Assemble open components	The receiving, storing and searching	Integration, retention, reporting, access control, and every upgrade that breaks one of the parts
Buy something built for this	All of it, along with the maintenance	Choosing a supplier carefully, and keeping the records portable

The middle row is where most self built systems actually sit, and it is where the disappointment lives. The components are excellent at what they do and entirely uninterested in the rest, so the parts you still have to build are the same dull three that were going to be skipped anyway.

It suits operators who already run those components for something else and have somebody fluent in them. Where that is not already true, the learning is the cost, and it arrives again at every upgrade.

What happens to a home built system as the network grows?

It meets a different class of problem, and it meets it during an evening peak rather than during a review. An arrangement that copes comfortably with a few routers behaves differently at thirty, and volume is not the only thing that changes.

Searches that returned instantly over a month start taking minutes over a year. Storage laid out for convenience becomes storage that has to be reshaped, with the history in it. Devices get added by people who do not know the collector exists, and nobody notices the gap until somebody asks about it.

Most operators cross that line with no project to mark it, because growth does not announce itself. The system did not break. It simply stopped being the right size, and correcting that is a second build with a live network attached to it.

Is there any case at all for building?

A narrow one. Operators with a software team already on the payroll, or with a requirement so unusual that nothing existing comes close, can reasonably build and carry it, because for them the maintenance lands on people whose job it is.

That describes very few networks running MikroTik equipment. The rest have engineers whose job is the network, and handing them a software product to maintain is a decision that looks free on the day it is taken and never afterwards.

Price alone is not a reason. Building to avoid a purchase only works out cheaper where the hours are genuinely free, and the hours belonging to the person keeping your network alive are the least free hours in the business.

There is a timing point worth adding, because it decides how much choice you have. Nobody builds this calmly. It gets started after a request arrives that could not be answered, which is the moment with the least available attention and the most pressure, and a software project begun in that state tends to reach the demonstration stage and stop there.

What should you check before buying instead?

Three things, and they are worth asking directly rather than inferring from a brochure.

First, whether it fits the way your network is arranged, particularly where translation and subscriber sessions happen on different devices. Every network does something slightly unusual, and it is better to surface that before purchase than after.

Second, whether you can leave. The records belong to you, and getting them out in a form something else can read should be possible on the day you decide rather than negotiated later. An arrangement that makes leaving awkward has quietly turned a purchase into a commitment.

Third, who is behind it and what happens if they stop. Dependence on a supplier is real and worth naming, and the answers to that question are part of what you are buying rather than sales conversation around it.

Ask those three plainly. A supplier who answers them without hesitation is telling you something useful, and so is one who does not.