Sean Troxel

Chief Technology Officer

An instinct for how systems work, hard-won and applied to infrastructure that holds up under pressure.

See what one missing piece costs a network

Three types of networks, each with more redundancy than the last: a single path from the internet to the desks, then a firewall pair with a backup ready to take over, then a two-site design with clustered firewalls and multiple uplinks. Reachability is computed live for each one, so a failure shows you exactly which parts of the business it takes with it.

An interactive network diagram belongs here: three networks doing the same job with different amounts of redundancy, with reachability recomputed live as nodes are taken offline. It needs JavaScript to run. What it demonstrates:

Small - one uplink, one firewall, one switch
This is the one that fails first, and it fails completely. Take out the uplink, the firewall or the switch and everything behind it goes dark in the same instant, servers and workstations together, and the status reads Business down. Nothing reroutes, because there is nowhere else for traffic to go.
Medium - paired uplinks and firewalls, two switches, a server pair
The same failure becomes a failover. The primary firewall dies and its VRRP backup carries the traffic; the primary uplink dies and the second one takes over; a switch dies and the servers answer on their secondary. What still hurts is the workstation groups, single-homed to one switch each on purpose, so losing a switch takes its group with it and the status drops to Services affected while the rest of the business keeps working. Only losing both halves of a pair puts it back where the small tier started.
Large - two sites, four uplinks and two firewall clusters each, meshed core, dedicated site-to-site links
No single failure reaches the business function. Uplinks, firewalls and core switches resolve as one fabric, so every surviving path carries and damage is absorbed rather than routed around. Lose all four uplinks at one site and it rides the point-to-point site links to the other site's internet, which reads as degraded rather than down, because it is. The single-homed workstation groups remain the weakest thing on the diagram at every tier: redundancy stops where the last cable stops.
One failure, three network designs A frozen frame of the interactive diagram at the moment the primary firewall goes offline, with all five stages of each network drawn: uplink, firewall, switching, servers and desks. The small network has one of everything, so the failure takes the switch, the server and the desks down with it. The medium network answers at every stage rather than just the firewall: paired uplinks, a firewall pair whose backup carries, two meshed switches and a server pair, so the same failure is absorbed. The large network widens each of those stages again to four uplinks, two firewall clusters, a meshed three-switch core and a server pair. In both of the redundant designs the desk groups are the exception, single-homed to one switch each on purpose, which is the one place a single failure still costs something. One failure, three designs The primary firewall goes offline in each of the three. uplink firewall switching servers desks Small: one of everything, in a line ISP Firewall Switch Server Workstations single 1 down, none left unreachable unreachable unreachable Business down. Switch, server and desks all go with it. There is no second anything to fail over to. Medium: a pair at every stage, and a meshed core ISP-1 ISP-2 FW-1 FW-2 SW-1 SW-2 SRV-1 SRV-2 WS-1 WS-2 pair 1 down, 1 carries meshed pair single-homed All systems normal. The failure became a failover. Desks are the exception: one switch each, no second path. Large: four uplinks, two clusters, a meshed core ISP-1 ISP-2 ISP-3 ISP-4 FW-A1 FW-A2 FW-B1 FW-B2 SW-1 SW-2 SW-3 SRV-1-A SRV-1-B WS-1 WS-2 WS-3 four 1 down, 3 carry meshed pair single-homed All systems normal. No single box is load bearing. One of two identical sites; dedicated links join them, and stay on standby because three firewalls still carry. Legend: the red box is the failed firewall. The line under each stage names its redundancy. Dashed links carry nothing.
Static snapshot of the failure the live diagram is built around, composed by hand rather than captured from it. The interactive version computes this state live and lets you cause it anywhere in the network.

Watch a botnet search for weaknesses in your network

A botnet does not know where you are. It wanders until something answers, then it piles on, and the machines it finds first go down hardest. Three networks face the identical swarm here: one with no defense at all, one that pushes attackers back, and one that holds them inert until they give up. Nothing about the attack changes between them. The only variable is what the network does when the swarm arrives.

A swarm simulation belongs here: a botnet wandering a field of servers, piling onto whatever answers, against three networks that differ only in what they do when it arrives. It needs JavaScript to run. What each defense does to the identical swarm:

No defense
Attackers hold connection slots until the server has none left, and it goes offline. Losing the server is what clears the attack, since the swarm on it dies with it - so the node comes back, and so does the swarm. Its outage count climbs faster than either of the others by a wide margin, and nothing else on this tier ever stops an attacker.
Rate limiting
Past a threshold the server pushes attackers off and scatters them, then waits out a cooldown before it can do that again. That buys real time and the outages drop sharply, but it removes nobody: the same attackers are still on the field, still looking, and a wave that lands inside the cooldown takes the server down anyway. It ends up carrying the largest live swarm of the three, precisely because it is the tier that stops detonating without ever clearing anyone.
Rate limiting and tarpitting
The same pushback, unchanged, plus a tarpit: a connection identified as hostile is captured rather than pushed, held open and inert until it times out. This is the only tier where the stopped count moves at all - on the other two the only thing that ever clears a connection is the server going down. Outages become rare instead of routine, with capacity still getting close during a heavy pile-on. The claim stops there: a captured connection is not a captured machine, and none of the three swarms gets smaller.
Swarm frame 1 of 3: first contact A field with two botnet sources at the edges and three servers across the middle. A handful of attacker connections have wandered in and locked onto each server. Drawn once for all three networks, because at this point they are identical: the defenses differ, but none of them has fired yet. Frame 1 of 3: first contact Identical in all three networks. The attack never varies. BOT-1 BOT-2 SRV-1 a few locked SRV-2 a few locked SRV-3 a few locked A few connections have locked on. No defense has fired. Legend: solid triangle = an attacker connection on the field. Ring = the defense firing. Hollow triangle = captured, held. Counts are illustrative wording, not readings from a run.
Frame 1 of 3. Static, hand-composed, and not a capture of the running simulation.
Swarm frame 2 of 3: sustained pressure The same field drawn three times, once per defense. With no defense the connection slots keep filling and SRV-2 is near full. With rate limiting the defense has fired, drawn as a ring, and attackers have scattered, but every one of them is still on the field. With rate limiting and tarpitting the same ring fires and three connections have additionally been captured and parked, drawn as hollow triangles. Frame 2 of 3: sustained pressure Same swarm, same field. Only the defense differs. No defense SRV-1 filling SRV-2 near full SRV-3 filling Slots keep filling. Nothing pushes back, nothing is removed. Rate limiting repulsion fired SRV-1 filling SRV-2 pushed back SRV-3 filling The threshold trips and attackers scatter, but none leave. Rate limiting and tarpitting repulsion fired SRV-1 holding SRV-2 pushed back SRV-3 holding held: Same pushback, plus connections captured and held inert.
Frame 2 of 3. Static, hand-composed, and not a capture of the running simulation.
Swarm frame 3 of 3: where each defense ends up The same three fields later in the run. With no defense SRV-2 is offline and the attackers that killed it are gone with it, which is the only thing that ever clears them there. With rate limiting SRV-2 is offline too, because a wave arrived while the defense was still on cooldown, and the field around it is the most crowded of the three. With rate limiting and tarpitting all three servers are still answering and the held count keeps climbing. Frame 3 of 3: where it ends up The same swarm, further into the same attack. No defense SRV-1 filling OFFLINE SRV-2 overwhelmed SRV-3 filling SRV-2 goes down. Its swarm dies with it; both come back. Rate limiting SRV-1 filling OFFLINE caught on cooldown SRV-3 filling A wave landed during the cooldown. Fewer outages, not none. Rate limiting and tarpitting SRV-1 online SRV-2 online SRV-3 online held: All three still answering. The held count keeps climbing.
Frame 3 of 3. Static, hand-composed, and not a capture of the running simulation. The live version never reaches a final state, which is why this is three frames rather than one.

15

person team led

100+

business clients

~2,000

endpoints under active management

up to 10,000 touched annually

SOC 2 Type I

completed 2022

Career progression

  1. Support Specialist I-III

    2017-2019

  2. Systems & Network Engineer

    2019-2020

  3. Chief Technology Officer

    Sep 2020-Present