[OpenIPMap] Geolocating remote peerings at IXPs

Mon Apr 13 15:45:55 CEST 2015

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

answering multiple emails inline:

On 13/04/15 15:12, Sebastian Pesman wrote:
> As far as I know;
> 
> IP's are individually registerd / saved. It could be that is
> incorrect but then it can be corrected.

Geoloc info is saved based either on hostname or on IP range.
The UI only exposes the hostname-based saving, that's why you can't
geoloc an IP via the UI currently.
It should be relatively simple to add functionality to the UI to save
IP->location info directly. I created a github issue for this, hope to
get to it soon:
https://github.com/emileaben/django-openipmap/issues/10

> What also can happen is that someone uploads an IP range with a
> location, like your situation the assumption that all those IP's
> belong to Ams-ix therefore are geolocated in Amsterdam. If I'm
> correct it's like routing, the more specific information will
> overrule the the less-specific tagging.
> 
> Also, I'm not aware of any connections/relations between IX's IP
> blocks and OpenIPmap such as sites as peeringdb do.

I did a manual upload of all the IXP blocks I could find in peeringdb
early on in the project, so that's why you see these, and I also tried
to track major IP-range updates (like AMS-IX renumber).

Having these items periodically checked from peeringdb, but not
overriding crowdsourced information is what I'd want as functionality.

There are more crowdsourced geofeeds that I would like this to happen
for (ixmaps, opengeofeed ...)

> On Mon, Apr 13, 2015 at 3:04 PM, Martin J. Levy <mahtin at mahtin.com>
> wrote:
> 
>> Brilliant point; however as the IX is located where the IP
>> address is geolocated and the packet must go thru the location
>> where the IX is located; I'd say the lines aren't that wrong.

Indeed. In the Lyon case, Ideally we'd store 2 locations for this IP
(Lyons and Amsterdam) because we know if we see this IP we know that
the circuit the packet travelled contained both these locations.

I think there are 3 general cases:
a) 1 IP -> 1 location
b) 1 IP -> 2 locations (for when an IP corresponds to a circuit
between 2 locations).
c) 1 IP -> multiple locations. Anycast.

The b) case could actually be a sequence of locations, if you know the
physical path that the circuit takes.

These are indeed tricky to impossible to calculate automatically, but
for the IXP with remote peering an optional second location might be
good to have indeed.

cheers,
Emile

>> Isn't the previous hop (the inbound on the networks peering
>> router) still correct?
>> 
>> Martin
>> 
>> 
>> 
>> 
>> On Mon, Apr 13, 2015 at 5:17 AM, Baptiste Jonglez
>> <bjonglez at illyse.org> wrote:
>> 
>>> Hi,
>>> 
>>> How does OpenIPMap handle remote peerings at IXPs?  Currently,
>>> when an address is identified as belonging to an IXP (e.g.
>>> AMS-IX), it is geolocated at the location of the IXP (e.g.
>>> Amsterdam), and the UI doesn't allow users to change the
>>> location.
>>> 
>>> However, due to remote peerings, the actual router might be
>>> located somewhere completely different.  For instance, the
>>> following addresses: 80.249.211.136 and
>>> 2001:7f8:1:0:a500:19:8435:1 belong to the AMS-IX range, but the
>>> routers are physically located in Lyon, France (as indicated
>>> by latency + external knowledge).
>>> 
>>> Would it make sense to allow editing the location of addresses
>>> in IXP ranges?  There might be some issues when two routers
>>> doing remote peering appear as consecutive hops in a traceroute
>>> with their IXP addresses (unlikely, but maybe possible?).  In
>>> that case, the link on the map would indicate a direct
>>> connection between the two routers (e.g. Belfast and Lyon),
>>> while the actual link goes through the peering fabric (e.g. in 
>>> Amsterdam).
>>> 
>>> That being said, the problem is more general: the L2 link
>>> between any two neighbouring routers might take an arbitrary
>>> geographical path, but this is not taken into account by only
>>> geolocating routers.  But since it's difficult to have access
>>> to this information in general (IXPs are a special case where
>>> it's easier), that's probably ok.
>>> 
>>> Thanks, Baptiste
>>> 
>>> _______________________________________________ OpenIPMap
>>> mailing list OpenIPMap at ripe.net 
>>> https://www.ripe.net/mailman/listinfo/openipmap
>>> 
>>> 
>> 
>> _______________________________________________ OpenIPMap mailing
>> list OpenIPMap at ripe.net 
>> https://www.ripe.net/mailman/listinfo/openipmap
>> 
>> 
> 
> 
> 
> _______________________________________________ OpenIPMap mailing
> list OpenIPMap at ripe.net 
> https://www.ripe.net/mailman/listinfo/openipmap
> 

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

iQIcBAEBAgAGBQJVK8iQAAoJEKxthF6wloMOY/AP/3iVgxl0ryor3RaOsY/2uMH0
0xqNM4DzDb3CaCmZUP+VCb5B+5JNhI1qIivx0+0uBRGjWa03qBXfN3jhzuDv69Hn
nzrzxjRPZXVXhWZjDvZLA8/EgXzxDTb3t4WQC6uDMn1z8Dnuu2v3FbyEiFcEZM/7
6wHONf6cPTyK+J+gW34F4quS8bpOf/bBMbRRq/VWRnxsdpobDxrHZfQQoY+PxaJs
H2OHW3w5ELhZ+yxEEh60YtUMFGvY5osw7iN4RiidtfZOAWWMX9gKCo8z13aSbd5A
YwQEJ97gXe4cWxxO1x60rTXb2IwXfDOs62l5bzN7AqGGTMRL/pKD3PmhudBarxCW
ruPHz44ZLU8ShPmK4kYY00V3fsHZ6VjnOsEa+j3Fc2kONfb2VYnE0i2hDbdHqFAn
llW9eDmKPVx6FPzhJzDYRqzoIgYJMO7ocuSWmkEqc+76mBLrfSuzKkDSjL3+CF2j
fb5Mbrbg4JGbHB5CF1ho1DjvcLCX71e2tj2cgxIwZQa0gIgJ7EviwYrZ+TSm3OG2
WjAn1V3NlNNY6kAuWaJ2lQsOBidClndMRMuyd8Bsj0by09jTkR/B1HE3yAzKC32l
FyrlPZkhdXDrSrDZMP6hblhFigOTQxNOA5OKJcuKd/j4dIajGqLo0d3BXgJBhPAL
VJGK3ESXCJBnAMm63Bq/
=VzRB
-----END PGP SIGNATURE-----