Summary

  • A November 2020 LINX engineering article jointly credited Senior Network Engineers Mo Shivji and Jan Kayser and Systems Reliability Engineer Ariel Smutkochorn with documenting a route-server and route-collector observability migration. The record connects legacy Quagga and Cisco 7200 constraints, Alice LG and Birdwatcher selection, an all-route-server memory test, a move from a virtual machine to physical hardware, and consolidation of most collectors onto BIRD-based captain servers.
  • The evidence supports a profile of Kayser as one named contributor to a team record, not as the sole designer or decision-maker. Current 2026 institutional material identifies him as a LINX Senior Network Engineer and a named presenter on a separate LON2 refresh, but vendor selection criteria and the 17-site result belong to LINX's institutional record and do not retroactively assign him sole credit.

A Profile Built From an Engineering Record, Not a Biography

The useful starting point for a profile of Jan Kayser is not a broad account of career, personality, or ambition. The available public evidence does not provide that kind of biography. It provides something narrower and, for understanding Internet infrastructure, more concrete: a dated engineering account in which Kayser is named alongside two colleagues and in which the operating constraints are described closely enough to reconstruct the decisions that followed.

LINX published that account on 10 November 2020 under the title "New LINX Route-Server Looking-Glass." Its closing credit names Senior Network Engineers Mo Shivji and Jan Kayser together with Systems Reliability Engineer Ariel Smutkochorn. That line sets the attribution boundary for everything that follows. The migration was presented as work of a three-person engineering group within LINX. The article does not divide every choice or implementation step among the three authors. It therefore supports naming Kayser as a documented contributor, while requiring the actions themselves to remain attributed to the team.

This distinction is not ceremonial. Route-server operation crosses software, routing policy, systems reliability, hardware, configuration management, and the needs of exchange members trying to understand route visibility. Assigning every result to one person would erase the shared operating surface described in the source. Leaving Kayser unnamed would also be inaccurate, because LINX explicitly included him in the engineering credit. The defensible profile sits between those errors: it follows the decisions recorded by the team and treats Kayser's named participation as significant without manufacturing exclusive control.

The 2020 account is especially useful because it does not present a finished interface as if it appeared fully formed. It starts with the reason a looking glass exists, then moves through ageing routing software, end-of-service collector hardware, shrinking maintainability of internal tools, selection requirements, testing, a memory constraint, deployment changes, and a different arrangement for collectors. The resulting story is less about a product launch than about the operational trade-offs required to make routing information observable on a live exchange.

That sequence also gives the profile its proper scale. The subject is not all of LINX, all of Kayser's work, or every decision affecting the exchange. It is one documented migration whose constraints can be checked against a primary institutional source. A later 2026 record can show continuity in Kayser's public role, but it cannot broaden the 2020 attribution beyond what the original engineering account says.

The Observability Problem Came Before the Product Choice

LINX's account begins by explaining the practical role of a looking glass. An operator troubleshooting BGP may need to see routing information from a router in another autonomous system without receiving full administrative access to that router. LINX had historically met that need in more than one way, including read-only Telnet access to route collectors and web interfaces for route servers and collectors. Those arrangements exposed useful information, but the engineering team reported that the collection of legacy systems no longer kept pace with modern requirements.

This framing matters because it keeps the migration tied to an operating need. The problem was not that an old interface looked dated. The problem was whether operators could inspect routing state through tools that remained supportable as the routing environment changed. A looking glass sits between sensitive infrastructure and people who need enough visibility to diagnose reachability. It must expose useful state without becoming a substitute for administrative control.

Its value therefore depends on the routing software behind it, the data it can represent, the interface it offers, and the ability of engineers to maintain the whole arrangement.

The public account describes two legacy paths. On route servers, LINX used an in-house looking glass originally developed in 2003 for Quagga-based systems. On Cisco route collectors, it used mlrg, which the article described as no longer under active development. These were not identical tools, and the reasons for replacing them were not identical. The internal route-server tool carried accumulated technical debt and depended on a declining pool of engineers familiar with it. The collector interface depended on software whose active development had ended.

Both conditions made future changes harder, but they represented different forms of operational risk.

The distinction helps explain why observability cannot be separated from lifecycle management. A tool may continue to display routes while the knowledge needed to modify it becomes scarce. Another may remain available while its upstream development stops. Neither failure has to begin with an outage. The warning can appear first as slower feature work, an inability to accommodate routing enhancements, or a widening gap between the production routing stack and the interface used to inspect it.

LINX's team translated those pressures into explicit requirements for a successor. The replacement needed an easy-to-use graphical interface, support for modern BGP enhancements and RPKI, an API, and active maintenance. Those requirements describe four different operating constituencies. The interface serves a person examining routes. Routing support keeps the view aligned with the network's protocol capabilities. The API permits structured access rather than confining observation to manual use. Active maintenance addresses the long-term ability to correct and extend the software.

By stating the requirements before naming the selected tools, the record avoids treating software choice as brand preference. Alice LG and the accompanying Birdwatcher API were selected because the team judged that combination to satisfy the stated needs. The source does not assign that judgment to Kayser alone, and it does not claim that the same selection would be right for every exchange. It shows a bounded decision: given LINX's legacy systems and requirements at that time, the jointly credited engineers recorded Alice LG and Birdwatcher as the successor.

BIRD Became the Common Routing Baseline

The looking-glass migration was connected to an earlier change in the route-server software beneath it. According to the 2020 account, LINX route servers had originally been based on Quagga. LINX later moved half of them to BIRD to improve resilience against bugs specific to one software implementation. The article then says that growing difficulty adapting Quagga to requirements such as RPKI and BGP enhancements led LINX to migrate all route servers to BIRD.

That history reveals a real trade-off. Running two implementations can limit exposure to a defect confined to one of them. At the same time, each implementation has to continue meeting the protocol, policy, operating-system, automation, and observability requirements of the exchange. The source records that Quagga's ability to follow the required changes became the limiting condition. LINX's response reduced implementation diversity at the route-server layer while establishing BIRD as the common base for later automation and looking-glass work.

The record does not say that software diversity ceased to matter. It says why the previous form of diversity no longer held. This is a more rigorous account than treating either diversity or standardisation as an absolute good. Diversity can contain one category of defect, while standardisation can reduce variation in configuration, integration, and support. The balance depends on whether both implementations remain operationally viable. In LINX's account, new routing requirements and maintainability changed that balance.

The move to BIRD also changed the economics of subsequent work. LINX had recently invested in automating BIRD route-server configuration. Once the route servers shared that base, the same body of operational knowledge could inform the migration of collector functions away from old Cisco hardware. This did not make route servers and collectors identical. It created a common routing implementation and a configuration approach that the team could reuse while preserving separate functions and separate looking-glass instances.

For Kayser's profile, the important point is the quality of the documented chain. The jointly authored article does not simply say that BIRD was newer. It identifies the earlier mixed-software rationale, the growing requirements Quagga struggled to meet, the completed route-server migration, and the existing automation investment that made BIRD relevant to the collector decision. Kayser's name is attached to that explanation as one of its engineering authors. The explanation remains a LINX team record rather than evidence of a unilateral decision.

End-of-Service Collectors Forced a Second Lifecycle Decision

The route collectors presented a hardware problem as well as a software problem. LINX reported using Cisco 7200 collectors for about two decades. Those systems had been end of service since 2015 and needed to be retired. The article does not describe a dramatic failure that forced an emergency replacement. Instead, it treats support status and age as sufficient reasons to remove a long-running dependency before it became an indefinite exception.

That is a significant operating choice. Infrastructure often survives beyond a vendor milestone, especially when its task is stable and engineers understand it. Continued operation, however, does not erase the consequences of the lifecycle boundary. Replacement parts, software support, security maintenance, and integration with newer systems can all become harder even while packets and routes continue to flow. The 2020 account does not enumerate every one of those risks, so they should not be attributed to LINX as specific incidents. What it does establish is that end-of-service status made retirement necessary in the team's assessment.

The collectors also carried a legacy interface dependency. LINX used mlrg for the Cisco routers, and the article says that software was no longer actively developed. Hardware and interface were therefore ageing together. Replacing only the web layer would have left the old collector platform in place. Replacing only the collector hardware without a maintainable visibility system would have preserved a different part of the problem. The migration had to address the routing process, the machines running it, and the way operators queried the result.

The existing BIRD investment narrowed the options. LINX had already automated BIRD configuration on the route servers and had chosen Alice LG for the new visibility layer. The team described migration of the collectors to BIRD as the evident way forward in that context. That statement should be read as a decision within the architecture LINX had already built, not as a universal claim that one routing implementation is always correct for both functions.

The sequence illustrates how technical debt becomes architectural. The in-house looking glass was difficult for a shrinking pool of familiar engineers to extend. The collector interface lacked active development. The Cisco hardware had crossed its service boundary. Quagga had become difficult to adapt to required routing changes. Each item could be described separately, but the migration became practical when the team treated them as one connected lifecycle problem and reused the BIRD automation already operating on route servers.

Requirements Narrowed the Looking-Glass Choice

The selection of Alice LG and Birdwatcher is easy to reduce to a product name. The engineering record supports a more useful reading. LINX first identified the capabilities that the previous arrangement did not reliably provide, then selected a combination that met those needs. The requirements were visible enough to test: a usable graphical interface, support for relevant BGP enhancements and RPKI, API access, and active maintenance.

Each requirement closed a specific gap. The graphical interface addressed human inspection. The routing features aligned the looking glass with changes already affecting the route servers. The API created a machine-readable path into the same observation system. Active maintenance answered the problem represented by old internal code and by mlrg's development state. A replacement that met only one or two of those conditions would have reproduced part of the original constraint.

The pairing of Alice LG with Birdwatcher also separated presentation from collection. The source describes Birdwatcher as the accompanying API and reports a test in which Birdwatcher on a route server emulated LON1 RS1 for the looking glass. The article does not provide a full component diagram, so it would be wrong to infer undocumented deployment details. It does show that the selected system depended on data collection from routing instances and that testing the complete set of route-server connections changed the hardware decision.

This is where the API requirement becomes more than a feature-list item. A graphical view can be useful to a person, but an API establishes a defined path by which routing data reaches other software. That path has capacity, failure, and maintenance characteristics of its own. LINX's later memory finding demonstrates that the visibility layer had to be tested as an aggregate system, not only as an interface that worked against one emulated route server.

The RPKI requirement also needs careful attribution. The 2020 article says Quagga had increasing difficulty adapting to RPKI and other BGP enhancements, and it names RPKI support among the looking-glass requirements. It also says the route collectors did not implement some route-server functionality related to RPKI and route filtering. The record therefore does not describe one undifferentiated RPKI function everywhere. It shows that the team wanted the observability system to handle the route-server context while preserving a reduced collector context where those functions were not present.

That distinction is operationally important because an observation tool should not imply that two routing roles enforce the same behavior when they do not. A route server and a route collector may both receive BGP information, but their purposes and policy surfaces differ. LINX maintained separate Alice LG instances and configured the collector view similarly while omitting functionality that did not exist on the collectors. Similarity reduced unnecessary variation; separation preserved truth about the underlying systems.

Nothing in the source establishes that Kayser alone wrote the requirements, evaluated every option, or selected the software. The correct statement is that he was one of three named authors of the LINX engineering record that documented those requirements and the resulting choice. That may sound more restrained than a conventional leadership profile, but it is also more informative. It ties a named engineer to a reproducible decision framework without turning shared infrastructure into a personal achievement story.

The Aggregate Test That Changed the Deployment

The most revealing part of the migration is not the initial success. It is the test that invalidated the initial deployment assumption. LINX reported that work on the Alice LG replacement began in February 2020, after route-server work to enable RPKI and upgrade the operating system to Ubuntu. Initial testing used a virtual machine on one route server, with Birdwatcher emulating LON1 RS1. In that limited setup, the system worked.

The result changed when the team connected all LINX route servers to the looking glass in a test environment. The account says it became clear that more memory was required. The team then chose a physical device with more memory, where Alice appeared to work better. The language is empirical and appropriately modest. It does not offer a universal sizing formula or claim that virtual machines are unsuitable for looking-glass workloads. It records that the single-server emulation did not expose the resource demand of LINX's aggregate test.

This is a small episode with broad operational meaning. A component can pass a functional test and still fail to represent production scale. The initial trial answered whether the selected pieces could work together against an emulated route-server instance. The later test answered a different question: whether the deployment had enough memory when connected across the exchange's route-server set. Both tests were valid, but they measured different constraints.

The decision to move to physical hardware followed the observed limit rather than a prior claim about architectural purity. The source does not say that bare metal was a strategic objective. It says the team needed more memory and that a physical device with more memory improved operation. That ordering is important. The hardware form was a response to measured demand. It was not presented as proof that one deployment model is inherently superior.

The episode also shows why observability must be capacity-planned as part of the routing system. A looking glass does not forward member traffic, but its usefulness depends on receiving, retaining, and presenting enough routing information to answer questions. If the observation layer cannot handle the combined data sources it is meant to expose, the interface may exist without providing the intended operational view. Capacity at that layer is therefore a continuity concern even when forwarding continues elsewhere.

The public record does not disclose exact memory values, route counts, query rates, or hardware models for the replacement device. Those omissions should remain omissions. They prevent a quantitative comparison and make it impossible to derive a general capacity rule from this case. What can be said is narrower: LINX tested beyond the one-instance emulation, found the memory allocation insufficient for the broader connection set, and changed the deployment accordingly.

This is also an example of running evidence overruling an attractive abstraction. Virtualisation can simplify allocation and operations in many settings, while physical deployment can provide a different capacity or licensing profile. The source does not evaluate those approaches in general. For this migration, the deciding fact was that the tested virtual-machine arrangement did not have enough memory for the intended aggregate connection, while the higher-memory physical device performed better.

Kayser's place in this episode remains collective. The 2020 article uses "we" throughout and closes with the three engineering credits. A responsible profile can say that Kayser helped document an engineering process in which broader testing exposed a resource constraint and changed deployment. It cannot turn that process into evidence that he personally ran the test, diagnosed the memory issue alone, or ordered the hardware.

Captain Servers Turned Reuse Into a Bounded Trade-Off

The collector migration introduced a second resource decision. In the fall of 2020, LINX began retiring the Cisco 7200 route collectors and moving their function to systems called captain servers. The article describes one captain server per site, normally used for troubleshooting and monitoring tasks. Co-locating collector functions on those systems avoided installing a separate physical server in every LAN or purchasing virtual-machine licences.

This was not cost avoidance in the abstract. It was reuse of an existing per-site operating footprint. The captain servers were already associated with monitoring and troubleshooting, which made collector work adjacent to their existing role. The team could place BIRD collector processes on machines distributed across the sites and apply the configuration automation developed for route servers. That arrangement reduced the need for another class of dedicated machine at most locations.

Reuse still required capacity. LINX upgraded memory on the captain servers before the collector functions were co-located. This mirrors the earlier looking-glass test in a useful way. In both cases, the desired software arrangement met a physical resource boundary. The response was not to pretend the existing allocation was enough. The team increased memory, then reported the resulting placement.

The final topology retained an exception. All collectors except the LON1 collector were co-located on captain servers; LON1 continued on a dedicated server. The source does not explain why that exception remained, so the reason should not be invented. Its presence is nevertheless important. It prevents the migration from being described as total uniformity and shows that the operating result included one explicitly different deployment.

Exceptions are often where infrastructure accounts lose precision. A summary may say that collectors moved to captain servers and omit the dedicated LON1 system. LINX's article kept the exception visible. That makes the record more useful because it identifies both the common design and the boundary where it did not apply. It also avoids confusing configuration consistency with physical sameness.

The collectors ran BIRD using the same configuration automation as the route servers. This reuse likely reduced the number of distinct configuration mechanisms the team had to maintain, but the source does not quantify labour savings or error reduction. Those outcomes should not be asserted. The supported conclusion is that LINX deliberately applied an existing automation approach to the new collector processes, making the collector migration part of the same operational system as the earlier route-server standardisation.

The trade-off can therefore be stated without speculation. Dedicated collector hardware at every LAN or additional virtual-machine licences would have imposed one resource pattern. Co-location on existing captain servers imposed another, including memory upgrades and shared use of machines already carrying troubleshooting and monitoring tasks. LINX chose the second pattern for most collectors and retained a dedicated system at LON1.

That choice also demonstrates that consolidation is not the same as centralisation. The captain servers were per-site systems, so co-location reduced the number of device roles without collapsing all collection into one physical location. The source does not provide enough topology detail to evaluate every failure mode. It does establish that the collector function remained distributed across site-associated systems, with the LON1 exception separately identified.

For an engineering profile, this is more meaningful than a generic claim about efficiency. The jointly credited record shows a team comparing hardware installation, virtual-machine licensing, available per-site systems, and memory capacity. Kayser is one named participant in that record. The evidence supports association with a documented trade-off, not a claim that he alone devised the captain-server model or produced its outcome.

Separate Views Preserved Different Routing Functions

After the migration, LINX operated separate Alice LG instances for route servers and route collectors. The collector instances were configured similarly to the route-server looking glass, but without some functionality related to RPKI and route filtering that was not implemented on the collectors. This is one of the most important details in the account because it shows that standardisation stopped where the underlying routing roles diverged.

A route server participates in the exchange's route distribution service. A collector observes routes without implementing the same service behavior. LINX's source does not offer a general tutorial on those roles, but its deployment reflects the difference. Both could use BIRD. Both could be exposed through Alice LG. Both could benefit from similar configuration. Yet the collector view could not honestly present policy functions that the collectors did not implement.

The arrangement therefore combined a common software baseline with role-specific truth. That is a stronger form of consistency than forcing identical interfaces over different systems. An operator looking at the collector instance should see the capabilities and data of the collector, not a decorative copy of controls available only on route servers. The separate instances made that boundary explicit.

This separation also helps interpret the RPKI references in the 2020 record. LINX had upgraded route servers to enable RPKI and wanted the new looking glass to support it. The collectors, however, lacked some route-filtering and RPKI-related functions available in the route-server context. The evidence therefore supports talking about accurate observation of each running role. It does not support saying that every BIRD process in the migration applied identical routing policy.

The public links at the end of the engineering article reinforced the distinction by directing users to one looking glass for route servers and another for route collectors. The article's concern was not simply to make routes visible somewhere. It was to make two operational views available without obscuring the difference between the systems producing them.

In practical terms, this is where the migration moved from component replacement to information design. Operators need to know what a view represents before acting on it. Similar interfaces can reduce cognitive load, but only if labels, functions, and data remain faithful to the underlying system. LINX's use of separate instances preserved that fidelity while reusing Alice LG, Birdwatcher, BIRD, and configuration patterns where appropriate.

What Joint Attribution Requires

The 2020 record supports a clear statement about Jan Kayser: LINX named him as one of two Senior Network Engineer authors, alongside Mo Shivji, with Systems Reliability Engineer Ariel Smutkochorn, on the article documenting the migration. It also supports a clear statement about the work: the team described the constraints, tests, decisions, and observed deployment in collective terms.

It does not support assigning the Alice LG and Birdwatcher choice to Kayser alone. It does not identify who first proposed BIRD for collectors, who configured each captain server, who measured memory, who acquired hardware, or who wrote particular automation. It does not say that one author controlled route policy or carried sole responsibility for service continuity. Any account that fills those gaps with a hero narrative would add claims absent from the evidence.

Preserving the three credits is not a reason to make the profile vague. The record contains enough detail to describe the engineering contribution precisely. Kayser was part of a named team that publicly documented why legacy tools were no longer supportable, why all route servers had moved to BIRD, why Cisco 7200 collectors needed retirement, what the successor looking glass had to provide, how an aggregate test exposed a memory limit, and how most collectors were placed on upgraded captain servers.

That form of attribution is useful in infrastructure reporting because it joins individual accountability with system reality. A named author can stand behind a technical explanation without being made the sole cause of a distributed result. The organisation remains responsible for the operating service. The other credited engineers remain visible. Hardware, software, automation, and testing remain part of the causal chain rather than scenery around one person.

There is also a difference between authorship and exhaustive implementation credit. The article's closing line establishes that the three engineers wrote the account, but it does not state that no one else at LINX contributed to the underlying work. The safest interpretation is therefore positive and bounded: the source directly names the three authors and documents a team process; it does not provide a complete personnel ledger for the migration.

Kayser's profile is strongest when it respects that limit. His public significance here comes from being attached to a technical record that exposes trade-offs instead of hiding them. The record admits that one-instance testing was insufficient, that more memory was needed, that a physical deployment worked better in this case, that captain servers required upgrades, and that LON1 remained an exception. Those details make the engineering account credible without requiring a claim of sole leadership.

The 2026 Record Is Corroboration, Not Retroactive Credit

NetUK3's event-dated records provide a later, narrower connection between Kayser and LINX network engineering. The NetUK3 speakers directory and plenary session page list Jan Kayser of LINX as the speaker for "LON2 Network Refresh." The event's 6-7 July 2026 participant roster records Jan Kayser with LINX and the role "Senior Network Engineer." These dated listings support only the role and presentation attribution they contain; they do not establish an unqualified present-tense employment claim.

Those records corroborate professional continuity. They show that Kayser was publicly identified in 2026 in the same broad engineering role and as the presenter for a later technical subject. They do not provide the presentation bytes in the frozen evidence, and they do not establish that he made every LON2 decision. The event abstract describes a live migration of an end-of-life network serving roughly one third of LINX membership and signals discussion of operational issues, but the evidence available here does not support reproducing unobserved details from the talk.

LINX's separate institutional reports describe the completed LON2 refresh. One reports a 17-site project driven by end-of-life equipment and a selection process involving proofs of concept against a vendor shortlist. It says the required platform had to support LINX interconnection services, EVPN, and port options from 10GE through 800GE, while preserving diversity from LON1. Another reports that LON2 was refreshed across all 17 sites onto Nokia IXR hardware with SR Linux, retained its VXLAN-based EVPN architecture, and remained diverse from LON1 in hardware and software.

Those are useful continuity facts, but their attribution is institutional. The stated vendor criteria are attributed in the LINX material to CTO Richard Petrie. The pages do not assign the Nokia selection to Kayser. They therefore cannot be used to say that Kayser chose the vendor, designed the platform, or caused the 17-site result. His supported connection is limited to the NetUK3 speaker and session records naming him as the presenter for the refresh and the event-dated participant roster listing him with LINX as "Senior Network Engineer."

Keeping the 2026 material bounded protects the logic of the profile. The primary subject remains the 2020 observability migration, where Kayser is directly named in the engineering byline and the implementation chain is available. The later material shows that he continued to appear in public professional records associated with LINX engineering and operational migration. It does not transform a team-authored 2020 article into proof of individual ownership over a separate 2026 programme.

The two records nevertheless share a legitimate operational theme. In 2020, end-of-service collectors, maintainability, routing features, memory, and deployment form constrained the looking-glass migration. In 2026, LINX described an end-of-life fabric refresh bounded by protocol continuity, capacity range, and diversity from another LAN. The evidence supports observing that both institutional accounts make lifecycle constraints visible. It does not support saying that Kayser personally imposed or resolved all of those constraints.

What the Public Record Supports

The public evidence supports a focused account of Kayser as a named member of a LINX engineering team that documented an observability migration in operational terms. The strongest person-level fact is the 2020 joint credit.

The strongest technical facts are the dated constraint-decision-result chain inside that article: legacy tools had become difficult to maintain or were no longer actively developed; Quagga no longer met required changes; Cisco 7200 collectors were end of service; Alice LG and Birdwatcher met the stated requirements; broader testing exposed a memory limit; physical deployment supplied more memory; and upgraded captain servers carried most collector functions using BIRD and existing automation.

The record also supports several explicit limits. LON1's collector remained on a dedicated server. Collector looking-glass instances omitted route-server functions that collectors did not implement. The initial virtual-machine test worked in a narrow setup before the aggregate test revealed more demand. These are not marginal details. They define where the migration was non-uniform and where the observed system overruled the first assumption.

The evidence does not support private biography, inferred motives, incident blame, security guarantees, or claims about customer impact. It does not prove that the migration eliminated every failure mode. It does not quantify memory, route volume, staffing effort, cost savings, or availability improvement. It does not establish sole credit for Kayser, Shivji, or Smutkochorn, and it does not provide a complete list of everyone who may have contributed inside LINX.

Within those boundaries, Kayser's record is substantial because it is attached to an engineering explanation that can be examined. The article shows what the team inherited, what it required, what it tested, what failed to scale as first arranged, what it changed, and what remained exceptional. It treats observability as running infrastructure rather than a passive web page. That is the defensible core of the profile.