SmashByte Wireless / tower networking

Requisitos de ASN y BGP para WISP en crecimiento

Cuándo solicitar su propio ASN, cómo obtener espacio de direcciones IP y cómo construir una política de enrutamiento BGP que resista la caída de un proveedor.

La mayoría de los WISP comienzan detrás de un único proveedor upstream: un circuito, una ruta por defecto estática y un bloque de direcciones IP asignadas por el proveedor. Eso funciona hasta que deja de funcionar. En el momento en que desea un segundo upstream, espacio IP independiente del proveedor o un control real sobre cómo llega el tráfico a su red, necesita su propio Número de Sistema Autónomo (ASN) y una configuración de BGP funcional.

Este artículo recorre las preguntas propias de la etapa de decisión: cuándo se justifica un ASN, cómo solicitarlo, cómo obtener espacio IP, cómo luce una política de enrutamiento sensata y cómo establecer peering para lograr redundancia. Si todavía está evaluando si BGP es necesario en absoluto, comience con enrutamiento estático versus BGP para WISP y regrese cuando la respuesta sea sí.

Cuándo un WISP en crecimiento realmente necesita un ASN

Un ASN no es un símbolo de estatus. Es un compromiso operativo: usted se vuelve responsable de anunciar rutas a Internet correctamente, para siempre. Los factores que lo justifican son concretos:

  • Está incorporando un segundo proveedor upstream. Hacer multihoming con dos circuitos de tránsito y una ruta por defecto en cada uno le brinda, en el mejor de los casos, una conmutación por error rudimentaria. BGP con su propio ASN le da una conmutación por error determinística y automática, además de la capacidad de preferir una ruta sobre otra.
  • Necesita espacio IP independiente del proveedor (PI). Las direcciones asignadas por un único proveedor se devuelven cuando usted se va. El espacio PI es suyo, se anuncia bajo su ASN y es portable entre proveedores: no tendrá que renumerar clientes cuando cambie de tránsito.
  • Quiere hacer peering en un punto de intercambio o directamente con redes de contenido. El peering sin costo de liquidación (settlement-free) requiere un ASN y sesiones BGP bajo su control.
  • Un carrier o centro de datos lo exige. Muchas interconexiones de colocation, servicios de mitigación de DDoS y productos de tránsito mayorista asumen que usted trae su propio ASN.

Si ninguna de estas situaciones aplica todavía —un solo proveedor, una sola torre, IPs asignadas por el proveedor— el enrutamiento estático sigue siendo la respuesta correcta. Reconsidere cuando una segunda torre o un segundo circuito entre en el plan.

Solicitar un ASN a su registro regional

Los ASN los emite el Registro Regional de Internet (RIR) de su zona geográfica: ARIN en Norteamérica, RIPE NCC en Europa y Medio Oriente, APNIC en Asia-Pacífico, LACNIC en América Latina y AFRINIC en África. El proceso es similar en todas partes:

  • Cree una cuenta en el RIR y pague las tarifas de registro y de mantenimiento anual.
  • Documente que tiene multihoming —o un plan aprobado y fechado para tenerlo—, normalmente indicando los dos ASN upstream distintos a los que se conectará.
  • Proporcione los datos de la entidad legal, los puntos de contacto (administrativo, técnico, abuso) y firme el acuerdo de servicio del registro.

Una vez que la documentación está en orden, la aprobación suele medirse en días o unas pocas semanas. Recibirá un ASN de 16 o 32 bits; a efectos prácticos son intercambiables, ya que todos los routers y proveedores de tránsito modernos admiten ASN de 4 bytes.

Mantenga actualizados los registros de contacto del registro. Los contactos de abuso cuyo correo rebota son una vía rápida para terminar en listas de bloqueo, y los contactos técnicos desactualizados ralentizan los tickets de soporte cuando una fuga de rutas o un secuestro involucra sus prefijos.

Obtener espacio de direcciones IP

Un ASN sin espacio de direcciones no anuncia nada. Tiene dos fuentes:

Espacio asignado por el proveedor (PA)

Su upstream le presta un bloque y lo anuncia como parte de su agregado. Está bien para comenzar, pero no es portable: si cambia de proveedor, renumera a cada cliente. Use el espacio PA solo como puente.

Espacio independiente del proveedor (PI)

Se solicita al RIR con una necesidad documentada, o se adquiere en el mercado de transferencias. El IPv4 está agotado en los registros, así que espere asignaciones iniciales modestas, trámites de justificación y —si compra en el mercado de transferencias— un costo por dirección considerable. El IPv6, en cambio, es prácticamente gratuito: solicite una asignación amplia desde el primer día y opere en dual-stack para que sus necesidades de IPv4 disminuyan con el tiempo.

¿Cuánto espacio necesita? Depende de los clientes por torre, de la política de IP públicas frente a CGNAT (Traducción de Direcciones de Red a nivel de operador) y del crecimiento. Dimensione de forma deliberada en lugar de pedir el máximo que pueda justificar: nuestro artículo sobre cuántas IP públicas necesita una torre WISP desarrolla el cálculo por torre, y la calculadora de tamaño de bloque IP convierte la cantidad de clientes en un tamaño de subred concreto. La solución de direccionamiento IP cubre el lado de adquisición de bloques PI.

Sea lo que sea que reciba, registre los objetos de ruta en la base de datos del RIR y cree ROA (Route Origin Authorizations, autorizaciones de origen de ruta) en el RPKI para que su ASN sea el origen autorizado de sus prefijos. Cada vez más, las redes que omiten este paso descubren que sus anuncios son despriorizados o descartados por grandes proveedores que filtran según la validez RPKI.

Construir una política de enrutamiento

BGP sin política es un router cargado de riesgos. Antes de que se levante la primera sesión, escriba —literalmente, en un documento— qué anunciará y qué aceptará:

Política de salida (lo que usted anuncia)

  • Anuncie únicamente sus propios prefijos PI, mediante una lista de prefijos explícita. Nunca filtre las rutas del proveedor A hacia el proveedor B.
  • Anuncie agregados, no prefijos específicos desagregados, salvo que esté haciendo ingeniería de tráfico de forma deliberada con un prefijo más largo más un agregado que lo cubra.
  • Etiquete las rutas con communities de BGP que sus proveedores respeten (solicitudes de prepend, activadores de blackhole) para poder dirigir el tráfico sin abrir un ticket.

Política de entrada (lo que usted acepta)

  • Rechace de entrada sus propios prefijos, los bogons y los ASN privados.
  • Establezca un límite de max-prefix en cada sesión para que un vecino mal comportado no pueda llenar su tabla de enrutamiento.
  • Por defecto, acepte la tabla completa o una ruta por defecto de cada proveedor de tránsito, según la memoria del router y el grado de control de rutas que desee.

Dos routers, uno por upstream, cada uno con la política completa aplicada de forma idéntica, es la base. El iBGP entre ellos mantiene la red coherente cuando falla uno de los bordes.

Peering y tránsito para redundancia

Todo el objetivo del ejercicio es sobrevivir a la caída de un proveedor. Un diseño resiliente tiene tres ingredientes:

  • Dos proveedores de tránsito diversos que terminen en rutas físicas diferentes: distintos ductos, distintos PoP, idealmente direcciones diferentes desde la torre o el sitio central. Un ducto compartido es una falla compartida. Las soluciones de backhaul redundante y de tránsito IP cubren cómo contratar circuitos diversos que realmente no se solapen.
  • Comportamiento de conmutación por error ajustado. Aplique prepend en el proveedor de respaldo para que quede en espera en frío, o divida el tráfico deliberadamente con communities. La mecánica de la selección de rutas, los prepends y los route-maps se cubre en conmutación por error de rutas entre dos proveedores de backhaul.
  • Falla probada, no asumida. Programe una ventana de mantenimiento y apague realmente la sesión primaria. Observe la convergencia, verifique que el tráfico entrante se desvíe y mida cuánto tiempo perciben la interrupción los clientes.

La capacidad importa tanto como la diversidad de rutas: si un solo circuito no puede sostener la carga pico por sí mismo, la conmutación por error lo mantiene en línea, pero lento. La calculadora de capacidad de backhaul ayuda a dimensionar cada circuito de modo que un único sobreviviente siga satisfaciendo la demanda.

Lista de verificación de preparación para ASN y BGP

Elemento Está completo cuando
Caso de negocioSegundo upstream pedido o contratado
Cuenta en el RIREntidad legal registrada, tarifas pagadas, contactos actualizados
ASN emitidoNúmero asignado y documentado
Bloque PI IPv4Asignado o transferido; trámites de LOA/transferencia completos
Asignación IPv6Solicitada al RIR; plan de dual-stack en marcha
Objetos de ruta en el IRRPrefijos registrados a nombre de su ASN
ROA en el RPKIROA creadas para cada prefijo que anuncia
Capacidad del routerRouters de borde dimensionados para tablas completas, o plan de ruta por defecto elegido
Política de enrutamiento escritaListas de prefijos, communities, max-prefix y filtros documentados
Prueba de conmutación por errorCircuito primario apagado en una ventana; convergencia verificada

Errores comunes que debe evitar

  • Anunciar antes de que exista la ROA. Los anuncios inválidos según RPKI se filtran cada vez más; cree las ROA primero y anuncie después.
  • No tener lista de prefijos de salida. Un solo error de tipeo y usted se convierte en ruta de tránsito entre sus dos proveedores, fundiendo sus routers y su reputación en la misma tarde.
  • Omitir los límites de max-prefix. Una fuga de tabla completa desde un vecino agotará la memoria del router y tumbará su borde.
  • Dos proveedores, una sola ruta física. La diversidad lógica sobre el mismo ducto falla junta. Verifique la diversidad de ductos y PoP por escrito.
  • Nunca probar la conmutación por error. La redundancia no probada es una hipótesis. Rómpala a propósito, en una ventana, antes de que se rompa sola a las 2 a. m.
  • Olvidar los contactos de abuso y del NOC. Cuando algo salga mal, otras redes intentarán comunicarse con esas direcciones. Supervíselas.

El compromiso operativo continuo

Un ASN es un organismo vivo. Presupueste las tarifas anuales del RIR, las renovaciones del mercado de transferencias o los costos de arrendamiento si compró espacio IPv4, el mantenimiento del software de los routers y el tiempo del personal para vigilar sus anuncios. Como mínimo, suscríbase a un servicio de monitoreo de BGP que alerte cuando sus prefijos se anuncien desde orígenes inesperados o queden inválidos según RPKI: los secuestros y fugas de rutas les ocurren a redes de todos los tamaños, y la diferencia entre un incidente y una caída suele ser la rapidez con que usted se da cuenta.

Mantenga el documento de política de enrutamiento bajo control de versiones y revíselo después de cada ventana de cambios. Los WISP que operan bien BGP lo tratan como un sistema de seguridad: documentado, probado y aburrido. Aburrido es la meta.

Bien hecho, tener su propio ASN convierte el backhaul de una relación con un único proveedor en un mercado: puede renegociar, reemplazar o agregar proveedores sin renumerar a un solo cliente, y su redundancia se convierte en una propiedad de su red en lugar de una promesa en el SLA (acuerdo de nivel de servicio) de otro.

¿Listo para implementar multihoming en su red?

SmashByte Wireless provee circuitos diversos de tránsito IP y backhaul, y ayuda a los WISP en crecimiento a planificar despliegues de ASN, espacio IP y BGP. Cuéntenos sobre sus torres y sus opciones de upstream y prepararemos un diseño redundante.

Solicite una cotización de diseño de red