BGP Peering: Why it's tricky to measure peerings?
Few days back a friend of mine (who works for an ISP) congratulated me for joining HE. Along with wishes he told me that our bgp.he.net doesn’t works well and the reason he fealt so is because he couldn’t see all peers for his ASN in our tool.
This is not a problem and to be more broader - same applies on all popular tools other then bgp.he.net like RIPE Stats, Robtex AS analysis etc. The reason many of these tools do not and cannot show all peers is because they show what they see from the point of collection. E.g right now I am on BSNL (AS9829).
Let’s do a trace to Google’s 8.8.8.8
Anurags-Macbook-Pro:~ anurag$ mtr -wrc 1 8.8.8.8
HOST: Anurags-Macbook-Pro.home Loss% Snt Last Avg Best Wrst StDev
1.|-- router.home 0.0% 1 0.9 0.9 0.9 0.9 0.0
2.|-- bsnl-wan-uplink.home 0.0% 1 1.9 1.9 1.9 1.9 0.0
3.|-- 117.206.176.1 0.0% 1 22.4 22.4 22.4 22.4 0.0
4.|-- 218.248.169.118 0.0% 1 28.5 28.5 28.5 28.5 0.0
5.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
6.|-- 72.14.218.234 0.0% 1 30.1 30.1 30.1 30.1 0.0
7.|-- 72.14.237.61 0.0% 1 32.8 32.8 32.8 32.8 0.0
8.|-- google-public-dns-a.google.com 0.0% 1 31.3 31.3 31.3 31.3 0.0
Anurags-Macbook-Pro:~ anurag$
Here hop 4 is BSNL, hop5 is dropping packets and hop 6 is Google. I can assume here BSNL is peering with Google i.e there’s a direct relationship between AS9829 and AS15169. If you look at bgp.he.net output (or any other similar tool) for BSNLs peers and Google’s peers you will not found them peering with each other. The way most of these services collect data is usually from collection point across the web. If they do not see any routes with AS_PATH as 9829 15169 OR 15169 9829, they will never know if these networks are peering. I am not aware of any collection servers running inside India specially inside BSNL network. From all outside points which would have a transit network of BSNL in between, there’s almost no chances of getting Google’s routes behind BSNL since BSNL is not a transit provider for Google. And same applies on Google as Google is not transit provider of BSNL either. Hence unless we have collection point on either inside network or BGP downstream of either network, we can never know if relationship exists.
Google has no downstream network since it is not a transit provider. Hence unless it agrees to share it’s routing full table with a collection point or any network, it’s not possible to know routes which Google learns from peers. (I usually do wild guessing by doing traces from a Google Cloud VM which runs inside AS15169 network. Probably same applies for Google fiber customers I guess). BSNL has few downstream customers and from any downstream customer which has full table from BSNL, it would be possible to find peerings of BSNL but unless one has access to such table in form of systematic MRT dumps, I guess most of services are just not aware of that part of table. But again that would be also limited to “best paths” which BSNL is choosing. So e.g BSNL might be learning Google directly from Google’s peering and indirectly say via any other network X. Now as long as BSNL prefers and installs only direct routes, it will announce those best routes to BGP downstream. Hence BGP downstream will see BSNL peering with Google but not the network X.
Same applies on Indian NIXI peerings as well. NIXI has only local Indian ISPs and hence since all are peering, the routing table exchanged at NIXI stays pretty much local except for cases of route leak. Hence you find AS24029 much across ASN related tools. Typically what is always visible on these tools is the upstream and downstream relationship of an ASN with other ASNs. While it’s relatively easy to find peerings of a large network since there is possibility of having collection point on it or it’s downstream.
Time to get back to work! :)