Welcome to the Netflix Partner Help Center. Have a question or need help with an issue? Send us a ticket and we'll help you to a resolution.

CGNAT has multiple flavors; some of them are compatible with OCAs, some are not. This article provides guidance on how to configure your embedded OCA environment in a CGNAT context so that traffic can be served.

In this article:

General requirements for CGNAT

  • RFC1918 and RFC6598 prefixes announced to OCAs are filtered and therefore cannot be used to steer traffic to privately-addressed end users.
  • OCAs must be assigned a publicly-routable IPv4 address, as described in the router interface configuration section of the Network configuration article. OCAs cannot have their IP interface addressed with an RFC1918 or RFC6598 IP (100.64.0.0/10), even if this IP has a 1-to-1 NAT equivalent from the outside.
  • All CGNAT prefixes will be served from whatever internet-routable prefix they are behind. Therefore, all relevant CGNAT public IP ranges must be advertised to your OCA(s) via BGP for steering purposes.
  • If you have a CGNAT prefix that is not being served, then you likely have a misconfiguration of your CGNAT, or a routing problem inside your network. For some troubleshooting steps, see: Troubleshooting customer streaming issues

Supported Scenario 1 - "CGNAT inline"

In this scenario, client traffic passes through CGNAT when communicating with our supporting services in AWS, and also when communicating with the embedded OCA(s). Public IP ranges assigned to CGNAT are advertised to the OCA, and these public IP ranges are used for steering.

As described above, the OCA must be assigned a publicly-routable IP address.

CGNAT_scenarios_-_inline.jpeg

Supported Scenario 2 - "CGNAT bypass"

In this scenario, client traffic passes through CGNAT when communicating with our supporting services in AWS. However, communication between clients and the OCA bypasses CGNAT. To enable this OCA-to-client communication, the network must be configured to allow direct communication between the OCA and the clients.

Public IP ranges assigned to CGNAT are advertised to the OCA, and these public IP ranges are used for steering. After steering decisions are made, the OCA communicates with each client via the client's private IP address.

The OCA does not need to receive the private IP routes via BGP, however you must ensure that the privately-addressed clients have a route to the OCA via their default gateway, and that the OCA has a return path/route to the privately-addressed clients via its gateway, therefore bypassing CGNAT.

As described above, the OCA must be assigned a publicly-routable IP address.

CGNAT_scenarios_-_bypass.jpeg

FAQs

Do I need to notify Netflix that I am using CGNAT?

No. As long as you are following the guidance in this article, your CGNAT environment should work seamlessly. You do not need to notify Netflix, mark communities, or take any additional steps. If you have questions about unexpected traffic patterns, you can always open a ticket for assistance.

How do I know that my CGNAT configuration is working?

You should see all of the public IP ranges that you have advertised to your OCAs in the Route Explorer, and you should see traffic being served by your OCAs. If you need assistance, open a ticket.

Can I see metrics and data for my private IP space in the Partner Portal?

No. Metrics, data, and the route tooling in the Partner Portal are only available at the level of the public IP ranges that are advertised to your embedded OCAs for steering. We are not able to provide metrics and data at the level of the private IP ranges that are behind CGNAT.

Is there any plan to support the advertisement of private IP space via BGP in the future?

No. As described above, we only use public IP ranges for steering. Therefore, we do not support BGP advertisements to private IP ranges and there is no plan to do so in the future.

Will you continue to support CGNAT?

Yes. We fully support IPv6 and we recommend that partners support IPv6 whenever possible. We do not plan to provide additional CGNAT support in our tooling or via BGP. However, we do plan to continue to support the CGNAT scenarios that are described in this article.

 

Was this article helpful?
2 out of 3 found this helpful