Isolario is a not-for-profit, real-time BGP route collecting research project developed at the IIT-CNR of Pisa, Italy. Its aim is to improve the knowledge about the AS-level ecosystem of the Internet by increasing the amount of ASes from which BGP data is collected.
To do this, Isolario offers network operators free-of-charge services based on the real-time analysis of inter-domain routing from different points of view in return for BGP full routing tables to be publicly shared, thus following the do-ut-des principle.
A commutative contract whereby something is given so that something may be received in return. The Latin translation is “I give that you may give”.
What is a route collector?
BGP route collectors deployed by Route Views, RIS, PCH and Internet2 have been invaluable sources of information for researchers for over 20 years.
Data collected from these projects helps to piece together information that was lost the day after the National Science Foundation’s privatisation in 1995 when regional networks started to buy national-scale Internet connectivity from private long-haul networks.
Route collectors are nothing more than simple servers that mimic the role of border routers that establish BGP sessions with several organizations.
As opposed to real routers, BGP route collectors do not generate any routing traffic – they only collect incoming BGP messages without generating any routing traffic directed to the other party. Therefore, they are able to receive – in real-time – the best routes chosen by the BGP decision process of the connected router.
This data collected allows operators to study the routing characteristics of the connected ASes and further their understanding of the Internet inter-domain ecosystem.
Why Isolario?
The potential use of route collector data is limited by the small amount of ASes sharing their routing information and by the nature of these ASes, typically provider-free and worldwide ISPs. As a consequence, data collected by these projects could lead to biased results, depending on the analysis carried out. For example, they fail to reveal the largest part of the peering ecosystem.
We believe this occurs because these projects rely on voluntarily provided data. In our opinion, most of the largest ISPs are attracted by the opportunity to exhibit their interconnections to potential customers, while the administrators of the smallest organizations may not find any strong motivation to join a route collecting project. This means that the current view of the Internet inter-domain ecosystem is skewed toward large ISPs rather than being a representative view of all the Internet players.
Since an AS should not announce routes learned from a peer to another peer or provider (to avoid being used unwillingly as a transit) BGP data collected mostly from the top level of the Internet will not be able to see any the largest part of routes crossing peer-to-peer BGP sessions (see figure below).
To overcome this skew and the lack of routing information, we developed Isolario. As mentioned, it is based on the do-ut-des paradigm, where we tried to introduce services with a direct outcome (do) in change of (ut) full route BGP sessions from AS administrators (des) with the final objective to improve the public knowledge of the Internet AS-level ecosystem.
How does it work?
Isolario is a distributed system devised to collect, parse and elaborate BGP data sent from the routers of its participants (feeders) and to provide results to network administrators of participating ASes (Isolario users) by introducing the minimum amount of delay as possible.
The starting point to implement real-time services is a slight modification of the classic concept of a route collector. BGP data that arrives from a feeder to an Isolario route collector is sent to a collector daemon — responsible for maintaining the BGP session with the feeder — and to the real-time service modules. The collector daemon, called Interactive Collector Engine (ICE) is very important because it must be able to maintain an updated routing table per feeder and answer any incoming query from real-time services, to guarantee the best user experience for Isolario users. For example, a service may want to retrieve on the fly the set of routes that a particular feeder announced to Isolario in order to reach a portion of IP space of interest.
Partial results computed by each RC are sent to a central core, which will perform aggregated statistics to produce the final result to be presented to the user. Computed results are finally sent to Isolario users through a web-server, meaning that Isolario services can be accessed from any common browser via the Isolario website. The client-server communication uses the WebSocket protocol, automatically displays new results without any need for the client to poll the web-server.
Each component is designed to be modular and scalable to allow users to introduce new equipment in a plug-and-play fashion without affecting user experience. In addition, components are interconnected via TCP to allow for different parts of the system to be deployed in different parts of the world.
Which services are available?
The most important parts of the system are the services built on top of the architecture. Services are the do part of the do-ut-des principle of Isolario, and are the key to attract new users. Most of the services are devised to ease the direct troubleshoot of the inter-domain routers behaviour.
Currently, every Isolario user can use the following real-time services:
- BGP Flow Viewer (BFV), which provides Isolario users with UPDATE messages that the Isolario route collector is receiving from their routes, with a particular focus on flapping routes;
- Routing Table Viewer (RTV), which allows Isolario users to analyse and monitor the evolution of portions of the routing table announced by their router, i.e. the best routes identified by the BGP decision process of the router;
- Website Reachability (WR), which allows Isolario users to analyse and monitor the evolution of portions of the routing table hosting the websites of interest;
- Subnet Reachability (SR), which allows Isolario users to analyse and monitor the evolution of portions of the routing table from every single Isolario feeder;
- Alerter, which allows Isolario users to set up different triggers on incoming BGP packets, for example triggers on packets containing a particular set of BGP attributes or packets carrying a non-legitimate announcement of a network.
These services are free for each Isolario user as soon as the sessions are up. We also provide users with a set of analyses performed on the BGP data collected each day from every BGP project available, including Route Views, RIS, PCH, Internet2 and Isolario.
In particular, we provide a completely customizable document about the routing table announced towards Isolario from its routers filled with stats and details, and a document totally dedicated to the external reachability of its AS, again filled with stats and details.
Every interested network administrator can have a taste of the above services before joining. Just go on our website and access with guest/guest credentials. Beware, every service will be available for 10 minutes only!
How to join
Joining Isolario is easy; all we require is you open one or more multi-hop BGP sessions towards our BGP route collectors, following the guidelines on our website.
The only strict requirement is you should treat Isolario as a normal customer, thus announcing us your full v4 (and v6, if available) routing table. We won’t use received BGP packets to route anything back to you, but only to implement our services.
Data collected will be publicly available on our website in MRT format the same way Route Views and RIS are doing, in order to ease the analysis from existing tools.
Co-authored by Alessandro Improta
Luca Sani is a researcher at the Institute of Informatics and Telematics (IIT) at the Italian National Research Council (CNR) in Pisa, Italy. His research interests are in Internet mapping, monitoring and analysis.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.