Monday, May 25, 2026
[Transparency Report #007][OPERATIONS] Full Environment Rebuild Scheduled WIP
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 is happening?
The FurrIX vIX is currently going through its rebuild of our exchange and it is taking a little
longer than we expected. Due to a miscommunication, reinstalling the physical server’s OS
took a bit of time.
What has been reworked so far:
- Phy One: The ProxMox host has been rebuilt
- Core Router: We condensed our IPv6 edge and core router into one VM
- Nardoragon Router: Our services router is back online with new config
- Catos vIX Access Router: Has been pulled from backup and reconfigured
- NS1/Games-3P: These member facing services are back online
- Web Server: Our websites are back online
Parts of the exchange still being worked on:
- Mail-NG: the mail server has to be brought back online
- Ikus vIX Access Router: Secondary member facing router still being reconfig’d
- NMS: We currently have no monitoring, needs to be reconfigured
Are exchange operations affected?
Yes — temporarily.
During the rebuild window, routing and service availability will be null as systems are rebuilt
and renumbered. Once the work is complete, normal operations will resume with improved
stability, ease of expansion, better rooted upkeep and clarity.
Wednesday, May 20, 2026
[Incident Report #034][DNS] Inter‑subnet Communication Failure
What Happened?
On May 15th, our upstream data center completed a router upgrade. As an
unintended side effect, the FurrIX subnets located within the data center
were no longer able to reach one another. Because this issue was isolated to
internal data‑center paths, no external member traffic or internet‑facing name server
traffic were affected.
The issue went undetected until May 19th because our monitoring system and
our email system reside on opposite subnets. With inter‑subnet communication
broken, monitoring alerts could not reach us.
We were seeing the following issues:
- Internal service reachability — Some internal services were unreachable from
member connections. - NS2 isolation — Members could not reach NS2.
- Stale zones on NS2 — NS2 could not reach NS1; as a result, its zones
went stale on May 17th. - NMS visibility loss — The Network Management System could not reach devices
on PHY One for accounting and monitoring. - Backup failures — PHY One could not reach the PBS instance on PHY Two,
preventing nightly backups.
What did we do to fix this?
We provided the data center with test results and trace data confirming the inter‑subnet
routing failure. They corrected the configuration on their side, restoring full communication
between PHY One and PHY Two. All internal services, monitoring and backup operations
have returned to normal.
Monday, April 27, 2026
[Transparency Report #003][OPERATIONS] The start of a WHOIS Server…
What are Transparency Reports?
As a community operated and governed virtual internet exchange, FurrIX has
to maintain and foster open and honest communication with our exchange
members. This means that from time to time, there will be items that come
up during our operations that could or do affect the exchange and our team
will publish notices in order to keep everyone in the know. As a community
internet exchange, FurrIX aims to have fully open communication standards
as best as possible.
What Happened?
As part of FurrIX going forward and rebuilding itself in a better documented and
run exchange, we have been working in the background on getting a simple but
custom WHOIS server up in running in its own isolated space, meaning it has no
access to critical routing gear or management planes in case our custom tooling
has bugs that we are not aware of. This server is to allow our exchange members
and outside network operators to be able to query various bits of information
about our network, domains and services using a brain dead just answer kind of
protocol. It is simple, easy to interface and just works.
At the moment, our WHOIS is running on sample data until we start doing the
actual rebuild of the FurrIX exchange, but it is usable. After the rebuild, the WHOIS
server will contain actual exchange data such as our network information, host
information, router notes, domain information, service info and who is responsible
for that gear and so on. For the WHOIS server, because it faces the public, member
emails will get replaced with a generic FurrIX address. Nickname and PTR will still
be published as is.
Also, while I am here making this post, just for the nitty gritty tech guys to wince
at a bit- the WHOIS server is built on Python using a flat YAML data store. Its
kinda crummy, catches fire sometimes with formatting, but thats all failsafe modules
we built in to the server. Hopefully, with us being a very small vIX, this service
last us for a bit of time to come.
To make a query, use your system terminal and run:
whois -h ns1.marbledfennec.net dwagon and you should hear a response
back from our snarky mascot, Marble. You can also query the domains
rsd.232.gay, marbledfennec.net and furrix.zone.
What this means for members of the exchange:
- Our WHOIS server will be the central authority on information about
our network, domain, service and membership census. If it exist on the
the exchange, it will have an entry in the WHOIS server - When adding entries, our WHOIS server is customized to help our
volunteers by also generating reverse, or PTR, name server zones! - Marble can actually be poked at by our members now, lovely!
Are exchange operations affected?
This is a feature addon, it does not affect core operations.
Wednesday, April 22, 2026
[Transparency Report #002][OPERATIONS] Name and mail server changes!
What are Transparency Reports?
As a community operated and governed virtual internet exchange, FurrIX has
to maintain and foster open and honest communication with our exchange
members. This means that from time to time, there will be items that come
up during our operations that could or do affect the exchange and our team
will publish notices in order to keep everyone in the know. As a community
internet exchange, FurrIX aims to have fully open communication standards
as best as possible.
What Happened?
As part of FurrIX going forward and rebuilding itself in a better documented and
run exchange, there have been parts of the network that we have kept from
Marbled Fennec Networks. The biggest things we have kept are the web, mail
and name servers. But all of these have been needed some reconfiguration to
fully move into our name space and management plane.
We are currently working on making some of the needed changes.
What this means for members of the exchange:
- NS1 and NS2 are in a hybrid state, answer DoH and DoT
on both the marbledfennec.net and furrix.zone domains to
maintain network operations and compatibility - FurrIX can now be emailed without going through Marbled Fennec
Networks. The email server has been reconfigured to service both
domains going forward, as MFN will retain email service
Are exchange operations affected?
This should not have any visible affect on our exchange members. The
network should just keep humming right along all peachy.
Monday, April 20, 2026
[Incident Report #033][DNS] Suspended lookups for ‘look.com’
What Happened?
NS2 has been seeing a low-volume, but constant stream of lookups for
‘look.com’ for the past few days. These lookups are for ANY and are spread
across a handful of IPv4 addresses. Seeing as most lookups only make a
handful of request before the requesting machine has the info it needs,
we are dropping these lookups for a little while because our NOC is treating
it as internet background radiation.
We were seeing the following issues:
- Steady, low rate, constant lookups for ANY against ‘look.com’
What did we do to fix this?
- Temporarily dropping lookup request for ‘look.com’