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.

English version: Network configuration

Esta sección describe la configuración de los dispositivos Open Connect (OCA, Open Connect Appliance). Si usted es un proveedor de servicios de internet (ISP, Internet Service Provider) socio de Open Connect, Netflix trabajará con usted para determinar la configuración óptima en base a sus necesidades.

Para más información, visite la página de Preguntas frecuentes.

Descripción General

Los OCAs son dispositivos dirigidos (directed cache appliances), esto quiere decir que la manera como el tráfico es dirigido al dispositivo es determinado por usted y Netflix, no por el dispositivo en sí.

Un OCA solo atiende a usuarios en las direcciones IP que usted anuncia hacia el, a través de una sesión BGP.  El tráfico solo se entrega desde sus OCAs a los prefijos anunciados específicamente por usted. Por lo tanto, usted—como nuestro socio—tiene el control sobre la red atendida por los dispositivos. Las sesiones BGP son establecidas entre el dispositivo(s) y el router más cercano.

Si el contenido que solicita un usuario no se encuentra alojado en su OCA, el pedido se dirige al sitio de contenido de Netflix más cercano, ya sea vía un acuerdo de interconexión o peering (si está disponible) o vía tránsito.

Re-Configuración de la dirección IP en un OCA

Cada dispositivo viene completamente configurado con la información proporcionada por usted en el cuestionario de sitio.

El artículo, Actualización de la dirección IP en un OCA, detalla paso a paso cómo cambiar la dirección IP en el dispositivo.

Configuración de las interfaces del router 

Cuando esté conectado el/ los dispositivo (s) OCAs  a su router, siga esta sección. También puede ver el artículo, Ejemplos de configuraciones de router.

  • Cada OCA debe tener asignado una dirección IPv4 pública. Recomendamos también asignar una dirección IPv6.
  • Usted puede asignar una dirección IPv4 de una subred  /31 o mayor, o de una IPv6 /127 o mayor.
  • Es aceptable asignar una dirección de una subred más grande (por ejemplo, /24). Sin embargo, como solamente se requiere una dirección IPv4 por dispositivo, normalmente se usa una subred más pequeña
  • Las interfaces del router deben ser configuradas en grupos de adición de enlaces (LAG Link Aggregation) con el protocolo de control de adición de enlaces LACP. Como se muestra en el siguiente diagrama, cada servidor debe ser configurado en su propio grupo LAG. En el caso de tener dos servidores, hay dos LAG diferentes, uno por cada servidor.

server-lag-config.png

  • Cada interfaz debe tener configurada la unidad máxima de transmisión estándar (MTU) Los jumbo frames no son compatibles.
  • En caso haya múltiples routers disponibles en un sitio para proporcionar redundancia, se recomienda alternar los dispositivos entre routers. Los dispositivos conectados a un mismo router deben estar en la misma subred para optimizar el proceso de llenado. Los dispositivos conectados a routers separados deben estar en diferentes subredes. Los dispositivos no están diseñados para estar conectados a dos routers separados.
  • Todos los puertos en el OCA deben estar conectados al mismo router o switch. No se recomienda multi-chassis LAG o switch stacking.
  • Cada OCA está protegido contra ataques y está diseñado para ser conectado directamente al internet. Filtrar el tráfico de entrada o de salida, puede causar problemas operacionales, debido a eso recomendamos encarecidamente autorizar todo tipo de tráfico en todos los puertos, no usar ACLs, y asegurarse que su router tenga una ruta predeterminada o una tabla de enrutamiento completa. En caso usted requiera aplicar filtros, a continuación se presenta un lista de uso de salida y entrada. Por favor tenga en cuenta que esto puede cambiar en cualquier momento sin notificación previa.
    • Tráfico desde el OCA: Permita todas las direcciones y puertos de destino
    • Tráfico hacia el OCA: Permita TCP 22, 53, 80, 179, 443, UDP 53 y 123 (origen y destino), ICMP tipo 0, 3, 8, 11, y ICMPv6 desde cualquier IP/puerto público. Permita todo el tráfico de retorno desde cualquier conexión iniciada por el dispositivo (TCP establecido).
    • Nota: En el Portal de Socios (Partner Portal) puede confirmar el status de conectividad entrante/saliente del dispositivo.
  • Cada interfaz debe recibir entre 0 dBm y -10 dBm de luz para asegurar un buen flujo de datos. El panel LCD en la parte frontal del dispositivo muestra los niveles de luz de cada interfaz. Si su dispositivo no tiene un panel LCD, puede acceder a la consola con un teclado y mouse.

Enrutamiento y direccionamiento del contenido vía anuncios BGP

Nuestros usuarios son dirigidos hacia los OCAs en base a los anuncios BGP de un ISP, en conjunto con los algoritmos de enrutamiento y direccionamiento en el plano de control de Open Connect. Los socios pueden controlar algunos aspectos del direccionamiento del contenido a través de las rutas BGP anunciadas vía peering o a cada una de las OCAs integradas en su red.

El plano de control dirige a los usuarios al mejor OCA disponible utilizando una versión modificada de la selección de la mejor ruta de BGP. Asumiendo que el dispositivo posee el título solicitado y capacidad de servicio disponible, el plano de control provee a los usuarios una lista de los dispositivos (usualmente 3 o más fuentes confiables) de donde transmitir el contenido.

Criterios de selección de dispositivo

Los siguientes criterios de selección de dispositivo son considerados, en orden, por el plano de control de Open Connect. Si hay un empate por un criterio dado, se considera el siguiente criterio. Si hay un empate en todos los criterios, el tráfico se balancea entre los dispositivos.

  1. El dispositivo que recibe la ruta más específica hacia el prefijo del usuario.
  2. El dispositivo que recibe la ruta hacia el netblock (o rango de direcciones IP consecutivas) del usuario con la ruta AS más corta. (Ver abajo las notas sobre peering).
  3. El dispositivo que recibe la ruta hacia el netblock del usuario con el MED más bajo (MED, multi-exit discriminator). (Ver Notas Adicionales acerca de MEDs)
  4. El dispositivo ubicado geográficamente más cercano*. La geolocalización se basa en el IP del usuario, cuya ubicación se compara con la latitud y longitud de los dispositivos cercanos para determinar el sistema disponible más cercano.

*Nota: Si usted tiene dos sitios redundantes que están bien conectados, y están diseñados a servir el mismo grupo de clientes (con los mismos prefijos anunciados en ambos sitios), es posible para Netflix establecer un geo override (anular el criterio de geolocalización) de ese modo el tráfico se equilibra igualmente entre los dos sitios. Si usted cuenta con una situación como la descrita, puede abrir un ticket para pedir un geo override.

Notas adicionales acerca de MEDs

  • Los valores MED que recibimos se respetan. Sin embargo, los valores se incrementan dependiendo de donde están ubicados los prefijos:
    • +0 para un OCA (servidor de Netflix)
    • +50 para una conexión directa de peering (PNI)
    • +100 para peering en un IX (peering público)
  • No hay límite para el valor máximo de MED.
  • Un MED omitido es considerado como un MED con valor 0, lo cual indica que el dispositivo debería recibir todo el tráfico para los prefijos asociados (esto se refiere también como MED-missing-as-best). Recuerde, si varios dispositivos reciben el mismo prefijo con la misma métrica, el tráfico se equilibra en todos esos dispositivos. Debido a que un MED omitido equivale a 0, éste se prefiere en lugar de cualquier otro MED con valor >0 en otros dispositivos.
  • Importante: Añadir MEDs en un OCA ya instalado y operativo puede causar problemas, ya que deben añadirse en todas las sesiones BGP en todos los dispositivos en un mismo sitio.

Por último, recuerde que si usted tiene un acuerdo de interconexión o peering con Netflix, y utiliza el filtrado IRR, nuestro prefix-set es RS-NETFLIX y nuestro as-set es AS-NFLX. Por favor asegúrese de aceptar anuncios que se originan desde ASNs: 2906, 40027, y 55095.

Requerimientos de BGP

  • Anuncios de enrutamiento para dispositivos Open Connect:
    • Se aceptan prefijos IPv4 entre /8 y /31 (inclusive).
    • Se aceptan prefijos IPv6 entre /19 y /64 (inclusive)
  • Anuncios de enrutamiento para sesiones de peering Open Connect:
    • Se aceptan prefijos IPv4 entre /8 y /24 (inclusive).
    • Se aceptan prefijos IPv6 entre /19 y /48 (inclusive).
  • Como requerimiento implícito, todos los dispositivos deben tener una sesión BGP configurada a fin de participar correctamente en el direccionamiento y entrega del contenido de Netflix.
  • Para localizar tráfico, la mejor práctica es anunciar las rutas más específicas al dispositivo. Por ejemplo, si anuncia un /22 al OCA, pero un /24 es recibido a través de peering o tránsito, se prefiere el /24 al /22, y el contenido es entregado desde una fuente remota en lugar de ser entregado desde el OCA.
  • Si solo está instalando un OCA en su red, el prefijo más específico (el más largo) debería ser anunciado en ese dispositivo durante la sesión de peering que desee usar para el llenado nocturno.
  • Si está instalando múltiples OCAs es más de un sitio en su red:
    • Para permitir un llenado nocturno efectivo: asegúrese que los dispositivos ubicados en un sitio puedan escuchar las subredes de los dispositivos ubicados en otro sitio vía la sesión BGP establecida en su router. Para más información consulte el artículo Patrón de llenado.
    • Más información disponible en la sección Arquitectura de Cluster.
  • Netflix no usa la información de ninguna comunidad BGP anunciada por socios a los OCAs o vía peering Open Connect.
  • Las rutas anunciadas que recibe un dispositivo se sincronizan con el plano de control de Open Connect aproximadamente cada 5 minutos.
  • Netflix utiliza el filtrado RPKI. Para más información consulte el artículo Filtrado RPKI en sesiones BGP.
  • Netflix se ha unido a la iniciativa MANRS. Para más información consulte el artículo: Normas Mutuamente Acordadas para los Estándares de Seguridad de Enrutamiento (MANRS).

Resolución de problemas de anuncios BGP

El Portal de Socios cuenta con herramientas que pueden ayudar a explorar y ofrecer soluciones a problemas relacionados con anuncios de BGP.

  • La herramienta Route Explorer monitorea el estado de las sesiones BGP y los anuncios configurados entre sus routers y sus OCAs.
  • La herramienta Route Optimizer ejecuta reportes de sus anuncios BGP. Los reportes incluyen todos los anuncios que Netflix escucha desde su ASN(s), incluyendo los de las sesiones de peering y  sitios con OCAS.
  • La herramienta Route Performance Report muestra los prefijos de su red que posiblemente experimenten una baja calidad de transmisión de video.

OCAs combinado con sesiones de peering

Al participar de Open Connect, lo ideal es contar con acuerdos de interconexión gratuitos o peering y OCAs.  Netflix utiliza dos sistemas autónomos diferentes para hacer peering:

  • AS2906 es el AS que Netflix utiliza para hacer peering en sus Puntos de Presencia.
  • AS40027 es el AS que se usa para que los OCAs hagan peering con los ISPs.

En la sección Requerimientos de BGP puede ver los prefijos que se aceptan en las sesiones de peering.

Cuando se cuenta con ambos, OCAs y acuerdos de peering, la sesión de peering se usa principalmente como soporte o backup, para llenado, y para servir los títulos menos buscados/populares.

Asumiendo que el trayecto de la ruta AS de peering y hacia el OCA son iguales, y si usted anuncia los mismos prefijos en la sesión de peering pública o privada (usando AS2906) y en el OCA (usando AS40027), se preferirá el OCA en lugar de peering. Esto es porque el plano de control tendrá dos registros BGP para ese prefijo:

  • Uno con trayecto AS PATH de 1 (<AS_NUMBER>) desde el dispositivo
  • Uno con trayecto AS PATH de 2 (2906 <AS_NUMBER>) desde el sitio de peering

Tenga en cuenta el criterio de selección descrito anteriormente, y recuerde que en general se recomienda anunciar las rutas más específicas a sus dispositivos, para que así éstos tengan preferencia al momento de servir tráfico.

Arquitectura de cluster

Cuando hay más de un OCA en un sitio, estos dispositivos son configurados como un clúster de manifiesto único. Los OCAs en un clúster de manifiesto comparten el contenido almacenado y funcionan juntos como una sola unidad lógica.

A pesar de que los socios no necesitan configurar los clúster de manifiesto, es importante entender algunos conceptos básicos de clustering. Sobre todo porque hay implicaciones que considerar cuando los dispositivos en un clúster son movidos a otro sitio o cuando se les da mantenimiento.

Los beneficios de clustering:

  • Mayor descarga para contenido único

    En un clúster típico de dos OCAs, ambos dispositivos utilizarán aproximadamente 40% de su capacidad para almacenar el mismo contenido popular. Este contenido representa apenas el 60% del total de descarga del dispositivo.  El 60% restante del espacio de almacenamiento de cada OCA se usa para almacenar el contenido que se accede con menor frecuencia. El mismo set de contenido no se almacena en cada OCA de un clúster, debido a eso un clúster de OCAs ofrece mayor descarga total que un conjunto de OCAs que no han sido agrupados en un clúster. Esta estrategia permite que los OCAs en un mismo sitio operen de manera más eficiente.

    Puede encontrar más información sobre estrategias de almacenamiento en este artículo de Netflix TechBlog.

  • Mayor resiliencia

    En un clúster con dos OCAs hay redundancia. En caso de que un OCA falle, el dispositivo saludable se hará cargo de la mayoría del tráfico que la unidad fallida estaba sirviendo. Vea los diferentes escenarios de fallos en ejemplos de arquitecturas.

Aviso importante a los socios

  • Una vez que un conjunto de OCAs ha sido instalado en un sitio y agrupado como un clúster por el equipo de Open Connect, éste conjunto de OCAs debe ser visto como un solo servidor. Por lo tanto, cualquier cambio que se haga en un OCA dentro de un sitio puede impactar de forma negativa la eficiencia de servicio y comportamiento de todo el grupo.
  • Si necesita hacer cambios en los OCAs en un sitio – por ejemplo, si necesita trasladar un OCA de un sitio a otro, o si requiere desactivar uno o más OCAs por un período de tiempo largo - es importante que notifique al equipo de Open Connect para que se hagan los cambios necesarios a la configuración del clúster. No hacerlo, puede ocasionar consecuencias no deseadas. Por ejemplo, el tráfico puede ser direccionado hacia el sitio equivocado, los patrones de tráfico pueden llegar a ser subóptimos, y se pueden desarrollar puntos de cuello de botella.
  • Para facilitar patrones de tráfico óptimos y equilibrados, los OCAs en un sitio deben recibir exactamente los mismos anuncios BGP. Por lo tanto, si un OCA se reubica a otro sitio, debe revisar las rutas anunciadas en el dispositivo para asegurar que el tráfico sea direccionado de forma adecuada.

Dispositivos Flash

Si usted es un ISP con niveles altos de tráfico de Netflix, podemos incluir dispositivos Flash en la arquitectura de despliegue de OCAs. Los dispositivos Flash se ofrecen cuando se alcanza el límite de dispositivos Storage.

Was this article helpful?
0 out of 0 found this helpful