ASA-5585- How to police Netflix bandwidth for 1Mbps.

[tarnhundal]

Hi . We have ASA -5585-X. Lot of Netflix users are consuming bandwidth. 

How can we police Netflix on ASA. I don't want to block it but police it for 1 Mbps.

Please help. 

Thanks in advance,

Taran

[Vibhor Amrodia]

Hi,

Do you have any external module on this ASA unit ? Like CX etc.

Without these , you would not be able to police this traffic as the classification cannot be done by the ASA device for the Netflix traffic and hence the Policy would not work.

ASA device would be able to use the Regex to match this traffic but that cannot be used with the police command as it can only be used for layer 3 match policies.

For that , you need to check the layer 3 Ip addresses and see if you are able to identity some specific servers for this which is difficult.

Thanks and Regards,

Vibhor Amrodia

[m.kafka]

Hi Vibhor,

recommended reading:

https://supportforums.cisco.com/document/66011/using-hostnames-dns-access-lists-configuration-steps-caveats-and-troubleshooting

[m.kafka]

Suggestion:

Create a fqdn object matching all netflix domains (if there are multiple)

Create a class-map matching this object

Create a policy-map with the police action for this class

Configure the service-policy on an appropriate interface e.g. outside or inside

[Marvin Rhoads]

The problem with most widespread streaming services is that they almost all use Content Delivery Networks (CDNs). The actual content may come from any one of dozens of DNS names and that list changes month-to-month if not day-to-day.

While you can use ACLs with FQDNs and apply that in a class-map and police with a policy-map, it's a very inefficient approach. Plus as Magnus highlighted in his linked article:

FQDN functionality in ACLs is not a replacement for HTTP Filtering. It cannot distinguish what content is being sent.

The current generation of service modules (FirePOWER or the older CX) can do this much more dynamically and with more consistent outcomes. 

[m.kafka]

Hi Marvin,

Thanks for your thoughts! I had to look up the current situation. My idea worked up to 2011, before that date Netflix used two or three cdns with distinguishable DNS names (I found one list of 3 cdn DNS names in a scientific paper, discussing Netflix's caching and cdn architecture), before that (around 2007) they even used anycast (easy to catch with class maps). But this is all obsolete now.

Netflix changed it's cdn architecture in 2011 and is now offering caching servers to IPSs free of charge. According to technical details I have found (link to PDF) it means that ISPs can set aside one small prefix from their own address space (netflix allows even /31s) for Netflix caching and install the completely preconfigured server, called "OCA" in their network.

The OCA learns through a BGP-session from the ISP which prefixes from the ISPs address pool are allowed to connect to this specific OCA. The learned routes are only used to filter access to the streaming content, not for routing (routing is done with a preconfigured 0.0.0.0/0). The OCA connects to the Netflix cloud control plane and sends the list of allowed prefixes.

Clients (Netflix customers) are directed through this cloud control plane to the IP address of the most appropriate OCA.

Which means, today there's is little chance to catch Netflix traffic with high confidence as ISPs can add additional OCAs with new addresses and most likely no distinguishable DNS domain names.

I think it will be difficult for content filters to catch up with the constantly changing list of OCA IP-addresses unless Netflix publishes it on a regular basis.

So much for policing Netflix...

Best regards, MiKa

[tarnhundal]

Hi Marvin,

I am agree with you. I tried lot of other things. I tried regex but nothing worked. Netflix has many servers which offer streaming. So I tried to find those IPs what I could and created ACL to match those IPs and then bind with QOS. 

I have seen some improvement but not the satisfactory result. Even after we decided to drop whole Netflix traffic but still some of its traffic was leaking. 

Then I put DNS resolution of netflix to 127.1.1.1 and we found the desired result :-)

I came through some of Cisco docs mentioning without external modules/ CX we can't handle https in desired manner. 

Thanks,

Taran