Un día en la vida: la tabla BGP global

 (articles.foletta.org)
2 puntos por GN⁺ 2024-11-27 | 1 comentarios | Compartir por WhatsApp
  • A partir de 464,673 BGP UPDATE recibidos durante un día desde un peer con la tabla BGP completa, se observaron variaciones de corto plazo en la tabla de ruteo global, no la tendencia de crecimiento de largo plazo
  • Justo después del peering, todas las rutas y los NLRI llegaron en bloque en unos 5 segundos, y la cantidad de rutas asociadas a las paths iniciales fue de 949,483
  • Luego, los UPDATE llegaron agrupados en intervalos de 30 segundos de Route Advertisement Interval; se observaron unas 50 actualizaciones de paths cada 30 segundos en IPv4 y unas 47 en IPv6
  • En IPv4 apareció una correlación de aproximadamente 40 minutos tanto en la cantidad de paths como en los cambios del espacio de direcciones, pero la causa queda como una pregunta sin responder
  • El exceso de AS path prepending, el path attribute 255 reservado y el fuerte flapping de ciertos NLRI muestran a la vez la complejidad y la resiliencia de la operación global de BGP

Observación diaria de la tabla BGP

  • El análisis de la tabla BGP global suele enfocarse en tendencias de meses o años, como el crecimiento de la tabla de ruteo o la adopción de IPv6
  • Este análisis examina qué variaciones de corto plazo aparecen durante un día, en una situación en la que un router recibe directamente las actualizaciones BGP de una Internet en cambio constante
  • El objeto de observación se divide en tres ramas
    • El flujo típico de UPDATE durante un día
    • path attributes inusuales
    • flappy paths que cambian con frecuencia

Recolección de datos y bgpsee

  • En lugar de parsear directamente la salida de depuración de un router, se puso en estado funcional un demonio BGP que había quedado a medio hacer en el pasado y se usó bgpsee
  • bgpsee es una herramienta multihilo de peering BGP para CLI que, tras hacer peering con otros routers, parsea mensajes BGP y los imprime como JSON
    • Procesa mensajes OPEN, KEEPALIVE y UPDATE
    • Un UPDATE puede incluir path attributes como NLRI, withdrawn routes, ORIGIN, AS_PATH, NEXT_HOP y AS4_PATH
  • El dataset se recolectó entre el 6 de enero de 2024 y el 7 de enero de 2024, y consta de 464,673 BGP UPDATE recibidos desde un peer con la tabla BGP completa

Transferencia completa inicial y cantidad de rutas

  • Cuando se levanta por primera vez el peering BGP, todas las rutas de la tabla BGP del router y los NLRI relacionados se envían como un gran lote de UPDATE
  • Este lote inicial se recibió en unos 5 segundos desde el inicio del peering
  • Después de eso, solo llegan UPDATE sobre rutas modificadas o withdrawn routes que ya no tienen ruta
  • El lote inicial y los UPDATE posteriores son estructuralmente iguales; la diferencia está en el momento de recepción y el alcance
  • Aquí es importante distinguir entre path y route
    • Una path es una unidad de BGP UPDATE con una combinación de path attributes y sus NLRI asociados
    • Una path puede tener asociada una o mil routes
    • La cantidad de routes asociadas a todas las paths del lote inicial fue de 949,483

Flujo de UPDATE en intervalos de 30 segundos

  • Los UPDATE posteriores a la transferencia completa inicial no llegan como un stream en tiempo real, sino que se envían agrupados según el temporizador Route Advertisement Interval
  • En este peering, el Route Advertisement Interval fue de 30 segundos
  • La cantidad promedio de UPDATE observados fue la siguiente
    • IPv4: unas 50 actualizaciones de paths cada 30 segundos
    • IPv6: unas 47 actualizaciones de paths cada 30 segundos
  • Aunque los promedios fueron parecidos, IPv4 tuvo una mayor amplitud de variación
    • Desviación estándar de IPv4: 64.3
    • Desviación estándar de IPv6: 43
  • En vez de contar simplemente los UPDATE, también se calculó la cantidad total de espacio de direcciones IP que cambiaba cada 30 segundos
    • Se sumó la cantidad de direcciones IP incluidas en cada UPDATE y luego se aplicó log2()
    • El ejemplo consiste en convertir /22, /23 y /24 a cantidad de direcciones, sumarlas y luego tomar el logaritmo
  • Tomando como referencia el espacio de direcciones IPv4, en promedio unas 2^16 direcciones, es decir alrededor de un /16, cambiaban de path en la tabla de ruteo global cada 30 segundos
  • En el intervalo del 95%, el espacio de direcciones IPv4 que cambió estuvo aproximadamente entre 2^20.75 y 2^13.85
    • Esto corresponde aproximadamente a un rango entre /11 y /18

Ciclo de 40 minutos en las actualizaciones IPv4

  • Tanto en los cambios de cantidad de paths como en los del espacio de direcciones IP, los UPDATE de IPv4 mostraron un comportamiento cíclico
  • Para verificar el período se usó la función de autocorrelación (ACF)
    • Los UPDATE se agruparon en intervalos de 1 minuto, y 1 lag significa 1 minuto
    • Se calculó la correlación entre la cantidad de paths en el momento actual y la cantidad de paths en cada lag pasado
  • En los primeros 7 lags aproximadamente apareció una fuerte correlación
    • Esto encaja con el hecho de que un cambio de path puede propagarse por todo el mundo y generar otros cambios de path
  • También apareció una fuerte correlación en los lags 40 y 41, lo que confirmó un comportamiento de aproximadamente 40 minutos de período
  • La causa de este ciclo de 40 minutos queda como una pregunta sin responder

Casos de AS path prepending excesivo

  • Los administradores de red pueden usar varios métodos para ajustar cómo entra el tráfico a su ASN
    • Usar prefijos de red más largos no escala bien y tampoco es deseable desde el punto de vista de BGP
    • El atributo MED es non-transitive, por lo que tiene límites al hacer peering con varios AS
    • En general, se reduce la preferencia de una ruta mediante AS path prepending, agregando varias veces el propio AS delante para un peer específico
  • En el dataset, la longitud de AS path IPv4 más larga fue 105
    • Es un valor grande si se considera que la ruta más larga sin prepending tenía longitud 14
    • Esta ruta IPv4 se originó en AS149381, “Dinas Komunikasi dan Informatika Kabupaten Tulungagung”, de Indonesia
    • El NLRI 103.179.250.0/24 apareció el 6 de enero de 2024 a las 06:31:18 con una longitud de AS path de 105, y unas 6.84 horas después, a las 13:21:35, se actualizó a longitud 4
  • En IPv6, la longitud de AS path más larga llegó a 599
    • Un AS path se compone de uno o más AS set o AS sequence
    • Como la longitud máxima de cada AS sequence es 255, esta ruta necesitó tres AS sequence
  • En la ruta IPv6 más larga, quien hizo prepending no fue el originator, sino AS8772 NetAssist LLC, un ISP de Ucrania
    • El destino era una ruta hacia AS203868, Rifqi Arief Pamungkas, de Indonesia
    • AS8772 había hecho prepending para que esa ruta fuera menos preferida
  • Al observar la cantidad de ASN en todas las posiciones de las 50 rutas más largas, la gran diferencia entre IPv4 e IPv6 se relaciona con el uso repetido de un ASN específico

Valor reservado 255 observado en path attributes

  • Cada BGP UPDATE se compone de información de alcanzabilidad de capa de red y path attributes
    • Algunos ejemplos son AS_PATH y NEXT_HOP
  • La Sección 5 de RFC4271 divide los tipos de atributos BGP de la siguiente manera
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • Al observar la cantidad de atributos en todas las rutas IPv4, los atributos well-known mandatory ORIGIN, NEXT_HOP y AS_PATH aparecen en todos los UPDATE y con la misma cantidad
  • También se observaron atributos comunes como AGGREGATOR y atributos menos comunes como AS_PATHLIMIT y ATTR_SET
  • Algunos AS adjuntan el attribute 255 a los UPDATE
    • Este valor es un atributo reservado para desarrollo
    • En ese momento, bgpsee no guardaba el valor de estos path attributes poco comunes
  • A través de routeviews.org se pudo confirmar que algunos AS todavía anuncian rutas adjuntando este atributo, y también se observaron valores raw byte
    • Se ve attribute 255 en AS265999, AS10429 y AS52564
    • Los valores raw byte de los tres ISP tienen una estructura similar entre sí
  • No se pudo confirmar qué vendor está usando el atributo reservado para desarrollo ni con qué fin

El NLRI con más flapping

  • Entre las routes cuya path cambió o fue retirada completamente durante el día, se contabilizaron los NLRI principales incluidos más veces en UPDATE
  • Los 10 NLRI activos principales y la cantidad de veces que aparecieron en UPDATE son los siguientes
    • 140.99.244.0/23: 2,596
    • 107.154.97.0/24: 2,583
    • 45.172.92.0/22: 2,494
    • 151.236.111.0/24: 2,312
    • 205.164.85.0/24: 2,189
    • 41.209.0.0/18: 2,069
    • 143.255.204.0/22: 2,048
    • 176.124.58.0/24: 1,584
    • 187.1.11.0/24: 1,582
    • 187.1.13.0/24: 1,580
  • 140.99.244.0/23 fue el caso de mayor variación de ese día, y ese espacio de direcciones pertenece a EpicUp
  • Hubo 2,879 bloques de 30 segundos en total, y esta route apareció en 2,637 bloques como otra path o como withdrawn route
    • Proporción de aparición: {p:93}
    • La proporción real es 92.8%

Diversidad de peering mostrada por una ruta con flapping

  • Para ver cómo hacía flapping 140.99.244.0/23, se usó un grafo que toma como nodos los ASN de todas las paths hacia esa red y como aristas los pares de AS
  • Las rutas principales parecen ser rutas centrales que pasan por NTT AS2914 y Lumen/Level3 AS3356
  • La ruta se mueve entre estos ISP tier 1 y otros ISP
    • Como ejemplos se incluyen Arelion AS1299 y PCCW AS3419
  • Con estos datos por sí solos es casi imposible identificar la causa exacta del flapping
    • Se mencionan como posibles causas situaciones como un enlace defectuoso, un corte de energía o un crash de router
  • Al mismo tiempo, este caso muestra la diversidad de peering de las redes globales modernas y la resiliencia de un protocolo de ruteo de 33 años

Un dataset que deja más preguntas

  • Este dataset contiene demasiados temas por explorar, por lo que el análisis se enfocó en algunos casos
  • Los UPDATE de la tabla BGP global pueden reflejar eventos del mundo real, como inestabilidad política, fenómenos naturales como terremotos o incendios, o errores de administradores de red
  • La economía del peering de Internet y los factores humanos de operadores con distintas capacidades también están contenidos dentro de pequeños BGP UPDATE
  • BGP global funciona la mayor parte del tiempo y entrega muchos cambios del mundo real hasta una laptop como un pequeño stream de actualizaciones

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-11-27
Opiniones en Hacker News

  • Hace 25 años trabajaba en un ISP pequeño y, como al principio solo teníamos un ISP upstream, me tocó encargarme de la configuración multihome
    Aprendí con un tutorial escrito por Avi Freedman y, gracias a eso, pudimos obtener un /20 de ARIN y anunciar rutas a dos peers
    Fue muy interesante aprender cómo funcionaba y, mientras más entendía, más me sorprendía que Internet de alguna forma funcione
    (1) http://avi.freedman.net/
    Avi

    • ¡Gracias! Al igual que con el cuerpo humano, cuanto más estudias Internet, más sorprende no que a veces falle, sino que funcione en absoluto
      Sobre todo en cosas como video/telefonía, y me alegra que el contenido haya sido útil
      En avi.net dejé reunidos algunos enlaces a los tutoriales de esa época y a viejos artículos de Boardwatch
      La motivación fue simplemente la frustración con el material disponible en ese momento, pero pronto quedó claro que ayudar a la gente con buenos textos también traía recompensas como “¿podemos comprarte un T1?” o “¿quieres operar nuestra gran red global?”
      Por eso sigo recomendando escribir sobre temas que resultan confusos y frustrantes
    • Trabajé con Avi en Kentik; era una persona inteligente y buena, y tenía buenos recuerdos de haber escrito esos artículos para ayudar a la gente
    • Un poco fuera de tema, pero en HN a veces he visto que al final de un comentario queda una sola palabra en una línea nueva como esta
      Me pregunto si el comentario quedó cortado o si fue un error de copiar/pegar
      También me da curiosidad si otros lo han visto, o si podría ser una señal de comentarios generados o del uso de alguna herramienta específica
      Lo he visto principalmente en HN y creo que alguna vez también en Reddit; aparece con más frecuencia de la que esperaría si fuera pura casualidad o un simple error

  • Buen artículo, pero el flapping del prefijo 140.99.244.0/23 de EpicUp debería haber estado sujeto a route dampening
    Normalmente los ISP aplican límites de velocidad por peer o por prefijo para todos sus peers, para evitar que un solo prefijo represente una gran parte de los cambios BGP globales
    La correlación entre las actualizaciones que el autor interpreta como un efecto en cadena no es muy convincente
    Cambiar tus propios anuncios basándote en rutas hacia prefijos de otros sistemas autónomos, especialmente rutas inestables, es un diseño bastante tosco
    Tampoco creo que exista una periodicidad de 40 minutos. Al menos cuando trabajé a fondo con BGP hace 8 años no había algo así, y suena a que el dataset casualmente se veía de ese modo o a una característica de la red desde la que el autor recibía el feed BGP
    Si miras en los datos reales qué AS y prefijos cambian, están dispersos por todos lados y casi no hay grandes patrones
    En cualquier día hay algunos ISP ruidosos por problemas de enlaces o errores de configuración, prefijos que entran y salen al lanzar servicios nuevos por primera vez, y cambios de rutas por mantenimiento normal de drenaje
    Que una retroexcavadora corte una fibra en un ISP pequeño de Kansas y eso se vea en un router de Perth es fascinante y un poco aterrador, y al mismo tiempo, gracias a muchísimas políticas manuales, la frecuencia global de actualizaciones se mantiene por debajo de 10 Hz

    • En las redes actuales, el route dampening está mayormente pasado de moda
      Muchas configuraciones estaban muy mal hechas, y los routers ya no están tan extremadamente limitados por CPU como antes
      Claro que no desapareció por completo: cuando hice BGP Battleships (https://blog.benjojo.co.uk/post/bgp-battleships), 3356 aplicaba route dampening en ese momento, así que tuve que dejar de jugar por un rato

  • Si quieres aprender BGP, especialmente la operación cotidiana en escenarios de peering, la serie de videos del Network Startup Resource Center de la University of Oregon es buena
    https://learn.nsrc.org/bgp

  • Por lo que encontré rápidamente, el atributo BGP reservado 0xff probablemente sea una peculiaridad de Huawei
    La mayoría de los 0xff que se ven en bgp.tools siguen el mismo formato que aparece en el artículo, y algunas de esas redes parecen usar equipos Huawei

  • Aprendí bastante sobre BGP en este artículo, especialmente que lo más interesante es lo caótico que es su funcionamiento
    Me gustaría leer una continuación que profundice más

  • Hace tiempo diseñé y configuré una red híbrida satélite-microondas para un gran cliente estadounidense con oficinas de campo en la zona de Borneo
    No se me olvida cuando estábamos haciendo la entrega de un circuito arrendado en Jakarta
    Como no tenía experiencia en esto, busqué y encontré que BGP era lo que se usaba para conectar nuestra red OSPF/UBNT con la WAN corporativa IGRP/Cisco del cliente
    Cuando les pedimos a los de Tata que configuraran BGP en el router, su reacción fue: “¿quiénes se creen, AT&T?”
    Hasta que una temporada de tormentas eléctricas acabó con la mayoría de los AirFiber, nosotros también nos sentíamos un poco así

  • Hice un script en Python que extrae datos del archivo MRT con rutas BGP de [1] y los importa a Neo4j para explorarlos
    Ese archivo contenía unos 56 millones de rutas con una cantidad extrema de duplicados, y Neo4j es bueno para manejar estos datos mediante “merge”
    [1] https://data.ris.ripe.net/rrc00/

  • ¿Cuál es la forma más fácil para que una persona común acceda directamente a datos BGP? No conozco a nadie en un ISP, pero me gustaría hacer análisis similares

  • Si con el tiempo aparece algún comportamiento cíclico en las actualizaciones IPv4, tanto en los cambios de rutas como del espacio IP, ¿significa que Internet también tiene algo parecido a las mareas?

  • Ojalá la iniciativa Memory Safety, que aborda la seguridad y confiabilidad de infraestructura crítica de Internet reimplementándola en Rust, también se encargue de una implementación de servidor BGP
    [1] https://www.memorysafety.org/