Arbital / CTO & Founding Engineer
From first customer
to an ISP at scale.
Build the business by building its technology: networks, software, services and operations.
From the first customer to a working business
When we connected our first customer, the whole chain worked. The billing system generated the rules, and the customer came online. Seeing the software and network run together for a real customer was an incredible feeling. That was the moment the business felt real.
I joined Arbital as its only technical person and built the initial network, infrastructure and operating software. As the ISP grew beyond 15,000 active customers, other staff took on routine administration and support while I directed technical work across the network and operating platform.
The remit crossed software and physical infrastructure: routing, subscriber services, monitoring and the tools people used to run the business. The network evolved across dozens of external BGP connections spanning peering, Internet exchanges and carriers, with Linux and FreeBSD systems underneath.
The topology evolved from a flat network to VLAN segmentation. I introduced iBGP as the primary internal routing mechanism, retaining OSPF for backup reachability. Border routers used eBGP toward upstream providers and iBGP between them.
Customer policy became network behavior
I wrote an internal CRM and network-management platform, primarily in PHP. It joined subscriber records, provisioning, network state and customer policy, translating business rules into network configuration instead of repetitive manual changes.
The integrated platform covered dozens of use cases across customer management, network policy, monitoring, self-service and staff operations. The stories below are selected decisions within that broader system.
Explore the software that ran the ISP: subscriber activation, payment reconciliation and the path from customer policy to network behavior.
Make device replacement self-service
In a stable network, subscribers replacing computers or other devices had become the dominant reason for contacting support: their registered MAC address needed to change. I selected that recurring workflow for automation and built a self-service path for subscribers to register replacement devices themselves.
Approximately 70–80% fewer overall support requests.
This followed automation of the dominant request category. The measurement window is unspecified.Traffic policy from subscriber measurements
Zabbix and per-subscriber traffic monitoring, including customer-visible usage graphs, made the traffic distribution visible. Approximately 5% of subscribers generated approximately 80% of aggregate traffic.
I designed and implemented dynamic peer-to-peer shaping with FreeBSD's ipfw and dummynet, using software policy to control traffic. The measured reduction was 30–40% of aggregate autonomous-system traffic.
These are historical measurements. The traffic-reduction comparison baseline and measurement window are unspecified; the collection protocol is not established.
From multicast switches to Nginx delivery
I conceived and launched IPTV from scratch as a new service and revenue stream. The initial architecture used a dedicated multicast VLAN, Multicast VLAN Registration and IGMP snooping, with automated multicast access control and subscriber provisioning.
Production exposed differences between switch vendors: multicast behavior was unreliable, and some switches hung and needed on-site restarts. After several months of operating that design, I replaced subscriber multicast delivery with server-based unicast.
I designed and implemented the Nginx-based delivery path, using a multicast-to-unicast converter and centralizing channel entitlements in server configuration. Requests for channels outside a subscriber's package were redirected to an instructional or upsell video. Service policy now lived in a delivery layer I could configure directly.
Addressing with business consequences
I personally secured Local Internet Registry status and a public IPv4 /17 allocation. That enabled public subscriber addresses without NAT, created a competitive advantage and reduced network-equipment costs. The exact allocation date and monetary savings are unspecified.
Recover within the hardware you have
During the early single-border-chassis stage, both supervisor modules failed to boot after planned maintenance. There was no second border chassis available. I repurposed an older core device, but its routing-table capacity could not accommodate the full Internet table.
I accepted /20 and shorter BGP prefixes and rejected more-specific routes, fitting approximately 100,000 routes. That restored broad Internet reachability in approximately two hours, in a deliberately degraded mode. The decision brought the routing set within the fallback hardware's limits; the outcome describes that specific recovery.
High-speed service history
I launched Russia's first 100 Mbps plan. Arbital ranked as Russia's fastest ISP on Speedtest.net for several years in the late 2000s. These historical achievements are drawn from my confirmed career record.