Network Consulting & Managed NOC

What we are asked for

Most engagements start with one of these four questions, and most of them turn out to be the same question asked from different directions.

DDoS protection architecture

The question behind it: can my topology even see the attack?

Where filtering belongs in your topology, what it has to be able to see in order to decide anything, and - the part usually missing - which attacks your current design provably cannot stop, whatever you spend on it.

A filter that only sees one direction cannot validate a handshake. A filter behind the congestion point cannot help. A per-IP threshold cannot see a carpet bomb spread over a /24. These are properties of the topology, not of the product, and no purchase fixes them.

Inline, on-demand diversion or hybrid - and the real cost of each Where to terminate: border, edge, or upstream of both Symmetric vs asymmetric routing, and what the asymmetry makes unknowable What to measure first, so the design is sized against traffic, not a guess

Routers, switches and network cards

The question behind it: what does this box actually forward?

Which platform actually sustains the forwarding rate you need, what the datasheet number excludes, and where hardware offload stops helping. We have bought the wrong card before - and spent four years on a vendor-specific API before concluding that the lock-in cost more than the performance was worth.

We are vendor-neutral by experience rather than by policy. Over seventeen years we have run commodity NICs, Solarflare, and current-generation 400G adapters; Juniper and Cisco at the border - and we have left every one of them behind at some point, for reasons we can explain.

pps versus bps sizing - what kills a box is almost never bandwidth Queue and interrupt architecture, RSS behaviour, NUMA placement Offload: what is real, what is marketing, what breaks under fragmentation TCAM and rule-count ceilings, and the day you exceed them

Border and edge network design

The question behind it: what happens on the worst day?

Full design of the border: upstream and internet-exchange strategy, route policy, convergence behaviour, and redundancy that survives the failure it was actually drawn for rather than the one in the diagram.

This is where most DDoS problems are really solved. A border with enough diversity, the right communities and a sane blackhole policy absorbs a great deal before any filter is asked to do anything. A badly designed one makes every downstream mitigation harder than it needed to be.

Transit mix, IX selection and peering strategy for your actual traffic Route policy, communities, RTBH and FlowSpec design Per-upstream marking, so attack traffic can be attributed to a path Failure analysis: what happens when the largest single link is gone

Build, commissioning and handover

The question behind it: who runs it afterwards?

Where it is wanted, we do not stop at the document. Configuration, staged commissioning, load and failure testing before traffic is moved, and the operational tooling to run it afterwards - monitoring that measures the right things, and runbooks written for the night shift rather than for the auditor.

Handover is the deliverable. The engagement is finished when your team can operate and change it without us, not when the last device is racked.

Configuration and staged migration with rollback at each step Load, failure and convergence testing before production traffic Monitoring, alerting thresholds and capacity baselines Documentation and training for the people who will run it

How an engagement runs

Short, with something usable at the end of each step. We would rather tell you in week one that the project is unnecessary than bill you for finding out in month three.

Read the network

Current topology, traffic, incident history and what has already failed. Measurements first - opinions are cheap and yours has probably already been given to you.

Name the constraints

Budget, latency, compliance, the hardware you are keeping and the decisions that are politically fixed. A design that ignores these is a design nobody builds.

Design and cost it

A document with the topology, the equipment, the reasoning and the cases it does not cover - plus the cheaper option, when there is one.

Build, hand over - or keep us

Your team builds from the document and we review, or we build and hand it over tested. There is a third ending too: we build it and keep running it, as the section below describes.

Tier 2 European backbone · European DDoS protected network Built, filtered and operated inside the EU · human NOC 24/7, no AI agents

ISO 9001ISO 27001PCI-DSSGDPRNIS2

Architecture & administration

We can also just run it for you

Design and build is half the story. The other half is the years after: software upgrades, capacity, incidents at four in the morning, the config nobody remembers making. We take that role too - network architecture and network administration, from the same engineers who run our own backbone.

The arithmetic

A real NOC is brutally expensive to own

One staffed seat around the clock is five to six engineers once shifts, holidays and turnover are honest - before training, tooling and the salary market for people who can actually run BGP. Below a certain network size that cost simply cannot be justified, and the usual compromise is one overworked administrator and a prayer. The alternative is renting the function: our NOC already runs 24/7 for our own network, and your infrastructure joins what it watches.

What the role includes

Everything an in-house network team would do

Monitoring and alerting tuned to your topology, configuration changes with review and rollback, software upgrades planned and executed, capacity watched before it becomes a ticket, incident response with a named engineer, and documentation that stays current because the people writing it are the people using it. The RIPE housekeeping - objects, RPKI, the LIR side - folds into the same role. You keep ownership and the vendor relationships; we keep it running.

Who already works this way with us

Not hypotheticals - these are standing arrangements, described without names for the obvious reason:

Hosting companies

We operate the entire network for several hosting providers: border routers, switching, peering sessions, capacity planning and the on-call that goes with it. Their teams run servers and customers; the network is simply ours to keep healthy, and their engineers stopped being woken by BGP a long time ago.

Internet service providers

For regional ISPs we hold the network administrator role end to end - upstream relationships, route policy, upgrades and incident response. An ISP trusting another operator with its own network is the strongest reference we can offer, and it happened because the consulting engagement came first and earned it.

Financial institutions

For financial-sector clients we maintain the whole network infrastructure under their compliance regime: documented changes, audit trails, DORA-shaped incident records and equipment lifecycle management - with their auditors reading our paperwork, not just theirs.

What those years actually contained

Senior system and network engineering since 2009 is not a slogan here - it is a list of things that have already gone wrong once, on our watch, and got fixed. The consulting is priced in scar tissue:

Kernel builds and recompiles - patched, tuned, shipped to production Custom network stacks and drivers, written when the stock ones ran out Databases kept alive and made fast - MySQL, PostgreSQL, replication and rescue Web servers under real load - nginx, Apache, tuning and the 3 a.m. incident Security audits and hardening, from the kernel up to the application edge DNS, mail and the unglamorous services everything else quietly depends on Virtualisation and container platforms - KVM and what came after Storage, filesystems and backups that had actually been tested by restoring

Every arrangement started smaller - a design review, one incident, one upgrade done well. If that is the pace you want, start with the small one.

What we will not take on

Four things we say no to

Reselling a conclusion you have already reached. If the equipment is chosen and the design is signed off, a consultant's role is to put a name on it. We are not useful there and will say so.

Application-layer architecture. We design networks and packet filtering. Your application's own scaling, database and caching decisions are somebody else's expertise, and pretending otherwise is how consultants do damage.

Windows estates. We design, build and operate Linux-based infrastructure - routers, filters, servers and the tooling around them - and more than twenty years of that depth is precisely what you are buying. Windows administration is a different profession, practised well by other people.

Work that ends at the document. A design nobody can operate is a cost, not an asset. If there is no team to hand it to and no appetite to build one, the honest advice is to buy the outcome as a service - from us or from anyone else - rather than to build it.

Frequently asked

Are you tied to any vendor?

Neutral by experience rather than by policy: seventeen years across commodity NICs, Solarflare, 400G adapters, Juniper and Cisco - and we have left every one of them behind at some point, for reasons we can explain in the report.

Can you just review a design without building anything?

Yes - an engagement can be one document, one incident post-mortem, or one afternoon of hard questions. Every larger arrangement we run started exactly that small.

Will you operate what you build?

If you want that - yes. We can run the network as a managed role from the same NOC that watches our own, or hand it over documented and tested with your team trained. Both endings are first-class.

Can you work under our compliance regime?

We already do - for financial-sector clients the changes are documented, the incident records are DORA-shaped, and the auditors read our paperwork alongside theirs. NDAs are standard before we see anything.

We have built this six times. Usually the hard way.