Wednesday, August 19, 2026
Transparency Report #013 — Monitoring Anomalies and RRL Activity
What are Transparency Reports?
As a community‑operated and governed virtual internet exchange, FurrIX maintains
a commitment to open and honest communication with its members. From time to
time, operational work may occur that affects the exchange or its supporting infrastructure.
When this happens, the FurrIX operations team publishes a transparency report to
ensure all members remain informed. As a hobbyist‑rooted vIX, we aim to keep
communication clear, accessible and practical to the best of our ability.
What Happened
On the afternoon of 18 August 2026, our monitoring system (LibreNMS) began displaying
abnormally large bandwidth spikes for NS2, including inbound and outbound traffic peaks
exceeding hundreds of megabits per second. These values were inconsistent with NS2’s
QoS limited capacity and did not match host‑level counters or resolver behavior.
During the same period, NS2 received a high‑volume PTR sweep from the IPv6 prefix
2a05:f480:2400::/48. Bind’s Response Rate Limiting (RRL) immediately escalated and
began dropping all responses to the prefix. This prevented any outbound meaningful
traffic spikes on the VM and kept resolver load stable.
A review of physical host metrics, VM‑level counters and RRL logs confirmed that
NS2 never transmitted the large volumes of traffic shown in LibreNMS or displayed on
our website graphs. The anomaly was isolated to the monitoring layer and one of our
volunteers pointed out to us that our LibreNMS VM is hitching, slow to respond and
sometimes timing out.
Changes to the Exchange
Our volunteers identified two issues within the monitoring stack:
- Interface Mapping Drift:
LibreNMS occasionally identifies the wrong interfaces for some of our VMs.
We’re currently investigating what is causing this and have an idea, but do
not want to point fingers until we are sure.
- Poller Delays:
The LibreNMS VM showed signs of slow polling and missed intervals. The
internal logs are showing both missed polls and ICMP issues within the
whole exchange, but our testing and probing shows otherwise.
We believe these issues caused the monitoring system to display incorrect bandwidth
values for NS2 and a few other VMs. No changes have been made to the resolver or network
at this time. Operations is preparing remediation options, including a rebuild of the NMS VM since
it still contains data from the project we split from, and will be presenting them to oversight
for consensus before proceeding.
Are Exchange Operations Affected?
No.
NS2 continued operating normally throughout the event. RRL successfully mitigated
the abusive PTR sweep, QoS remained effective and host‑level counters showed
stable, low traffic consistent with expected resolver behavior. The only affected
component was the monitoring system’s visibility layer. Member‑facing, peering and
internal services were not impacted.