[OpenIPMap] Geolocating remote peerings at IXPs

[Sebastian Pesman]

This issue happens aswell with IPv6 tunneling and VPN's. Though there is an
initiative to find such devices http://www.tracebox.org/ though that is far
from being applied to IPmap. The same is with virtual switches that can
move their IP from a datacenter in Rotterdam (NL) to their co-datacenter in
Amsterdam (NL). Or Anycast solutions, which might bring some new weirdness.

Not to excuse anything for OpenIPmap; at least it's a lot more detailed
then current "visual route" information. As this is something very new I
think we will run into more interessting situations.

On Mon, Apr 13, 2015 at 3:33 PM, Baptiste Jonglez <bjonglez at illyse.org>
wrote:

> On Mon, Apr 13, 2015 at 06:04:21AM -0700, Martin J. Levy 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.
> >
> > Isn't the previous hop (the inbound on the networks peering router) still
> > correct?
>
> You're completely right.  However, the link towards the following hop
> might be incorrect.
>
> Consider the four-hops path below, where the routers in Frankfurt and Lyon
> are connected by remote peering through AMS-IX:
>
> Berlin  -->  Frankfurt  --(through AMS-IX fabric)-->  Lyon  -->  Geneva
>
> Since the router in Lyon replies with its AMS-IX addresss, what you will
> get with OpenIPMap is either:
>
>   Berlin → Frankfurt → Amsterdam → Geneva
>
> or
>
>   Berlin → Frankfurt → Lyon → Geneva
>
> depending on where you geolocate the third router (either in Amsterdam
> according to its AMS-IX address, or in Lyon according to its physical
> location).  Both results are incorrect.  The "correct" path would be
>
>   Berlin → Frankfurt → Amsterdam → Lyon → Geneva
>
> but it has more hops (5 hops) than the original traceroute (4 hops)...
>
> Maybe edges could have an optional geolocation as well?  It seems a bit
> tricky to compute automatically, though.
>
>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/openipmap/attachments/20150413/9cf02020/attachment-0001.html>