The networking industry talks a lot about automation; the problem we talk about less is that much of that data we’re trying to automate isn’t reliable enough. At Inter.link, we’ve run into this firsthand. Public data sources such as Peering DB, IRRs are essential to our automation, but inconsistent, incomplete or outdated information can disrupt automated workflows.
Inter.link has discovered a limitation in how the industry operates and it needs fixing.
Stefan Funke, our Head of Network & Infrastructure explains how inconsistent public data can limit network automation, why building private workarounds isn’t always the answer, and why improving the foundations of Internet infrastructure matters for everyone.
“Automation is only as good as the data you give it,” Funke explained. “We use a lot of information that is already publicly available to configure and operate services for our customers. When that information is incomplete, inconsistent or outdated, automation can stop — and a human must step in.”
Turning public data into network configuration
One example is the information required to establish BGP sessions. Inter.link uses data such as organization names, ASNs, IRR AS-SETs and prefix limits to automate configuration.
The process starts with data from PeeringDB, which Inter.link mirrors internally. That information is then normalized, stored in NetBox and used to generate configuration that is ultimately pushed to network devices.
For relatively straightforward information, this works well. But the further automation goes, the more edge cases emerge.
A key example is AS-SETs. If the same AS-SET name exists in multiple IRR databases, automation cannot reliably determine which dataset should be used. Instead of automatically deploying a BGP session, the process fails — requiring a network engineer to investigate and resolve the ambiguity.
Across thousands of BGP sessions, these exceptions add up.
The solution adopted by larger networks is often to maintain their own internal or “shadow” PeeringDB environment, with additional automation and validation layered on top. While effective, this approach is resource-intensive and is not realistic for every network.
If every network has to build its own workaround for the same public data problem, are we really solving the problem? Inter.link prefers to fix the foundation which means improving the shared data that networks and automation tools rely on.
Making network automation easier for everyone
Inter.link has proposed changes to PeeringDB that would make AS-SET information more predictable and automation-friendly, including ensuring AS-SETs are uniquely defined.
The goal is straightforward: if networks and automation tools can rely on consistent public data, fewer organizations need to build their own workarounds.
Stefan said, “The bigger networks may have the resources to build their own systems around these problems, but smaller operators often don’t. If we can improve the underlying data, everyone benefits.”
Prefix-limit information can also become more reliable. Networks publish IPv4 and IPv6 prefix limits in PeeringDB and Inter.link uses those values as safeguards when configuring BGP sessions. If the information becomes outdated, however, a legitimate session can potentially reach an incorrect limit and be shut down.
Because routing data is publicly observable through a range of sources, that information can be used to identify when published limits appear to be approaching reality — and prompt networks to review their records.
Making DDoS protection more automated
The same principle applies to security.
Remote Triggered Blackholing (RTBH) allows traffic destined for a particular route to be blackholed during an attack; however different networks can implement RTBH in different ways, including using different BGP communities.
Inter.link thinks that RTBH community information should be published in PeeringDB so that automation can significantly improve, thereby enabling better networks.
If the information is available through a common, machine-readable source, automation can retrieve the correct community and apply it when required — reducing manual intervention during potentially time-critical incidents.
Automation built on collaboration
Automation is a joint responsibility. It depends on shared data and improving that data requires networks to contribute rather than building their own workaround that brings limitations.
Inter.link is dedicated to fixing the core of a problem. That’s why Inter.link is encouraging network operators to contribute to the relevant PeeringDB discussions, share how they implement RTBH and, importantly, keep their PeeringDB records up to date.
“Keeping your records updated isn’t just about helping one network,” Stefan said. “Everyone benefits when the information the Internet relies on is accurate.”
The future of networking isn’t just about moving more traffic. It is about making the infrastructure that moves it smarter, more reliable, and easier to operate.
