Whether it’s after a long day at work, a rainy weekend, or when a new season of your favorite TV show is released, we’ve all been on a Netflix bender (*cough* Stranger Things *cough*). What we probably don’t think about is how all of that content is being delivered and what a burden that puts onto our ISPs. If you’re in the ISP industry, don’t worry—Netflix has the solution in Netflix Open Connect!
Netflix Open Connect is their globally distributed CDN. It delivers 100% of their video traffic or over 125 million hours daily. This translates to tens of terabits per second of simultaneous peak traffic. If you’re in the ISP industry, you know all too well how costly this can be for your WAN uplinks in order to provide the best end user experience.
Traditionally, most ISPs will peer with Netflix at IXP locations, but to make life easier, Netflix also provides an OCA (Open Connect Appliance) to host locally. There are a few requirements in order to be eligible, found here. In this blog I want to focus on one requirement in particular: traffic volume. Netflix requires you to have a minimum of 5Gbps of peak traffic to qualify for an OCA. In Scrutinizer it’s easy to isolate Netflix traffic and verify your volume at peak hours, as well as trend these statistics long term. Let’s jump in!
Method One: NBAR
In this first method of isolating Netflix traffic, I’ll use Cisco’s NBAR (Network-Based Application Recognition) exports, which is Cisco’s proprietary layer 7 export. In this example, I can simply isolate one of our NBAR-exporting Cisco devices and filter on only Netflix traffic:
You’ll notice in the report above that I have a complete bandwidth statement (as a rate or total) and I can also easily adjust my timeframe to reflect peak business hours. One report, one filter, and I have all the data I need to apply for my Netflix OCA!
Method Two: URL Exports
In this example, I’ll use URL information exported via a SonicWALL, but the same results can be achieved with a Gigamon appliance or a probe that exports URL information. I’ll select my SonicWALL device and isolate the WAN interface. From here I’ll add a filter to isolate only our traffic with a URL like Netflix:
Since we collect all of the metadata, I’m not restricted to only viewing the URLs and the bandwidth statement. I can also view this same data in the traditional Source > Common Port > Destination view like below:
As you can see above, that’s my workstation reaching out to two of Netflix’s Cloud OCAs via our ISP’s peering setup.
Method Three: Autonomous System by IP
In this example, I’ll use Netflix’s Autonomous System by IP to isolate their traffic going across our network. Similar to our last three examples, I’ll begin by choosing one of my edge devices (SonicWALL in my case, but vendor doesn’t matter). Now I’ll build two reports: one isolating Netflix AS as a source and the second as a destination:
Method Four: Defining Applications
The first four examples focused on unique exports being collected, but in the final example I want to look at how the same results can be accomplished without using anything vendor proprietary. In Scrutinizer, applications can be defined based on IP space and a port/protocol. To begin, I’ll define the Netflix application:
As you might guess, this can become tedious depending on the number of IPs in play. You can simplify the process by using IP ranges versus individual addresses. Scrutinizer can also simplify this with the use our RESTful API.
Once the application is defined, I’ll follow a similar process to build a report on an edge device, filtering on our defined application of Netflix:
As you can see, it’s incredibly easy to isolate Netflix traffic in your environment and begin building the use case to bring a Netflix Open Connect Appliance in house. Netflix also has the full list of requirements on their site, which I recommend reviewing.