Recomendación acerca de Agregación de Rutas Basado en el documento original: RIPE Routing Working Group Recommendations on Route Aggregation Philip Smith Rob Evans Mike Hughes Document ID: ripe-399 Date: December 2006 http://www.ripe.net/ripe/docs/ripe-399.htm Resumen Este documento discute la necesidad de se agregar prefijos en la Internet, y recomienda algunas practicas para Proveedores de Servicio Internet y otros Sistemas Autónomos conectados a la Internet. 1. Introducción Internet es hecha de varios redes autónomos (usualmente llamados Sistemas Autónomos, o del Inglés Autonomous System - AS), que se interconectan entre si. Estas redes autónomas tendrá con el tiempo espacios de direcciones IPs asignados y para uso en sus redes o en las redes de sus clientes. Ese espacio de direcciones es anunciado para las redes autónomas vecinas. Dependiendo del tipo de acuerdo o contractos comerciales entre dichos vecinos, ese espacio de direcciones pueden o no ser anunciados a las redes autónomas vecinas. Y también para la Internet. La colección de los espacios de direcciones anunciadas por las organizaciones creando la Internet es lo que se llama de Tabla de Rutas Internet. Con cada AS anunciando su espacio de direcciones, y cada AS "escuchando" ese anuncio, directa o indirectamente, cada sistema en la Internet es capaz de se comunicar con cualquier otro sistema. Por lo tanto, permitiendo la existencia de ese sistema de comunicación global que conocemos como Internet. 2. "Background" Tal cual como figura en el CIDR Report[1], y en otros reportes similares, el tamaño de la Tabla de Rutas Internet ha sido de mucho interese para Proveedores de Servicio Internet e para compañías de equipos de ruteo desde la rápida adopción de la Internet como medio de comunicación en el inicio de los años 90. 2.1 Internet en su inicio En el inicio de la Internet, espacio de direcciones eran asignadas a Sistemas Autónomos y Sitios finales de acuerdo con tres categorías: clase A, clase B y clase C. Y la tabla de rutas Internet contenía solamente estos tres tipos de direcciones. A organizaciones pequeñas se les asignaba clase C. A organizaciones medianas clase B y a organizaciones largas clase A. Esto era denominado asignación de direcciones "classful", y los sistemas de ruteo comprendía las diferentes clases. Un grande esfuerzo fue visto en 1994 cuando se comenzó una conversión del sistema "classfull" para un otro que utilizaría direcciones "classless" ([2] y [3]). La motivación para dicha conversión era la rápida disminución del espacio de direcciones con el esquema "classful", en especial en lo que tocaba a las direcciones en espacio clase B (128.0.0.0 a 191.255.0.0). Con la comercialización de la Internet y antes de la migración para el sistema "classless" de direcciones, las organizaciones que habían crecido allá de los requerimientos para uno solo espacio de dirección clase C, recibiría otro espacio clase C al contrario de recibir un espacio clase B. Eso para reducir la presión el en espacio de direcciones clase B. El resultado de eso era que muchas organizaciones poseían largas cantidades de direcciones clase C (lo que en la terminología actual, serían los /24s). Como parte de la migración para el sistema de ruteo classless, la motivación del CIDR Report era estimular a los operadores de las redes autónomas a agrupar sus /24s contiguos en un solo anuncio. Esta actividad es lo que se denomina agregación y será explanada con más detalles a continuación. 2.2 Internet hoy En la Internet actual con el uso del esquema de "classless", los operadores de redes reciben espacio de direcciones de los Registros Internet Regionales (RIR) de acuerdo con su región. Y dichas asignaciones serán de acuerdo con los requerimientos de cada operador y en general tendrán un prefijo minino de un /21. Los operadores de redes anunciarían los espacios de direcciones recibidos de los RIRs para la Internet. Tal cual se pasaba antes en el comienzo de la Internet y mientras se utiliza el esquema de clases de direcciones. Mismo que no se tenga mucha cosa escrita acerca de eso, lo que se esperaría era que los anuncios de dichos espacios de direcciones fueran hechos con el mismo prefijo de la asignación. Pero lo que se ve de manera mas común es que los anuncios aún son hechos, en muchos casos, en prefijos de /24 (el equivalente al antiguo clase C). El resultado de eso es que el 60% de la tabla de rutas consiste de prefijos /24. Algunos de los anuncios de /24 son, sin duda, hechos por cuestiones de ingeniería de trafico y multihoming. Pero gran parte es el resultado de ISPs recibiendo "32 clases C" de los RIRs y los anunciando como tal para la Internet. (El comportamiento esperado sería agruparlos en uno solo anuncio de un bloque de prefijo /19). 3 ¿Que es agregación? Agregación es el hecho de poner varias direcciones IPs contiguas en uno único bloque de direcciones IP. Un ejemplo sería un ISP que recibe 4096 direcciones IPs de un RIR, que sea 10.201.48.0 hasta 10.201.63.255, ello anunciaría para la Internet un único bloque: 10.201.48/20. Una otra forma de agregación es en la forma de Proxy BGP. En ese caso un ISP, por ejemplo, toma los bloques contiguos que le fueran anunciados por otras redes (en general utilizando BGP), y los agrupa en uno solo bloque mas largo y lo anuncia de esa forma. 4 Tabla de Rutas Internet Hay algunos puntos que contribuyen para el tamaño de la tabla de rutas internet. 4.1 ¿Qué es desagregación? Los RIRs asignan espacio de direcciones IP para los ISPs en bloques, y se espera que dichos bloques sean anunciados para la Internet sin alteración. O sea, como un bloque cuyo prefijo comprende todo el espacio asignado. Es importante destacar que no hay ninguna regla por parte de los RIRs que indique como los ISPs deben anunciar los bloques a ellos asignados. Se considera impropio que los RIRs digan a los ISPs como anunciar sus bloques. Pero muchos ISPs no anuncian sus direcciones como un único bloque, prefiriendo anunciarlos como varios bloques menores. En algunos casos, menores que /24. Eso es lo que se conoce como "desagregación". 4.2 Desagregación general Aparentemente, hay varias razones para hacer la desagregación. Algunos proveedores la justifican basado en razones comerciales; otros indican preocupaciones con sistema de seguridad de ruteo; otros justifican que eso reduce el consumo de la banda utilizada por virus y otras actividades de abuso contra su red. La seguridad de sistema de ruteo es una preocupación general de muchos proveedores de Internet. No hay ningún sistema acepto universalmente para asegurar que un proveedor es quién tiene derecho de originar el anuncio de un bloque de direcciones. El resultado es que algunos proveedores intentan contornar esa falta de un sistema anunciando el prefijo mas especifico posible. Con eso, ninguno otro sistema autónomo puede anunciar un prefijo mas especifico provocando una negación de servicio contra el usuario legitimo de ese espacio de direcciones. Pero, los autores del documento original indican haber tomado conocimiento de muy pocos incidentes como ese, y por lo tanto, la desagregación por razones de seguridad al sistema de ruteo parecen más perjudicial a la tabla que comparado al risco en potencial. Una otra justificativa para la desagregación sería la reducción a ataques de negación de servicio y otras actividades nocivas contra la red de un proveedor. Es del conocimiento de todos que existen muchos virus y "worms" en la Internet que simplemente hacen "scans" de todo el espació contiguo (sea ello ruteado o no), buscando por sistemas infectados. Eso crea un trafico considerado "ruido de fondo" direccionado al bloque de IPs. Considerando las experiencia apuntado por los autores del texto original, el anuncio de un bloque de direcciones /16 puede atraer hasta 2Mpbs de ese tipo de ruido. Por lo tanto, ISPs anunciarían solamente lo que se esta utilizando de hecho. Así que cada /24 es "consumido" en la estructura del proveedor y por sus clientes, el proveedor anunciaría también ese /24 para la Internet. Pero, mismo cuando todo el espacio esta en uso, no se verifica ningún esfuerzo del ISP en comenzar a anunciarlo de forma agregada. Lo que impacta en el tamaño de la tabla de rutas. 4.3 iBGP y eBGP Una otra razón para desagregación parece ser un falla en comprender la diferencia entre BGP utilizado dentro de la red del ISP (iBGP - de internal BGP), y el BGP utilizando para ruteo inter dominio (eBGP - de external BGP). iBGP tiene la función de cargar internamente información de las rutas de los clientes y de la estructura del ISP, así como rutas aprendidas de otras redes de otros ISPs. eBGP tiene la función de anunciar rutas entre dominios, lo que se logra simplemente anunciando el bloque de direcciones que le fue asignado a un ISP por un RIR. De manera muy común, ISPs dejan pasar información del iBGP en la comunicación eBGP, lo que resulta en un crecimiento impactante en el tamaño de la tabla de rutas. 4.4 Desagregación y "Multihoming" La necesidad de hacer la desagregación con objetivo de ingeniería de trafico por parte de las redes que son multihomed, es citado a menudo como motivo o justificación para el tamaño de la tabla de rutas Internet. Sería una practica común para una red multihomed estándar tomar cualquier asignación de direcciones, dividirla en bloques /24 y anunciarlos a través de cada uno de sus links a redes externas. Se elige un /24 como unidad minina una vez que se cree que ISPs filtren bloques con prefijo mas largos que /24. Según la experiencia de los autores del documento original, la teoría de que solamente el hecho de anunciar bloques en prefijos /24 garantirían un buen funcionamiento de una conexión multihomed no es completamente verdadera. Según los autores, la ingeniería de trafico e balanceo de carga es obtenida solamente cuando se anunciar sub prefijos de los bloques asignados llevando en consideración el trafico generado por los equipos utilizando dichos sub prefijos. 4.5 Asignaciones legadas Las asignaciones legadas son vistas, comúnmente, como principales culpadas por el tamaño de la tabla de rutas. Estas asignaciones fueran hechas por la IANA antes de la creación de los RIRs. Entretanto, el principal factor de contribución para el tamaño de la tabla son las asignaciones legadas hechas en el bloque 192/8, el primer /8 del antiguo espacio clase C.... 5. Impactos del Tamaño de la Tabla de Rutas ¿Por qué el tamaño de la tabla de rutas es importante? Lo que se menciono hasta ahora en ese documento se concentro en la prudencia de lo que se debe anunciar para la Internet. Pero, hay algunos impactos para los Sistemas Autónomos que participan de la Internet actualmente. 5.1 Memoria de los Ruteadores En la historia de la Internet se ha visto que los fabricantes de equipos los especifican com capacidad suficiente para la red del momento. Con el rápido crecimiento de la Internet, esto ha causado una cierta angustia en los operados de diferentes sectores. El rápido crecimiento de la Internet hace con que un ruteador capaz soportar la tabla completa e de rutas en un año no lo sea en el año siguiente. Nuevos modelos de ruteadores con mucho más capacidad de memoria son la solución natural, implicando una vida corta para estos equipos cuando comparado con otros componentes en la Internet. 5.2 Poder de procesamiento de los Ruteadores Un otro recurso sob presión es la CPU de los ruteadores (plano de controle). Cuanto mayor es la tabla de rutas Internet, más tiempo se toma de la CPU en los procesos iniciales de la conexión BGP, y más tiempo se requiere de la CPU cuando se necesita procesar actualizaciones en la tabla debido a cambios en la topología de las redes. CPU más rápidas reducen dichos tiempos, por lo tanto, operadores de redes están siendo obligados a actualizar las CPUs de sus ruteadores, en general, con el cambio completo del equipo, solamente para mantener el mismo rendimiento en su red. El resultado es que el tiempo de vida para un equipo de ruteo esta decrementado a medida que la tabla de rutas crece. 5.3 Convergencia de Rutas Convergencia de rutas ocurre cuando la red ha finalmente calculado el mejor camino hasta un destino en particular. Lo que se necesita hacer siempre que una ruta es retirada de tabla o una nueva es a ella agregada. Es un proceso computacional que toma tiempo. Los dos factores claves que afectan el tiempo para la convergencia de una ruta son la CPU del ruteador y el tamaño de la tabla de rutas. Cuanto mayor es el numero de prefijos en la tabla de rutas Internet, más trabajo tendrá el ruteador para encontrar nuevas rutas. Ese tiempo puede ser reducido con el uso de CPUs más rápidas, lo que se logra con caras actualizaciones del plano de controle; con sustitución del equipo completo lo que implica en costos aún mayores y también en paradas en la red. La alternativa es reducir el tamaño de la tabla de rutas Internet a través de la agregación de prefijos en anuncios más pequeños cuanto sea posible. Convergencia demorada significa una recuperación demorada en caso de falla en la red. Lo que implica también en problemas más visibles para los usuarios. 5.4 Rendimiento de la red. El rendimiento de la red es algo que operadores de redes no consideran que tenga relación con anuncio de prefijos para la Internet. Pero, es relativamente sencillo demostrar que a falla en anunciar de forma agregada hace que la experiencia de los usuarios finales con la Internet en general sea peor de que si se anunciara de forma agregada. Una situación típica que los autores del documento original tienen encontrado es cuando operadores de redes anuncian prefijos de su BGP interno para la Internet (a través de su conexión BGP externa). Los prefijos de los clientes son insertados en la tabla BGP interna cuando los links con estos clientes son activados, y son sacadas de la tabla cuando estos mismos links se desactivan (por alguna falla, por ejemplo). El problema de dejar pasar la tabla BGP interna para la Internet es que los prefijos de los clientes deben ser sacados de todos los ruteadores que tienen la tabla completa de Rutas Internet. Y el proceso de sacar los prefijos no ocurre de forma instantánea o de manera uniforme. Cuando el link hacia el cliente retorna al estado normal, su prefijo es reinsertado en la tabla BGP interna del proveedor y entonces anunciada para la Internet. La propagación de ese anuncio tampoco ocurre de forma inmediata. El resultado es que ese Usuario Final ve la internet como que se no estuviera disponible de inmediato cuando su link retorna al estado normal. Y llamadas al soporte del proveedor son tratadas de forma negativa una vez que desde el punto de vista de operador todo está normal. Caso el proveedor Internet no hubiera repasado para la internet la tabla BGP interna, y anunciado solamente su espacio de direcciones de forma agregada, su cliente no habría visto la demora en la restauración de conexión con la Internet. 6 Soluciones Varias soluciones para el problema de crecimiento de tabla de rutas Internet han sido propuesta y probadas con los años. 6.1 Reporte CIDR El Reporte CIDR ("The CIDR Report"), fue inicialmente una técnica implementada para contener el crecimiento de la tabla de rutas Internet. La idea era estimular los ISPs a anunciaren sus espacios de direcciones de forma agregada. Su efectividad se concentraba básicamente en la presión al nombrar aquellos ISPs que no anunciaban de forma agregada. Lo que fue eficiente en los primeros años de la migración del esquema "classful" para "classless". Pero más recientemente se ha notado ISPs utilizando su posición el Reporte CIDR como factor positivo en el marketing por su status y influencia en la Internet. Más recientemente el Reporte CIDR ha cambiado de una herramienta de reporte para un sitio web [1] con interfaz que permite a los operadores de red verificaren sus esfuerzos en agregar. El Reporte CIDR incluye también una herramienta que toma la tabla de rutas desde el punto de vista de un ASN particular y sugiere posibles medidas de agregación. Hay pocas razones para cualquier proveedor no conocer sus anuncios para la tabla de rutas Internet, y también pocas disculpas para ellos en conocer como mejorar sus esfuerzos en hacer anuncios agregados. 6.2 Filtros Una otra técnica utilizada es el filtro de rutas con base en el tamaño mínimo de las asignaciones por parte de los RIRs en los bloques que les fueran asignados por IANA. Por ejemplo, si la asignación minina de un RIR para un /8 particular es /21, los operadores de redes filtrarían anuncios de rutas recibidos de conexiones externas con lo que, se rechazaría prefijos menores que /21. Un resultado positivo es que operadores anuncian prefijos más largos (y también sus bloques agregados) para contornar dichos filtros. No esta claro cuantos operadores de red hace uso de filtros tomando como base el tamaño mínimo de las asignaciones de los RIRs, ni si el uso de dichos filtros es eficiente en limitar el tamaño de la tabla de rutas. Esta claro, por otro lado, que si un operador recibe un asignación de tamaño mínimo de un RIR, sus posibilidades de ingeniería de trafico son restringidas de alguna forma. Pues no le será posible dividir el bloque asignado si sus proveedores aplicaren filtros con base en la asignación mínima de los RIRs. 6.3 La "Policía CIDR" En los finales de 90 y inicio de 2000, un pequeño grupo de voluntarios analizó varios reportes de anuncios de rutas y dedicaran sus tiempos libres a trabajar con los ISPs que anunciaban más prefijos que el necesario. Ellos miraban los anuncios contiguos de /24 y sugerían medidas de agregación. Eso obtuvo distintos grados de éxito, variando desde la cooperación y apreso hasta hostilidad por parte de los operadores de redes. En medianos del año 2001, con el "bust" de la Internet, ese grupo paso a se dedicar a otras prioridades. Más recientemente han surgido algunas decisiones acerca de recrear el grupo pero sin resultados concretos hasta el momento. 6.4 Facilidades BGP La comunidad Internet (principalmente los ISPs y fabricantes de equipos) ha trabajado también para añadir facilidades al BGP para ayudar con los esfuerzos de agregación. Lo cuales son discutidos a continuación. 6.4.1 El "NO_EXPORT" BGP Community La primera ayuda para multihoming e agregación de prefijos viene en la forma de la comunidad BGP (BGP community) NO_EXPORT, descrita como parte de la especificación de los atributos de las comunidades BGP. Un prefijo marcado con esa comunidad no será anunciado a través de una conexión eBGP (BGP externo). La idea es que un proveedor Internet dejará pasar sub prefijos para su proveedor superior para un "peer" por cuestiones de ingeniería de trafico; pero, el hecho de marcar aquellos sub prefijos con "NO_EXPORT" indica a su proveedor superior o "peer" que dichos prefijos no puede ser anunciados a otros sistemas autónomos allá del suyo. Muchos proveedores utilizan esta comunidad BGP para propósitos de ingeniería de trafico, pero quizás su uso no es tan intenso como debería. 6.4.2 El "NOPEER" BGP Community La ayuda siguiente para temas de ingeniería de trafico y agregación era la comunidad BGP "NOPEER". Lo que fue creado demasiado reciente pero no tuvo suporte por parte de los fabricantes de equipos, y aparentemente poca demanda por parte de los ISPs. La idea era marcar anuncios de prefijos a los proveedores con dicha community. Los proveedores superiores podrían anunciar o no dichos prefijos a otros sistemas autónomos de acuerdo con la identificación de la conexión eBGP ser de "peer" o no. 6.4.3 El atributo "AS_PATHLIMIT" La ultima contribución para ayudar con ingeniería de trafico en conexiones multihomed fue la propuesta de se crear un atributo BGP "AS_PATHLIMIT" [12] La idea es restringir la propagación de un prefijo a un rayo particular de AS, tal cual definido por el atributo AS_PATHLIMIT. Ese atributo contiene el numero máximo de ASNs que puede aparecer en el "AS Path" de una ruta BGP. Cada Sistema Autónomo que reciba un anuncio con ese atributo verificaría el valor del AS_PATHLIMIT con el numero de ASNs en el AS_PATH de la respectiva ruta. Si el numero de ASNs en el AS_PATH es mayor que el valor del AS_PATHLIMIT, el prefijo no es procesado o propagado para peers eBGP. Eso permitiría ISPs hacer ingeniería de trafico local sin que proveedores más "distantes" tuvieran que recibir algunos anuncios más especifico. 6.4.4 Comunidades específicas del Proveedor Muchos proveedores permiten que sus clientes utilicen comunidades BGP para indicar grados de propagación de sus prefijos, lo cuales permitirían mejor controle que la comunidad NO_EXPORT, y aún impidiendo que dichos anuncios lleguen a la tabla global de rutas. En general, eso incluye opciones como "todos peers regionales", "todos peers", o en algunos casos solamente algunos peers específicos con los cuales el cliente es multihomed. Dichas comunidades especificas del proveedor estan en sus sitios web o en "Internet Routing Registries". 7 Recomendaciones La parte final del documento original describe las recomendaciones de grupo de trabajo de Ruteamento del RIPE (RIPE Routing Working Group), acerca de anuncios de rutas para la Internet. El grupo espera que los operadores de red sigan las recomendaciones y así se mantengan el crecimiento de la tabla de rutas Internet sob controle. 7.1 Asignaciones Iniciales Cuando un operador de red recibe una asignación de direcciones IP de un RIR, o una asignación de su ISP, la expectativa es que las direcciones IPs sean combinadas en el bloque más largo posible y anunciado como tal para el resto de la Internet. Por ejemplo, si un operador de red recibe un /21 de un RIR, ese debería configurar su BGP para anunciar solamente ese /21 a sus Sistemas Autónomos vecinos. 7.2 Asignación Adicionales Siempre que posible, los RIRs intentan hacer una asignación adicional a un ISP que sea contigua con la asignación anterior. Cuando un operador recibe una nueva asignación del mismo tamaño que la anterior y que sean contiguas, el operador debe combinar los dos bloques de direcciones y anunciarlos de forma agregada. Por ejemplo, un operador de red recibe inicialmente un /21 y en seguida el /21 contiguo. Si los dos /21 están el en mismo "bit boundary", ellos pueden ser combinados en uno solo /20. El operador de red debería entonces anunciar ese /20 a sus Sistemas Autónomos vecinos y remover el anuncio de /21 inicial. Si la asignación adicional no es de un bloque contiguo, o es contiguo pero esta en otro "bit boundary", o de tamaño distinto, entonces no habría como agregarlos en uno solo prefijo, y habría que anunciar los dos prefijos independientes. 7.3 Multihoming Si la red es multihomed, será necesario dividir el bloque (o bloques) de direcciones para hacer la ingeniería y balanceo de trafico. Caso el operador de esa red necesita hacer eso, el debe seguir anunciando el bloque original (antes de la división), para garantir así respaldo cuando uno de los links falle. La división del bloque de direcciones debe ser hecha con criterio para obtener el máximo de la ingeniería de trafico sin impacto significativo a la tabla de rutas Internet [15]. 7.4 Avances BGP Los variados avances BGP descritos en la sección anterior debe también ser considerados cuando apropiado y cuando soportado por el equipo de ruteo. Muchos de los proveedores, fuera del "core" de la Internet, van a encontrar uso para comunidades "NO_EXPORT" y "NOPEER" así como para el atributo BGP "AS_PATHLIMIT". 7.5 Agregación a través de Proxy Agregación a través de Proxy debe ser tratada con cuidado. Agregar anuncios originados por otros ASNs puede llevar a efectos desagradables, especialmente cuando se considera los deseos de hacer ingeniería de trafico por parte de otros ASNs, y también por la posibilidad de absorber el trafico en caso de falla de link. Por lo tanto, eso debe ser hecho solamente cuando el ISP esta seguro que no habrá impactos en la operación de la red afectada. 7.6 IP versión 6 Mismo que dichas recomendaciones tiene foco en IPv4, ella son igualmente aplicables a IPv6. Participación en la Internet IPv6 no es diferente de que la participación en Internet IPv4, y las expectativas para con los Sistemas Autónomos son exactamente las mismas. 8 Conclusión Agregación es algo necesario para la operación de redes en la Internet actual. Lo que se logro con la migración para el esquema "classless" en años 90 no más parece ser una actividad estándar para los operadores. Y el resultado es el crecimiento rampante de la tabla de rutas Internet, provocando problemas que tienen impacto para todos los participantes de la Internet. Análisis de la actividad BGP tal cual [16], demuestran el potencial de economía posible en el tamaño de la tabla de rutas Internet - y dichas economías en potencial son significantes y están entre el 30% a el 50%. Referencias [1] The CIDR Report | Original Idea: Tony Bates | Maintained by: Geoff Huston http://www.cidr-report.org/ [2] RFC1518 - An Architecture for IP Address Allocation with CIDR | Tony Li and Yakov Rekhter http://www.rfc-editor.org/rfc/rfc1518.txt [3] RFC1519 - Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy | Vince Fuller, Tony Li, Jessica Yu and Kannan Varadhan http://www.rfc-editor.org/rfc/rfc1519.txt [12] AS-PATHLIMIT Attribute | Joe Abley, Tony Li and Rex Fernando http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-02.txt [15] BGP Multihoming Techniques | Philip Smith - NANOG 35 http://www.nanog.org/mtg-0510/pdf/smith.pdf [16] Aggregation Potential http://bgp.potaroo.net/as4637/