Contenido
- Escalabilidad en el enrutamiento de datos
- Protocolo de puerta de enlace fronterizo
- Sincronización de tabla de reenvío
- Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
Para llevar:
La escalabilidad de enrutamiento puede ser muy asistida por el Border Gateway Protocol, que ayuda a enrutar paquetes de manera más eficiente.
En informática, un concepto importante es escalabilidad, o qué tan bien una forma de manejar una determinada tarea sigue funcionando a medida que aumenta el tamaño de la tarea. Por ejemplo, escribir números de teléfono en trozos de papel funciona bastante bien cuando necesita hacer un seguimiento de una docena de números de teléfono: solo toma diez segundos encontrar uno. Pero para una ciudad con 100,000 personas, ahora toma cien mil segundos (aproximadamente un día) encontrar un número. Usando una guía telefónica para una ciudad con una población de 100,000 habitantes, se tarda aproximadamente medio minuto en encontrar un número de teléfono que tenga un nombre de pila. La gran ventaja no es tanto que usar un libro es mucho más rápido que usar trozos de papel individuales, sino que al duplicar el tamaño del problema, no se duplica la cantidad de trabajo para resolverlo: buscar a través de un teléfono un libro que es el doble de grande solo toma un par de segundos extra: ¿es el nombre que busco en la primera mitad de la segunda mitad? No toma el doble de tiempo y, por lo tanto, las guías telefónicas son escalables, pero los desechos no lo son. La escalabilidad de enrutamiento es la aplicación de la noción de escalabilidad al problema de entregar paquetes al destino correcto a través de Internet.
Escalabilidad en el enrutamiento de datos
La escalabilidad de enrutamiento consta de dos problemas: el plano de gestión y el plano de datos.
El plano de datos es el módulo central o distribuido en un enrutador que toma los paquetes entrantes y los reenvía al siguiente enrutador en su camino a su destino. Esta función debe para cada paquete reenviado encontrar el siguiente salto en la tabla de reenvío. Los dos mecanismos principales para hacer esto son una TCAM, una memoria especializada con soporte de hardware incorporado para buscar a través de ella, y una memoria regular que se busca utilizando algoritmos avanzados. La velocidad de las búsquedas no disminuye a medida que aumenta el tamaño de la tabla. Sin embargo, la TCAM o el tamaño de la memoria aumenta linealmente (o un poco más rápido que eso para las búsquedas de varios niveles), lo que aumenta el costo y el uso de energía. Además, a medida que aumenta el número de búsquedas de tabla de reenvío por segundo, se deben utilizar tecnologías más caras y que consumen mucha energía. Estos aumentos son inevitables a medida que aumenta la velocidad de la interfaz, pero también dependen del tamaño promedio o del peor de los paquetes y del número de interfaces por dispositivo o por blade / módulo en ciertas arquitecturas de enrutadores.
Durante el taller de enrutamiento y direccionamiento de la arquitectura de Internet celebrado en Amsterdam en 2006, se argumentó que los aumentos de velocidad de memoria requeridos superan los aumentos de rendimiento en componentes estándar, especialmente ahora que los SRAM separados ya no se usan ampliamente. Anteriormente, las computadoras usaban SRAM de alta velocidad como caché de memoria, pero en la actualidad esa función está incluida en la propia CPU, por lo que SRAM ya no es un chip comercial fácilmente disponible. Esto significa que los costos para los enrutadores de más alto nivel aumentarán mucho más rápido de lo que han sido hasta ahora. Sin embargo, después del taller de direccionamiento y direccionamiento de IAB, varios proveedores de enrutadores salieron y declararon en conversaciones y en listas de correo que este problema no es inmediato en este momento y que el crecimiento en los niveles pronosticados actualmente no planteará problemas en el futuro previsible.
Protocolo de puerta de enlace fronterizo
El plano de gestión consiste en un procesador de ruta que ejecuta el protocolo de enrutamiento BGP y las tareas relacionadas que debe realizar un enrutador para poder crear una tabla de reenvío. BGP es el protocolo que utilizan los ISP y algunas otras redes para comunicarse entre sí qué direcciones IP se utilizan y dónde, de modo que los paquetes destinados a esas direcciones IP se pueden reenviar correctamente. La escalabilidad de BGP se ve afectada por la necesidad de comunicar actualizaciones, almacenarlas en el enrutador y procesarlas. En este momento, el ancho de banda para propagar actualizaciones no es un problema en absoluto. En la práctica, los requisitos de memoria para almacenar tablas BGP cada vez más grandes pueden plantear un problema, esto generalmente se debe a limitaciones de implementación en enrutadores disponibles comercialmente, no debido a problemas tecnológicos inherentes. Un procesador de ruta es básicamente una computadora de uso general, que ahora se puede construir fácilmente con 16 gigabytes o más de RAM. Actualmente, el servidor de ruta pública Route Views se ejecuta con 1 GB de RAM y tiene alrededor de 40 feeds BGP completos de aproximadamente 560,000 prefijos cada uno (cifras de diciembre de 2015).
Sin embargo, esto deja el procesamiento. La cantidad de procesamiento requerida para BGP depende de la cantidad de actualizaciones de BGP y la cantidad de prefijos por. Dado que el número de prefijos por actualización es bastante pequeño, ignoraremos ese aspecto y solo miraremos el número de actualizaciones. Presumiblemente, aparte de cualquier crecimiento autónomo, el número de actualizaciones aumenta linealmente con el número de prefijos. El procesamiento real de las actualizaciones de BGP es muy limitado, por lo que el cuello de botella es el tiempo que lleva acceder a la memoria para realizar una actualización. También durante el taller de enrutamiento y direccionamiento de IAB, se presentó información que indica que el aumento en la velocidad de DRAM es bastante limitado y no podrá mantenerse al día con el crecimiento de la tabla de enrutamiento.
Sincronización de tabla de reenvío
Además de los problemas de reenvío y plano de datos por separado, existe el problema de sincronizar la tabla de reenvío con la tabla BGP / enrutamiento después de las actualizaciones. Dependiendo de la arquitectura de la tabla de reenvío, actualizarla puede llevar bastante tiempo. BGP a menudo se describe como un protocolo de enrutamiento de "vector de ruta", muy similar a los protocolos de vector de distancia. Como tal, implementa una versión ligeramente modificada del algoritmo de Bellman-Ford, que, en teoría al menos, requiere una cantidad de iteraciones igual al número de nodos (en el caso de BGP: sistemas autónomos externos así como enrutadores iBGP internos). ) en el gráfico menos uno para converger. En la práctica, la convergencia ocurre mucho más rápido porque no es un diseño viable usar la ruta más larga posible entre dos ubicaciones en la red. Sin embargo, puede ocurrir un número significativo de iteraciones en forma de actualizaciones distintas que deben procesarse después de un solo evento debido a los efectos de multiplicación. Por ejemplo, en el caso de que dos AS se interconecten en dos ubicaciones, una actualización en el primer AS se propagará dos veces al segundo AS a través de cada enlace de interconexión. Esto lleva a las siguientes opciones posibles:
Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
No puede mejorar sus habilidades de programación cuando a nadie le importa la calidad del software.
Este aspecto de BGP no es reconocido explícitamente por muchas personas, aunque estudios como Route Flap Damping Exacerbates Internet Routing Convergence abordan el comportamiento resultante.
Con lo anterior en mente, podemos concluir que BGP tiene algunos problemas de escalado: el protocolo y los enrutadores que lo implementan no están preparados para un Internet donde quizás sea necesario que BGP maneje cinco millones y ciertamente 50 millones de prefijos individuales. Sin embargo, el crecimiento actual es relativamente estable en aproximadamente el 16% anual para IPv4, por lo que no hay motivo de preocupación inmediata. Esto es especialmente cierto para IPv6, que actualmente solo tiene 25,000 prefijos en BGP.