Use the Route Optimizer tool in the Partner Portal to run reports on your BGP route announcements. You can:
- Compare BGP route announcements from different sources to discover patterns that may result in suboptimal traffic routing.
- Discover embedded routes with no alternate source
- Discover unregistered routes that appear to be advertised or propagated beyond their intended scope
- Discover embedded routes that Netflix is filtering from its steering algorithms
The Route Optimizer reports include all announcements that Netflix hears from your ASN(s), including at peering and embedded sites.
For general information about BGP best practices, see the routing and steering information in the related article: Network configuration
Running the reports
- Open Routes > Route Optimizer from the main menu.
- Select the type of report that you want to run:
- Select Compare Routes to compare announcements between different transport types and return a list of potentially suboptimal announcements. Then, select the comparisons that you are interested in.
Note: "Other" routes are routes announced by your organization towards upstream providers, which Netflix is hearing at other peering sites via another ASN that is not owned by your organization.
Tip: If you want to look at all issues for a single prefix across all sites where it is advertised, select all of the comparisons and then sort the results by prefix.
- Select Discover Routes with no Alternate Source to return a list of prefixes that are announced to OCAs in your embedded sites, but are not announced to any backup peering or transit traffic sources.
- Select Discover Unregistered (RIR) Routes to return a list of prefixes that appear to be advertised or propagated beyond their intended scope.
- Select View Filtered Embedded Routes to return a list of embedded routes that Netflix is filtering from its steering algorithms.
- To exclude routes from the results of any report that have not had Netflix traffic on them within the last 7 days, select Show only routes with traffic.
- Select Compare Routes to compare announcements between different transport types and return a list of potentially suboptimal announcements. Then, select the comparisons that you are interested in.
- Select other options, then click Show to run the report and display the results.
- Use the Filter field to limit results, and click CSV to export the full results to a CSV file for further offline analysis.
Interpreting the results and fixing issues
Compare Routes
Each row in the results represents a situation where routes have potentially been announced sub-optimally. Whether these conditions actually cause any issues with traffic patterns will depend on your particular network environment and which prefixes are being used to serve Netflix clients.
To determine whether traffic is actually being served from less-preferred sources, look at the Traffic by AS Path report to view high level traffic patterns. If you see unexpected patterns in the Traffic by AS Path report, the route comparisons in the Route Optimizer tool can help you dig deeper into BGP announcement patterns that could be improved.
In the Results grid, the columns on the left represent a typically less optimal transport type that will be preferred by our steering algorithms as a primary source, all other conditions being equal. On the right, the columns represent what is typically a more optimal transport type, however the routes are being advertised such that traffic is not likely to be steered to it as a primary source.
The results that are returned are in one of two categories:
- Prefixes that are announced more specifically to a less optimal source (for example: Peering or Other sources are preferred over Embedded sites)
- Optionally: Prefixes that are announced to the less optimal source, but not announced (labeled as Missing) to the more optimal source. Note: You can filter these out of the results using the report options.
In either case, the results highlight situations that could potentially cause Netflix traffic for each prefix to be routed to a less optimal source.
Tip: As mentioned above, you can select Show only routes with traffic to limit the results to routes that have had Netflix traffic on them during the last 7 days. Regardless of whether you select this option, the results in the grid are sorted by the 7-day maximum traffic value for each prefix. This can help you prioritize your troubleshooting efforts.
The values that are currently causing each route to be preferred by the less optimal transport type are circled in the results grid. You could fix the issue by changing either value. The goal is to display a potential fix for each issue. However, again, the ultimate fix will depend on your individual network environment.
For example, consider the following "PNI peering vs Embedded" comparison. Peering is typically a less optimal transport type and we would prefer to serve traffic from more local Embedded sources. You might see a row in the results that looks similar to this:
In this case, the prefix lengths and AS Path lengths are the same, but the advertisement to PNI peering has a lower MED value. Therefore (again, all other conditions being equal,) our BGP best path selection criteria will steer traffic on this prefix to the PNI peering site over the embedded site. In most cases, we want to serve as much traffic as possible from the embedded sites, so we show this result in the report as a potential optimization opportunity.
You could fix this particular situation by either increasing the MED value at the peering site or decreasing the MED value at the embedded site.
As another example, consider the following "Other vs. PNI peering" comparison.
In this case, there are some prefixes that are advertised more specifically to "Other" sources vs. at the PNI peering site. In most cases, it is more optimal to serve traffic from the PNI site, so we show these results as another potential optimization opportunity.
Note: In the second row, there are actually 21 similar prefixes that fall into the "Other" category, so the prefix shows a count next to it. Assuming this situation is an actual issue for your particular network, you would want to investigate and correct all instances of the prefix.
Discover Embedded Routes with no Alternate Source
When prefixes are only advertised to embedded OCAs and there is no identified backup traffic source, Netflix member devices within the prefix may experience content availability issues (client streaming errors) as well as general reliability issues. Because embedded sites do not typically store copies of every title, less popular content (not stored within the embedded site) that is requested from a client device will need to be served from a backup source. If no backup transit or peering source has been advertised, the customer will see an error when they try to access the title.
If there are routes returned in this report:
- If the prefixes are no longer in use in your network, remove the advertisements from the embedded OCAs.
- If there is a need to serve Netflix traffic to client IPs within the prefix, advertise a less-preferred route to an alternative traffic source (peering, Other/transit).
Discover Unregistered (RIR) Routes
This report returns routes that are advertised to your embedded OCAs that are flagged by our systems as potential leaks. These routes are suspected to have been advertised or propagated beyond their intentional scope. This situation can occur due to an accidental misconfiguration or because relationships between ASNs are not properly documented using an AS-SET.
If there are routes returned by this report:
- If you have an established relationship between your ASN(s) and the owning ASN(s), ensure that it is properly documented via an AS-SET as described in the article above.
- If the routes were advertised to your OCAs unintentionally, withdraw the advertisements.
View Filtered Embedded Routes
There are various situations where Netflix rejects routes and filters them out of our steering algorithms. This report returns prefixes that we are rejecting and the reasons for rejecting them. Although it is not critical to fix these issues because we are already rejecting the routes, as a best practice they should be corrected.
Important: The Route Optimizer report currently does not identify filtered routes that are announced on peering or transit sessions. The results you see in this report represent routes that we are filtering from embedded sessions only.
Reasons include:
- RPKI: Violation of our RPKI validation rules
- Route origin ASN does not match any of the authorized origins for the prefix.
- Tier 1: Unexpected Tier 1 ASN in the AS Path
- When we peer with a non-Tier-1 transit provider (someone who pays other providers for transit), seeing Tier 1 ASNs on the AS path indicates a route leak.
- Manually filtered: Filtered for another reason
- This reason is typically associated with unregistered routes that appear to be advertised beyond their intended scope.