Netflix leverages public geofeed data that conforms to the RFC 8805 specification for client IP geolocation purposes. Our partner ISPs can also specify the URL to a public geofeed in the Partner Portal to make it available to our systems.
What exactly is geolocation data used for?
Netflix uses IP geolocation data for basic operational purposes, including (but not limited to):
- Steering clients to the geographically closest OCA in the event that geolocation is the final tie-breaker in the BGP best path algorithm
- Presenting the appropriate regional catalog to our members (see: Netflix thinks I'm in a different country)
Advantages of maintaining a public geofeed
If you specify a public geofeed in the Partner Portal, we consider all valid prefix data in the geofeed CSV file to be the source of truth when we are geocoding client IP addresses in your network. In the absence of validated public geofeed data, we use a combination of third party and internal data for this purpose.
- Improved accuracy: Ingesting geolocation data from a public geofeed that is directly maintained by an ISP improves our ability to accurately geocode the client IP addresses in their network. ISPs understand their network and where client IPs are physically located better than anyone else.
- Quick turnaround for fixing geolocation issues: If an ISP's geofeed is the source of truth, they have more direct control over fixing any geolocation issues that may arise. Changes or fixes for geolocation information are ingested and reflected in our systems relatively quickly, vs. the length of time it may take for third party data sources to reflect these changes.
To specify a public geofeed or view your validation results:
- From the main menu in the Partner Portal, select Routes > Geofeed.
-
In the page that opens, click Edit and enter or modify the URL for your public geofeed in the Geofeed URL field.
After you have entered or modified the URL, our systems will fetch and validate the geofeed file and its contents. The results are displayed in a report at the bottom of the page. After the initial validation, we will continue to monitor and validate the file and its contents, as described below.
Validation of geofeed data
The report on the Geofeed page displays the current state of the geofeed that you specified. There are two basic levels of validation that we perform. Geofeeds (or prefixes with the geofeed) that do not currently meet these criteria cannot be ingested or refreshed in our system and will generate alerts as described below.
- RFC validity: Your geofeed file must remain publicly accessible at the URL you specified, and must comply with the RFC 8805 specification. If the file is not valid or accessible, we will pin to a previous version and generate an alert as described below.
-
Prefix validity: Assuming that your geofeed file is accessible and RFC valid, we then proceed to validate and ingest the contents of the geofeed file at a prefix level. We enforce the following requirements for each prefix. Prefixes that do not meet these criteria will be ignored and will generate an alert. Other prefixes that meet our criteria will be ingested as described below.
- We must be able to attribute ownership of the prefixes in your geofeed file to the ASN(s) that are associated with your organization.
- To ensure location accuracy, we require city-level granularity for each prefix. In addition, the city that you specify for each prefix must be located in the region and country that you specify.
- The location information in the geofeed should represent the physical location of each prefix.
- We currently only support geolocation via public geofeed for the following countries:
- United States
- Australia
- Brazil
- Canada
- France
- Germany
- Italy
- Japan
- Mexico
- South Korea
- Spain
- United Kingdom
Note: In addition to these validation checks, the geofeed report will highlight any valid prefixes that are included in your geofeed, but are not advertised via BGP to your OCAs or over peering connections. This will help you ensure that your BGP announcements and the prefixes in your geofeed are in sync. If you have not advertised some prefixes via BGP, we cannot use their geofeed data for steering purposes. You can view more information about your advertised prefixes in our Route tooling.
What happens if my geofeed file is invalid or inaccessible?
We attempt to fetch and re-validate the data in your geofeed file hourly, 7 days a week. The Partner Portal will reflect the current state of this validation and displays a timestamp to indicate when it was last checked.
We only ingest geofeed data into our systems (hourly) during the following limited time window:
Monday through Thursday: UTC 4pm - 10pm
We do not ingest geofeed data outside of these hours to ensure that our engineering teams are available to actively monitor and resolve any issues that may arise in our systems.
If your geofeed file is RFC invalid, is not accessible at the URL you provided, or contains validation errors, we will trigger operational alerts and notify your team. You will be notified about these issues just as we notify you for any other operational alert. You can always refer to the Operational Issues page and the Geofeed page to understand the current state of your geofeed and whether there are any active issues.
If your geofeed URL becomes temporarily inaccessible or RFC invalid, we will pin back to the last known good version that we successfully ingested. If your geofeed is inaccessible or RFC invalid for longer than 15 days, we will revert back to using third party and internal geolocation data. The Geofeed page displays information about whether we are pinning back to an earlier version, and when the data was last refreshed and validated.
Any prefixes contained in the file that do not meet our requirements will be ignored, and we will fall back to using third party and internal data to geocode these prefixes.
Note: We reserve the right to stop ingesting geofeed data for other reasons - for example, if we detect significant anomalies or widespread IP location shifts that indicate unintentional changes or potentially hijacked data. If this happens, we will reach out to partners to notify them.
More information
If you have any additional questions, feel free to open a ticket as described in: Creating and managing support tickets