[OpenIPMap] Geolocating remote peerings at IXPs

Mon Apr 13 22:10:54 CEST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/04/15 18:58, Baptiste Jonglez wrote:

> This sounds like a nice solution to the original issue, thanks!
> There is a special case when an address is the target of a
> traceroute, though: it might be reached without going through the
> circuit.
> 
> Consider the following topology, with a remote peering to
> explicitate the point:
> 
> R1  ---  IXP  --(remote peering)--  R3  ---  R4
> 
> When R3's IXP address appears in the middle of a traceroute, it
> means that the packet has travelled the (IXP → R3) circuit.
> However, if R3's IXP address is the *target* of a traceroute, the
> packet might or might not have travelled the circuit:
> 
> (R1 → IXP → R3) has travelled the circuit
> 
> (R4 → R3) has not travelled the circuit
> 
> I don't see a way to distinguish between the two cases, though
> (except using latency, but this is hard to automate).

Yes, hadn't thought of that initially, but I think you can distinguish
between them simply because of the target of the traceroute is either
R3 or not.

Actually looking into ams-ix peering LAN remote peering I found this
interesting one from Curacao telecom (80.249.210.252)

measurement from NCC office in Amsterdam to 80.249.210.252:

## msm_id:1957122 prb_id:6019 dst:80.249.210.252 ts:2015-04-13
14:14:24 -00:00
1 err:{u'x': u'*'}
2 (AS3333) gw.transit.telrtr.ripe.net [0.665, 0.734, 0.796]
|Amsterdam,North Holland,NL|
3 (AS1200) 80.249.210.252 [220.954, 221.094, 221.126] |Amsterdam,North
Holland,NL|

measurement from a probe in Curacao:

## msm_id:1957121 prb_id:3544 dst:80.249.210.252 ts:2015-04-13
14:09:44 -00:00
1 () 10.0.1.1 [1.588, 1.623, 16.153] ||
2 () 172.30.0.1 [7.329, 7.595] ||
2 () 172.30.0.143 [1.416, 1.418] ||
3 () 172.30.0.1 [3.622, 3.733] ||
4 (AS52233) xe-5-2-0.an.ecp-edge02.columbuscuracao.com [19.6, 45.382,
60.389] ||
5 (AS1200) 80.249.210.252 [27.198, 48.735, 76.312] |Amsterdam,North
Holland,NL|
5 (AS52233) xe-5-2-0.an.ecp-edge02.columbuscuracao.com [17.661,
42.385, 69.92] ||
6 (AS1200) 80.249.210.252 [13.188, 14.943, 45.972, 47.71, 55.282,
57.169] |Amsterdam,North Holland,NL|

In this case the geoloc (Amsterdam) is obviously wrong. Impossible to
get from Curacao to Amsterdam in 13 ms . Physical distance is ~7800km
, so should be at least 78ms, for light in fibre.

So to be completely (pedantically?) correct, the remote peering case
should probably have the remote location as a primary location (in
this case Curacao), if we only store a single location. For
traceroutes that have a remote-peering-IP as an intermediate hop, the
peering-lan location is very likely a secondary location (Amsterdam)
that the packets travel through before/or after the primary location.

For now I've fixed the geoloc for this particular IP in the database
(by using the bulk upload feature), as well as for your Lyon remote
peering IP addresses.

cheers,
Emile

> 
> Thanks, Baptiste
> 
> 
> 
> _______________________________________________ OpenIPMap mailing
> list OpenIPMap at ripe.net 
> https://www.ripe.net/mailman/listinfo/openipmap
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVLCLMAAoJEKxthF6wloMOs9EP/R2gRTrYAwaTI19zogmKNKX6
H7VDqtB9ITMrJSkLZEwRSKmYr02YVUl+hzkdradb8iEKHIhNmW0YWmkmTB9qRJ7p
cd6YbZEcnlfVpC9FisrutCyB53UtGOEBeQsK8jjd6AT4NoY3WNTk4D3gECEPkYxA
gRUpGbYe0NhBzScjrwWVOGYQP7Dez4GQC7jytKnaXaDXRO9NjIb5miXQ6q4ALy8g
hEXfnN5o7DF8zPusYu7k5XdCVZdGl/lU4bP9TBrzg060uB15SdVAZ+Wyld53UGde
B93s3Cl1HiLE+xHy4RJokNTmECuICyN9ZIenajCYb099PhzIUom5AvJTsDlgryja
nfEUZ+0gw9g2DmEBWLTF37MnE07eG6oSzjkBPEb1DKViLkPl5cKYAYiVVALzcUbD
c1+boRAFiGltHCiJw8eg2Y8OFf2OTurwvv93UfuhOINmyJMikwucxBg6qHKEuwHT
hZ0B5Ir/6gUoA+DezD2YzwWRJMaxVwAF/l1dWZOsM2ihCLsVKDkpvQAYUshrwydD
Z+7cJQI6pdJr6J56HWV1CUt0liVbahYeFDQ/zua1haj/EVAeEDgVF1nJskpG2Ewv
K36nvAtmxEjOQOZrq6i2U7divR6b+rs7uivSrDa6EoIRYcBsI5m27q1sNFtV1dlc
HhJdE7VeX+bhdsoGjbb9
=og27
-----END PGP SIGNATURE-----