Hi Jon, Thanks for weighing in.
I asked about using /32 in the beginning of the post, but in the essence of why location matters, the /32 end in say Dallas is a gateway router and the /32 end in Charlotte is where the proverbial eyeballs are. Do we really need to be that granular to the host level for a router that will not make any CDN requests? A /31 seems close enough for all intents and purposes. I think following the geofeed RFCs should be sufficient, but at this point, I just need my customers to be able to watch NFL and MLB games they should be able to watch. However, as is the crux of this post, IPinfo ignores geofeeds when their probe ping times do not align. In their current setup, let's say I assigned a /32 as Charlotte in my geofeed today, the ping time of an IPinfo Charlotte probe is still way off from what they expect. They expect < 1ms if the /32 is truly in Charlotte but get 50ms and that "noise" just kicks it out. Their current solution offered to me is for me to host a probe at every customer site is not feasible. So while I agree that if we are splitting hairs, a /32 makes for a more granular location, it does not solve the problem that IPinfo has bad data solely due to basing geolocation on ping times. And the current IPinfo stance boasted about on their website is that when an ISPs geofeed doesn't align with their probe system, it must be wrong because their assumption is that all ISPs are liars. I am hopeful Ben and Abdullah will come to a solution on the matter very soon. The NFL season is ticking away. Mark On Thu, Oct 23, 2025 at 9:25 AM Jon Lewis <[email protected]> wrote: > On Wed, 22 Oct 2025, Mark Blackford via NANOG wrote: > > > Thank you Ben and Abdullah for joining the discussion. I understand the > > balance IPinfo has to make, but hopefully what I have explained to > Abdullah > > on LinkedIn and your support team about the nature of hub and spoke > > EVPL/NNI networks, point to point IP assignments in /31 ranges, and > > automatic geofeeds from IPAM product like Netbox helps clarify how your > > probes do not paint the whole Geo IP picture. > > > > For example from my support case, an IPinfo probe in Charlotte, NC sends > > data to my customer also Charlotte, but has to traverse Internet > providers > > to first get to my network hub in Dallas, and then make the trip over my > > EVPL/NNI back to my end user in Charlotte who is the one that > > needs accurate Geo IP location for content providers. I am sure this > ping > > time should be about twice the expected 25-30ms round trip latency > expected. > > > > Meanwhile, an IPinfo probe in Dallas pings the other end of the /31 with > < > > 1ms latency, which is just on a gateway on a router with no users, and > > simply concludes I am lying in the geofeed, the /31 must be in Dallas and > > not Charlotte. > > It sounds like your geofeed needs "higher resolution" if you want it to be > honest about where the IPs are in use. Instead of the /31s, break those > into /32s each at the appropriate location. > > Where I work currently, we've had quite a bit of difficulty both with > stale IP Geo data on end-user systems and IP Geo providers with stale data > for a former RIPE /16 $work purchased via a broker several years ago. > > Prior to this thread, I was unaware of ipinfo.io, and I was pleased to > see > on their website that they allow ISPs to "register" their geofeed...so I > did that last night. I also did test lookups (another welcome feature not > all IP Geo providers provide) and found that most of what I checked was > correct, but not all. I got an email early this morning thanking me for > sharing our feed. It'll be interesting to see if/how soon it corrects > their incorrect data. > > At a previous job, $work had a VPN division, and I know VPN was popular > for bypassing streaming service content restrictions based on IP Geo. We > actually did have a global network, and so we had VPN servers all around > the world. I can easily imagine a smaller VPN provider might lie in their > geofeed to try to trick IP Geo providers in essentially saying the VPN > provider has a wider footprint than they do (servers in countries where > they're really not). > > I hope that doesn't keep them from trusting a broadband ISP's geofeed. > We don't provide VPN (other than for staff to be able to work) and depend > on accurate IP Geo data so that our customers get the right local channel > lineups from streaming TV services and don't get blocked from websites > that have decided to block access from "abroad". > > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Blue Stream Fiber, Sr. Neteng | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/S5A2JXBMGTNAFGQ46TMBTT244ZW3E4LB/
