Network automation depends on being able to trust the data behind it.
Stefan Funke, our Head of Network & Infrastructure recently explained 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.
Now he describes the challenges in greater detail and walks through what is needed to fix AS-SETs in PeeringDB.
What is the AS-SET?
Over the last year, you saw me and James going from event to event, telling everyone who wanted to hear, that we need some changes in PeeringDB.
The reason behind that is simple: if you register your ASN with PeeringDB, you need to enter a few values that help other networks keep up peering relationships with you. Among those is your AS-SET, which you use to describe your network. Think about it as if it was a phone book which translates a name to your AS number.
For example: our AS-SET is AS5405:AS-INTERDOTLINK. In it, we add all the other networks which you should expect behind us (downstreams) if you set up a peering session with us. If you look up AS5405:AS-INTERDOTLINK, you will get AS5405 as a member (that was obvious, ha!), and all our lovely and awesome customers, like Github, WaipuTV, Deepl or SpaceX.
Unreliable Data = An Automation Challenge
The problem with the AS-SET field in PeeringDB was that everyone could just enter any information whatsoever. PeeringDB is a community driven database, and every member/user SHOULD be able to enter whatever is right for their network. That did not change and is important. But with every free text field comes a big responsibility. While AS-đź’© might be filtered out, AS-IAMTHEGREATEST is not. There is no check which can and will make sure that the data you have entered is either valid or correct.
At Inter.link, we try to automate everything. If I had the choice, I would love to automate a little bot that brings me a coffee whenever I think about having a coffee. When it comes to our customers, automation should take over from the moment they sign up. You go to our portal, order your IP-Transit service, and enter your AS number.
And here it starts to get complicated. We use the data in PeeringDB to make decisions on how to configure your new service with us. Do you see the problem? Oh boy. It’s a garbage in, garbage out situation.
That’s why we fought for having good data in PeeringDB. While we still cannot guarantee that the data you put into PeeringDB is right, we can at least try to narrow it down as best as possible.
The internet is roughly divided in multiple regions, managed by Regional Internet Registries (RIR). If you create an AS-SET, it can have its origin at ARIN, RIPE, APNIC, LACNIC, or AFRINIC. If you decide to go with “AS-GENERICISP”, this name could be registered with any of those RIRs, so the name would not be unique. If our automation picks that up, we would have to make a guess what the best and right data source would be. There is a 1/5 chance that we might be right. For automation, this is not good enough.
What happens next with AS-SETs in PeeringDB?
We asked PeeringDB to change the AS-SET field to something that allows unambiguous values only, which requires networks to state the source of their AS-SET, using the format RIR::AS-SET. In our case, that would be RIPE::AS5405:AS-INTERDOTLINK.
The lovely people at PeeringDB worked hard to implement the new feature. With release 2.82.0 we finally made a big step towards having more reliable data for everyone in PeeringDB.
Now it is your turn: please log in to PeeringDB, update and check your record(s). And, if you are on it anyway, please update your AS-SET to the new format. With every update, you help companies like us and people like James and ME to make the internet a better place. Thanks to everyone involved!
