Interesting Graph - How Accurate is the RIPE Routing Registry?
In the article Interesting Graph - How Complete is the RIPE Routing Registry we showed that for IPv4 95% of all organisations that receive an ASN from the RIPE NCC and that originate a route in BGP also register a route object in the RIPE Routing Registry. For route6 objects, the numbers were a little lower: 86% of ASNs that originate IPv6 routes in the routing system, also register route6 objects in the RIPE Routing Registry (RR). In 2007 this number was only 60%, and it has been steadily increasing over time.
We thought these numbers were encouraging. As a next step we were interested to find out how accurate the information really is. In how much does the data registered in the Routing Registry match the routing information found in the BGP routing tables.
In Figure 1, you can see the total number of IPv4 routes as seen in RIS (blue), the number of routes originated by RIPE NCC assigned ASNs (red) and of those the number of IPv4 routes in BGP that match route objects in the RIPE Routing Registry (yellow).
It is important to note that for this comparison we were rather strict on matching: if there is one origin AS seen in BGP, but the routing registry has two (or three!) route objects each with different AS, it counts as a mismatch; regardless of whether or not one of those would match BGP.
In Figure 2, we show the break-down of the various possible matches in more detail:
- total number of routes originated by RIPE NCC assigned ASNs (blue)
- total number of exact matches in the RIPE RR (red)
- number of routes that are match a more specific in the RR (yellow)
- number of routes that match less specific routes in the RR (green)
- number of mismatches (purple)
- number of routes not registered in the RIPE RR at all (orange)
As you can see, the number of mismatches is quite low. Most organisations register either the exact route or a number of less specific routes in the RIPE RR.
It is also interesting to note that the number of route objects in the RR that exactly match a route in BGP is very stable and growing steadily over time. The fluctuations in the total number of matching route objects is mostly caused by more specific routes in BGP that correspond to less specific route objects in the RIPE RR.
Figure 3 below shows the total number of IPv6 routes as seen in RIS (blue), the number of IPv6 routes originated by RIPE NCC assigned ASNs (red) and the number of route6 objects in the RIPE Routing Registry that matches those IPv6 routes (yellow).
In Figure 4, we show the various options of matches in more detail in the same way Figure 3 shows the for IPv4.
It is interesting to see that the number of exact matches for IPv6 route6 objects follow the total number of RIPE NCC assigned ASNs very closely whereas the number of less specific route6 objects in the RIPE RR is much lower compared to IPv4 route objects.
Also the number of mismatches is even lower than for IPv4 route objects.
Combined IPv4 and IPv6
In this last Figure, you can see the percentage of IPv4 route objects (blue) and IPv6 route6 objects (red) in the RIPE Routing Registry that match a BGP route in real life. This refers to any of the three possibilities of matching a BGP route in the RR:
- there's an exact match
- more specifics in the RIPE RR fully aggregate to the BGP route or
- a less specific in the RIPE RR covers the BGP route
In the latter two cases, the more and the less specific routes in the RR have the same origin(s) as in BGP.
For IPv4 route objects, the percentage is very high and stable for the last few years – between 85 and 90%. This means that almost all organisations that receive an ASN from the RIPE NCC and that originate a route in BGP have a matching route object registered in the RIPE Routing Registry.
For IPv6, the numbers are a little lower, but growing steadily over time and have now reached 80%.
The high number of matches between data in BGP and in the RIPE Routing Registry suggests that operators indeed use the RR for operational purposes. It would be interesting to see if not just the prefixes but also the routing policy matches, but that is more complicated and would require a different look at the data.