Peering and Transit Cost Management Software Problems: The 7 That Waste the Saving, and How to Avoid Them

Why does a peering analysis build turn into a full network observability platform?

The question that starts the project is commercial and narrow. What would that session actually save, under our contract, this year. It is answerable, and answering it is worth real money.

Then scope arrives from every direction, because flow data is interesting to everybody. Security wants anomaly detection. The network operations centre wants alerting. Capacity planning wants forecasts. Someone wants per customer traffic reports for the sales team. Six weeks in, a costing tool has become a general purpose observability platform, competing directly with products that have been developed for years and are genuinely good at that job.

This matters more here than in most categories because the two things need different data fidelity. Observability tolerates approximation and rewards breadth. A commercial model has to reproduce your invoice to the byte, and if it cannot, nobody in finance will act on it. Chasing breadth first means you get neither.

The discipline that works is a single acceptance test before anything else is built: reproduce last month's billed number for one supplier port from your own flow data, within a stated tolerance. Nothing else ships until that passes. In Digital Heroes delivery experience the first release that clears that bar and adds prefix level attribution and candidate modelling runs $60,000 to $130,000 in 10 to 14 weeks. The full platform, with commit optimisation across suppliers, exchange port sizing, cache modelling and payback tracking, runs $150,000 to $350,000 over 6 to 10 months. Buy Kentik, Nokia Deepfield or Flowmon for the observability half. Build only the part that touches your contracts.

What goes wrong with flow data and routing table history?

The data problem in peering analysis is not volume, it is truthfulness, and it hides well because every number that comes out looks plausible.

Three specific traps. The first is sampling. On high speed interfaces sFlow sampling rates mean small flows are statistically unreliable, so a candidate whose projected saving is small relative to its port cost may be entirely noise. A build that presents a sampled figure as exact is worse than one that presents nothing, because it produces confident wrong decisions.

The second is destination resolution. Resolving a flow to a destination autonomous system number using a public mapping disagrees with reality precisely where your policy is doing something interesting, which is exactly where the money is. Localpref, communities on customer routes, selective announcements at one fabric and backup paths that only activate under failure all live in your routing information base and in none of the public datasets.

The third is time. Attribution has to resolve each flow record against the routing table as it was at that timestamp, not as it is now. A table that changed midway through the billing month makes last month's numbers unreproducible if you only ever kept the current view.

The fixes are all decided before the first line of code. Ingest the routing table properly, via Border Monitoring Protocol (BMP) from the border routers where the platform supports it, and keep the historical view. Carry sampling rates through every calculation and render confidence bounds rather than hiding them. Decide retention deliberately: full prefix level detail for the last quarter, aggregates beyond that, because most decisions live in recent months and a year of full detail carries a storage bill that surprises people.

Why do the flow export, BMP and invoice feed integrations break after launch?

This category has an unusual failure pattern. The integrations do not break loudly, they degrade, and the model keeps producing answers from partial data.

A border router is upgraded and its flow export configuration is not carried across, so one port silently stops reporting. The percentile reconstruction for that supplier now understates, and it understates in the direction that makes everything look fine. A BMP session drops after a maintenance window and nobody re-establishes it, so route resolution quietly falls back to the last table it saw. Sampling rate is changed on one interface during a capacity upgrade and the pipeline keeps applying the old multiplier, which scales that port's traffic wrongly by a constant factor that nobody spots because the shape looks right.

The invoice side breaks differently. Contract terms change at renewal, a new commit level or a revised overage rate takes effect, and if those terms live as numbers typed into a configuration screen once, the model is confidently pricing against an agreement that expired.

The fixes are specific. Every flow source reports its own liveness, and a port that stops exporting raises an alarm rather than simply contributing nothing. Sampling rate is read from the device rather than configured by hand. BMP session state is monitored like any other session. Contract terms carry effective date ranges, exactly like the agreements they represent, so a calculation run against March uses March's terms. And the reproduce-the-invoice test that gated the first release runs every month as a regression check, because that single test catches almost every silent degradation before it reaches a decision.

What happens when contract terms and commit position are not modelled?

This is the gap that turns a technically excellent build into a report nobody acts on.

Traffic engineering only changes your bill in specific commercial circumstances. If you are comfortably below a committed level you never approach, shifting traffic off transit saves you nothing at all until the contract renegotiates, and a model that reports a saving in that situation is simply wrong. If you carry tiered pricing, the marginal rate at your current volume is not the headline rate. If you buy from several suppliers under different terms, the same shifted traffic is worth different amounts depending on which port it leaves.

Term remaining matters too. A saving that only materialises after renewal has a different value to your finance director than one that lands next month, and presenting both as one number invites a fair objection you will not be able to answer in the meeting.

The other commonly missed obligation is inbound. Half the peering questions that matter concern traffic you do not control directly and can only influence through what you announce and how. A model that only reasons about outbound will confidently recommend sessions that do nothing for your largest cost driver.

The fix is to make the contract a first class object in the model rather than a spreadsheet somebody consults. Commit floors, overage rates, tiers, regional terms, term end dates and any minimum revenue commitments all become parameters, so every candidate is evaluated as marginal cost change under the agreement that will actually be in force. Then a candidate's output is a payback period rather than a volume, and payback is a number a chief financial officer can act on.

Should you build custom or configure what you already own?

For a large number of networks the honest answer is buy, and we say so regularly.

If you take transit from one supplier on a flat commit you never exceed, there is no commercial optimisation problem to solve. Nothing you do to your traffic changes the invoice until the contract renegotiates. Buy Kentik, use it well for engineering and capacity work, and revisit the build question when you add a second supplier or start approaching the commit. Building in that situation is a hobby with a project code.

If what you actually need is to see traffic by autonomous system, spot anomalies quickly and answer engineering questions, Kentik does that genuinely well and you should not write it yourself. Nokia Deepfield is the right choice at carrier scale for subscriber and distributed denial of service work. Flowmon is a sensible pick where security is the primary driver. None of these is a weak product and none of them fails at its own job.

Configuration runs out at one boundary and it is a clean one. These products model traffic. Your problem is a commercial optimisation over traffic, under contracts they cannot see and should not be expected to model. The moment the contract arithmetic is the hard part, the contract arithmetic has to live in software you control, because your commercial terms are not going into a vendor's product.

So the usual shape is both. Keep the visibility product for engineering. Build the thin, contract aware layer that reads the same flow data and answers the money question. That is a smaller and much safer project than replacing anything.

How do hidden costs get into the quote?

Three things drive cost in this category and only one of them is normally quoted.

Flow volume is an architecture decision rather than a configuration. Ingesting a few thousand records per second and a few hundred thousand are different systems, and a proposal that does not state the assumed rate has not been sized. Ask for the number the quote assumes and what happens when you exceed it.

Router estate is the second. Flow export and BMP behave differently across vendors and across software versions, and older platforms are usually the harder ones. A quote written against a homogeneous modern estate will not survive contact with the two legacy boxes still carrying real traffic. Name every vendor and version before you take a price.

Retention is the third, and it is the one that turns into a monthly bill rather than a project line. Holding a year of prefix level detail rather than aggregates is a storage design problem with a real cost attached, and it should be a deliberate decision made with a number in front of you.

Then the unquoted items. Legal or commercial review time to extract your contract terms into something modelable, which is your team's work and usually takes longer than anyone expects because the agreements live with different people. Ongoing running cost for ingestion and storage. And the fact that the reproduce-the-invoice test may fail first time for a reason that turns out to be a misconfigured export rather than a bug, which is time well spent but is time.

What separates a build that works from one that fails here?

Ask a candidate developer to explain percentile billing before anything else. If the answer involves monthly averages or total bytes, the conversation is over. The right answer mentions five minute samples, ranking, and the observation that a small number of intervals sets the bill. Someone who says that unprompted has done the work.

Then ask how they would resolve a flow record to a destination autonomous system. A public dataset is the weak answer. Your own routing table at the timestamp of the record, ingested via BMP where supported, with any fallback clearly labelled approximate, is the strong one.

Ask what they will do about sampling. Anyone who has run flow analytics at scale raises sampling rates and confidence bounds without being prompted and refuses to present a sampled number as exact. That instinct separates practitioners from readers.

The builds that succeed start with the invoice reproduction test and refuse to move past it. The builds that fail start with a dashboard, look impressive in month two, and never get used for a decision because nobody trusts the numbers against the bill.

Finally, insist that the model's output at decision time is stored as a commitment, and that actual percentile movement after turn up is measured against it. That single habit calibrates the model against your own network within a few cycles, and it is the only way you will ever know whether the last session was worth the port. Settle ownership of the repository and the infrastructure accounts before kickoff, because this system holds your commercial terms and you should never need a vendor's cooperation to read them.