Your twelve sites each graph their own traffic — how do you produce one credible number for what the estate received?
answer
- no site holds the number
- one collector, one clock
- scale by each exporter's sampling rate
- peak per second, not bytes per hour
- your counters stop at your own ceiling
basics
~20 sAggregate flow records from every site into one collector on a common clock, scale each site's counts by its own sampling rate, count each packet once, and report a peak per-second rate rather than a byte total.
solid answer
~50 sNo site can produce the number, because no site has the data — the total has to be built. Export flow records from every site's edge to one collector, aligned to a common clock, and then handle three things that silently corrupt the sum: sampled export must be scaled by each site's own sampling rate, and rates that differ between sites skew the total in a direction nobody notices; a packet counted at both an ingress and an egress interface is double-counted; and a byte total over an hour answers the wrong question, because the capacity claim is about the peak per-second rate. Then state the limits honestly. Your records show what your interfaces received, not what upstream links dropped before you, so the true arriving volume needs your transit providers' counters — and if no threshold ever fired, the write-up says the estate absorbed an attack it did not detect.
go deeper
Know that a site's dashboard shows only that site, and that an estate-wide figure has to be assembled from every site rather than read off one graph.
Be ready to explain sampled flow export — counts represent samples and must be scaled by the exporter's sampling rate — and why an unsynchronised clock hides a burst.
Show the whole method and its limits: aligned per-second series, one counting boundary, estate and per-site peaks, upstream counters for what was dropped before you, and an explicit floor when they are unavailable.
Own the wording of the claim. 'Absorbed' and 'detected and absorbed' are different promises, and presenting the first as the second is what destroys trust in every later capacity number you bring.
## Why the number does not exist yet An executive has been told the distributed footprint absorbs attacks. After an incident someone asks the obvious question — how much did we actually take? — and discovers that twelve dashboards showing twelve local graphs do not answer it. Nothing in the design ever computed a sum, so the number has to be constructed, and constructed defensibly, because the people asking are being asked to fund capacity on the strength of it. ## Build the aggregate, then distrust it **One collector, one clock.** Every site's edge exports flow records — five-tuple, byte and packet counts, start and end timestamps — to a single collector. If site clocks drift, records land in the wrong bucket and a synchronised burst smears into a plateau, which understates the peak. Time synchronisation is not housekeeping here; it is the difference between a peak and an average. **Scale sampled export correctly.** Most edge exporters sample: one packet in a thousand, one in ten thousand. A record's byte count then represents its sample, and the site's real volume is the count multiplied by that site's rate. Two sites configured at different rates and summed without scaling produce a total that is wrong by whatever ratio the misconfiguration happens to be, in a direction nobody will spot, because the result still looks like a plausible traffic graph. Confirm the rate per exporter, not per site, and record it beside the figure. **Count each packet once.** A flood traversing a site can be observed at more than one interface. Sum across interfaces without deciding a counting boundary and you double the estate total — which is a very comfortable error to make when you want a big number, and an embarrassing one to have found for you later. **Report peak, not volume.** "We absorbed 43 TB" sounds impressive and answers nothing. Capacity is a rate problem: what matters is the highest per-second bits and packets each site had to carry, and the estate-wide peak at the same instant. Publish both the estate peak and the per-site peaks, because a comfortable estate peak can hide one site that ran at ninety percent. ## The part your own data cannot show Interface counters measure what arrived at the interface. Once an upstream link saturates, traffic is discarded before it — so your records stop measuring the attack and start measuring your own link capacity. The graph flattens at the ceiling and looks calm. The only source for what was actually sent toward you is the transit providers', so an honest total either includes their figures or states that it is a floor. The same applies to the sites' shares. A share is a share of what you received, not of what was aimed at you, and the two diverge exactly when the incident is worst. ## Saying the uncomfortable sentence If no site ever crossed a threshold, the write-up cannot claim detection. There are two different claims and they are funded differently: | Claim | What it needs as evidence | | --- | --- | | "We absorbed it" | Reconstructed flow totals, per-site peaks, no user-visible degradation | | "We detected and absorbed it" | An alert with a timestamp before anyone noticed, and a responder who acted | Only the first is available, and the second is what the audience assumed they were buying. Saying so is the whole value of the write-up, because it converts a quiet week into the argument for the aggregation work that would have produced an alert. And note the adversary's position in this. An attacker who repeats the exercise learns your estate's shape from the outside — which sources reach which site, and what volume passes without a response — and the absence of any reaction is the most useful thing you can teach them. Nothing about that appears in a byte total. ## What to hand over A defensible package is short: the estate peak rate with the time it occurred; per-site peaks and shares; the sampling rate and counting boundary used, so the arithmetic can be re-run by someone who does not trust it; the upstream providers' figures or an explicit note that yours is a floor; and a plain statement of what fired, what did not, and who found out first. Numbers presented without those qualifications are the ones that get taken apart in the room, and once one figure is shown to be double-counted the whole absorption claim goes with it.
- Why is a peak per-second rate the figure to report rather than total bytes?Because the capacity claim is about rate. Links, line cards and absorption budgets are sized in bits and packets per second, and an attack is survivable or not at its peak instant. A large byte total spread over an hour may never have stressed anything, while a short burst at ten times the peak rate is the event that mattered. Report both estate and per-site peaks with their timestamps.
- The graph flattens at the top for twenty minutes. What does that tell you?Most likely that an upstream link saturated and traffic was discarded before reaching your interface, so the counter is measuring your capacity rather than the attack. Treat a flat top as a censored measurement, not a plateau in the attack, and go to the transit provider's counters for the arriving volume. Reporting the flattened figure as the attack size understates it, sometimes by a lot.
- Someone asks why you cannot just add the twelve dashboard peaks together.Because peaks at different sites did not necessarily occur at the same second. Summing local maxima produces a number higher than any instant the estate actually experienced. The correct method is to align the per-second series on a common clock and take the maximum of the sum, not the sum of the maxima.
saying these in an interview costs you the question
- Summing per-site peaks that occurred at different moments
- Adding sampled flow counts without scaling by each sampling rate
- Reporting total bytes as though it proved absorbed capacity
- Treating a flat-topped graph as the real attack ceiling
- Implying detection when no threshold ever fired