Mostrando entradas con la etiqueta bgp. Mostrar todas las entradas
Mostrando entradas con la etiqueta bgp. Mostrar todas las entradas

viernes, 8 de marzo de 2024

BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP

04/03/2024


Por Alejandro Acosta, Coordinador de I+D en LACNIC

LACNIC presenta la primera página on line que muestra los incidentes y el análisis de datos de medición del Border Gateway Protocol (BGP) en América Latina y el Caribe.

PRINCIPALES SUCESOS. Además de sumarizar la información se aprecian los tres principales sucesos, los cuales son: posibles secuestros de red, interrupciones BGP y fugas de rutas.

Posibles secuestros de red es la adquisición ilegítima de grupos de direcciones IP al corromper las tablas de enrutamiento de Internet. Tradicionalmente ocurre cuando el Sistema Autónomo anuncia un prefijo que no le pertenece.

Interrupciones (outages) se refiere a la pérdida de visibilidad de prefijos de red por un grupo mayoritario de sensores[1] .

Fugas de rutas como su nombre lo indica, se refiere al anuncio -posiblemente- no intencional de algún prefijo de red vía BGP. Por ejemplo, un peering privado de intercambio de tráfico, alguno de los participantes anuncia el prefijo del peer a Internet. Este caso es el más difícil de detectar por los algoritmos y no consigue identificar algunas de éstas incidencias.

¿Cómo se obtienen los datos?

Esta iniciativa utiliza BGP Stream de Cisco, un proceso automatizado que selecciona los incidentes más grandes e importantes, qué tipo de situación es y cuáles ASNs están involucrados.

La información se publica de forma abierta ya que LACNIC considera que se trata de información importante para que ingenieros, responsables de redes y organizaciones puedan conocer los incidentes más comunes de la región y crear conciencia sobre la situación.

Ello permite la investigación eficiente de eventos, creación rápida de prototipos y de herramientas complejas y aplicaciones de monitoreo a gran escala (por ejemplo, detección de interrupciones de conectividad, ataques o secuestros de BGP).

En base a un sistema desarrollado por el área de I+D de LACNIC, se obtienen los datos de forma cruda, los parcela, identifica, limpia y almacena en una base de datos para posteriormente generar estadísticas y gráficas. Lo anterior ocurre cada 24 horas de forma automatizada.

RESULTADOS. Durante el período de tiempo estudiado -febrero 2023 a febrero 2024- nos encontramos con los siguientes resultados que se muestran en la siguiente gráfica comparando eventos BGP mundiales vs eventos BGP de nuestra región.

Comparando la gráfica mundial versus la gráfica de la región vemos que el orden de incidentes es similar (el mayor es outages, seguido por posibles secuestros de red y finalizando en fugas de prefijos).  Adicionalmente hay que destacar que en nuestra región las interrupciones (outages) son más frecuentes en comparación con el total mundial de eventos BGP. 

Al analizar la tabla resultados mostrando eventos BGP Mundiales vs eventos BGP de nuestra región, nos encontramos con los siguientes fatos.

TOP 5 países de nuestra región con Interrupciones BGP (Outages)

Outages 
CCEvents
BR781
AR99
HT24
MX22
CL17

TOP 5 países de nuestra región con secuestros de prefijos (Possible Hijacks)

Expected CCDetected CCEvents
BRBR67
BRnone35
PYBR24
BRUS22
BRCN9

TOP 3 países de nuestra región con fugas de rutas (Route Leaks)

Origin CCLeaker CCEvents
VEVE7
MXMX5
CLPA2

El impacto

En este primer año de funcionamiento desde LACNIC hemos observado una disminución de los incidentes BGP, entre los motivos de estos resultados podemos identificar: a) el despliegue y la adopción de Sistema de Certificación de Recursos (RPKI), b) el Registro de Enrutamiento de Internet de LACNIC (IRR) y la adopción del RFC 9234 (Roles en BGP).

La adopción de dichas herramientas se está dando por mejores prácticas de los operadores y el impulso de MANRS por ISOC.

Conclusiones

Los posibles secuestros de red (BGP Hijacks), interrupciones BGP (Outages) y fugas de rutas son los incidentes BGP más comunes. Durante el primer año de recopilación de datos, se observa una disminución de estos casos; sin embargo, en el futuro cercano no desaparecerán por completo. Es crucial implementar medidas robustas de redundancia y resiliencia en las redes, así como detectar y prevenir tempranamente posibles secuestros para garantizar la integridad y confiabilidad de las rutas de Internet.

En LACNIC, buscamos crear conciencia y motivar a los ISPs y organizaciones a estar preparados para abordar estos incidentes de manera eficiente cuando ocurran.

Referencias

https://stats.labs.lacnic.net/BGP/bgpstream-lac-region.html

https://stats.labs.lacnic.net/BGP/bgpstream.html

https://bgpstream.crosswork.cisco.com/ 

lunes, 19 de febrero de 2024

Inocentada: La verdad detrás del coqueteo de QUIC y BGP

Netland, 1707882300

Hoy tengo el honor de compartir con ustedes un secreto que he guardado celosamente durante mucho tiempo. Un secreto que, una vez revelado, cambiará nuestra percepción de la realidad y sacudirá los cimientos de nuestra sociedad. Permítanme llevarlos a un viaje a través de los pasillos oscuros de la red, celos, amor y el engaño, donde una verdad oculta ha estado esperando pacientemente para ser descubierta. Pasa en las películas, pasa en la vida, pasa en la red.
He esperado precisamente el día de los enamorados para contar sobre este  peculiar romance. Es muy duro y difícil de digerir para muchos profesionales de la red.  Relatar la historia de cómo TCP, el antiguo y confiable, conquistó el corazón de BGP, y cómo, tras décadas de lealtad, BGP ahora se encuentra coqueteando con.., correcto, con QUIC.

Acto I: Un poco de historia

Hace muchos años, en los albores de la red, TCP y BGP se cruzaron en un oscuro rincón de la topología. BGP, con su elegancia y sus enigmáticas tablas, cautivó a TCP. La conexión se estableció, y juntos construyeron una red resiliente. BGP admiraba la paciencia de TCP, su capacidad para esperar y retransmitir cuando las cosas se volvían difíciles.

Acto II: La famosa Rutina, ni en la red parece ser buena

Los años pasaron, y BGP y TCP se convirtieron en una pareja estable. La tabla de rutas de BGP creció, y TCP seguía transmitiendo sus paquetes con diligencia. Pero algo comenzó a cambiar. BGP miraba más allá de las fronteras de su dominio, de los firewalls y los IDPs. Había oído hablar de QUIC, un protocolo rápido y moderno que prometía una conexión más íntima y eficiente.

Acto III: El Coqueteo

BGP y QUIC comenzaron a encontrarse en conferencias y grupos de trabajo. Intercambiaban miradas furtivas en los paquetes de datos. QUIC, audaz y atrevido, le susurraba a BGP sobre su capacidad para sortear los problemas de latencia y congestionamiento. BGP, aunque leal a TCP, no podía evitar sentirse intrigado.

Acto IV: El secreto

Retomando el correo que les conté al comienzo que me llegó por error, me doy cuenta que  BGP le cuenta de todo a su tío, el viejo EGP
El texto decía lo siguiente: “QUIC es emocionante, ágil y tiene una forma de moverse que me resulta intrigante. Su naturaleza basada en UDP me hace sentir que puedo ser más libre y ágil, algo que no sucede con mi conexión tradicional a través de TCP.”,
Luego hay un pedazo que no se pudo recuperar y más adelante dice esto: “Tío, al principio, me resistí a los encantos de QUIC, aferrándome a la familiaridad y seguridad que me brinda TCP. Pero con el tiempo, no pude ignorar la energía y la emoción que QUIC aportaba a nuestra relación.”
Leer también:
Un necesario RFC sobre BGP: AS Path Prepending

Acto V: La Decisión

Y así, en esta temporada de enamorados, BGP se encuentra en una encrucijada. ¿Debería seguir con su relación estable con TCP, o debería aventurarse con QUIC? Las noches son largas mientras BGP reflexiona sobre su futuro. ¿Es posible amar a dos protocolos a la vez?

Acto VI: El pronóstico de los expertos

Algunos dicen que el amor no tiene edad ni fecha en el calendario, los expertos reconocen la historia de BGP y  TCP como profunda e intrigante. Todos concuerdan que  BGP es un protocolo caballeroso, muy serio y no creen que vaya a arriesgar su vida completa a su edad y con la gran responsabilidad que lleva consigo.

Acto VII: ¿Qué piensa TCP de estos rumores?

TCP con su gran experiencia no quiso expandir su respuesta, pero se limitó a decir:  “me siento dolida pero detrás de cada gran protocolo existe una gran acompañante, solo me queda decir que sería emocionante contemplar un futuro donde BGP pueda explorar nuevos horizontes con QUIC, por ello aquí estoy, la animaría a seguir adelante y darle una oportunidad al nuevo romance”


Att.

Rebif Citpo VI + Tniv Frec, Avaj, Cin, Pir, Lrep, Locotorp, Tan Tap, Lufetats

P.D. Es una inocentada, pero ojo, cuando el río suena, piedras trae: https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/

jueves, 1 de febrero de 2024

Un necesario RFC sobre BGP: AS Path Prepending

Introducción

Border Gateway Protocol (BGP) desempeña un papel fundamental en la construcción y mantenimiento de las tablas de enrutamiento en Internet, a tal punto que es considerado como el “pegamento” de Internet. En este contexto, una técnica de muchos años atrás y ampliamente popular conocida como “AS Path Prepending” se ha concebido como una estrategia clave para influir en la selección de rutas y la optimización del tráfico tanto entrante como saliente de un AS.

En el presente documento navegaremos a través del draft IETF “AS Path Prepending” [1], el cual recoge varias ideas y conceptos muy valiosos para la comunidad.


Sobre el Draft draft-ietf-grow-as-path-prepending

El Draft se encuentra en discusión dentro del Working Group GROW (Global Routing Operation) desde el año 2020, y actualmente se encuentra en su versión 10.

El draft cuenta con 7 autores: M. McBride, D. Madory, J. Tantsura, R. Raszuk, H. Li., J. Heitz y G. Mishra. En la lista de discusión este draft ha tenido mayoritariamente apoyo (incluido este humilde servidor). Puedes leerlo aquí.


¿Qué AS Path Prepending?

El AS Path Prepending es una técnica que implica la adición repetitiva del identificador de sistema autónomo (ASN) propio a la lista de ASs en el camino de una ruta BGP (AS_PATH). Su objetivo es influir en la selección de rutas, haciendo que ciertos caminos sean menos atractivos para el tráfico entrante/saliente. En otras palabras, es agregar nuestro sistema autónomo en el AS_PATH y así artificialmente “alejar un prefijo” en Internet.


En el gráfico anterior sin prepends, Router A prefiere ir a C a través de B; sin embargo debido a 3 prepends agregados en B, router A decide alcanzar C a través de D.


¿Para qué y por qué se hace AS PATH Prepending?

Existen muchas razones por las cuales se hace AS PATH prepending. La principal razón indiscutiblemente sería por ingeniería de tráfico la cual a su vez recae en el deseo de influenciar el tráfico entrante y saliente al AS. Es muy probable que el AS desee lograr alguno de los siguientes objetivos:

  • distribución de tráfico entre dos o más upstream providers
  • tener algún upstream provider de backup
  • Sea cual sea el caso, una vez más el objetivo es ingeniería de tráfico.


Hacer prepend o no hacer prepend, he ahí el dilema

Hacer prepend se parece un poco al NAT, es un mal muchas veces necesario.

Como explicaremos, su uso excesivo y a veces innecesario puede convertirse en una vulnerabilidad con implicaciones significativas para la estabilidad de las redes.


¿Qué tiene de malo hacer AS Path Prepending?

Todos sabemos que hacer AS Path Prepending es una técnica muy común para influenciar las decisiones de BGP, sin embargo, el excesivo/mal/ y a veces innecesario uso puede traer resultados negativos. Por ejemplo:

  • crear un tráfico subóptimo, es decir, quizás en los enlaces inmediatos logremos nuestro objetivo de una distribución de tráfico, sin embargo, mas alla de tu upstream inmediato el tráfico no se encuentre optimizado para alcanzar nuestro sistema autónomo y viceversa;
  • desagregación de prefijos, es muy normal que al momento de querer hacer una ingeniería de tráfico se proceda a desagregar prefijos afectando así el ecosistema de Internet;
  • en caso de algun route-leak (fuga de ruta), en condiciones normales nuestras publicaciones tenderían a tener un as-path más corto que el leak, pero si alargamos artificialmente el path haciendo prepend es posible que las rutas fugadas tengan un as-path más corto que las que estamos anunciando legítimamente de nuestro prefijo -legítimo- tendrá menos preferencia en Internet trayendo consigo posibilidades de secuestro de rutas, ataques, y un largo etcétera;
  • memoria: como es de esperarse, estos AS Path Prepends son aprendidos por los BGP Speakers consumiendo su memoria. A esto yo también le sumaría a cada prefijo un pequeño consumo de CPU adicional.


Si no recomiendan hacer AS Path Prepend, ¿qué puedo hacer?

Existen muchas técnicas para realizar ingeniería de tráfico en BGP.  menciono algunas que aparecen en el draft:

  • considera aprovechar las comunidades BGP. Además de las comunidades BGP ampliamente reconocidas, te recomiendo que dialogues con tus pares BGP para optimizar el tráfico. Existen numerosas comunidades BGP implementadas por proveedores, las cuales seguramente podrían beneficiar tu configuración
  • Puedes realizar anuncios más específicos hacia tus upstream principales
  • Manipular el AS Origin Code; recordemos que este atributo también se encuentra en el algoritmo de selección de rutas de BGP
  • Usar MED (Multi Exit Discriminator), un atributo no transitivo, excelente para manipular el tráfico entrante cuando tenemos varios enlaces hacia el mismo proveedor
  • Local Preference, otro atributo no transitivo, perfecto para influenciar el tráfico que sale de nuestro sistema autónomo


Todo muy bien, pero aún necesito hacer AS Path Prepend, ¿alguna sugerencia?

El draft menciona las mejores prácticas al momento de realizar prepends, aquí te resumo las mismas:

  • solo hacer AS Path Prepend cuando sea imprescindible;
  • debido a algunas técnicas de manipulación de tráfico puede ocurrir que al hacer AS Path Prepend no veamos cambios significativos en la distribución del tráfico, por ello es importante conversar con nuestros pares y saber si ellos respetan los prepends;
  • utilizar Local Preference en nuestra red;
  • no realizar prepends con números de ASs que no son nuestros;
  • no hacer prepend si eres single home (esta no está en el draft);
  • si realizamos preprends de algún prefijo quizás no es necesario colocar ese prepend hacia todos mis peers;
  • no hay necesidad de colocar más de 5 prepends. El motivo es que más del 90% de los destinos se encuentran a 5 o menos ASs de distancia.




(imagen tomada de: https://www.potaroo.net/ispcol/2019-10/prepending.pdf)


Consideraciones finales:

El uso de AS_PATH Prepending es una estrategia valiosa pero debe ser utilizada sólo cuando es necesario y de una manera precavida siguiendo las mejores prácticas. El uso excesivo de prepends puede ocasionar imprevistos a nuestro sistema autónomo desde la perspectiva de tráfico como de seguridad.

Te invitamos a leer el draft completo aquí, y sumarte a la discusión en la lista de LACNOG

Además, te animamos a dejarnos un comentario en este post, para contarnos si haces prepending de tu ASN, por qué y para qué lo usas.


Referencias:

[1] https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ 

martes, 5 de diciembre de 2023

BGP: Ejemplo IPv6 Only entre FRR y OpenBGPD

FRR:

show run

frr# sh run 

Building configuration...


Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!



OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates


# global configuration

AS $ASN

router-id 2.2.2.2


network 2001:db8::2/128

network inet6 connected


neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}


deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1


#

(por favor notar el espacio en blanco entre la última línea y la antepenúltima línea)

sábado, 10 de junio de 2023

Análisis de 7 variables BGP en la región durante el 2022

Contexto de este análisis: Un poco de historia

Internet es un ambiente que cambia, incluso minuto a minuto, segundo a segundo. Cambian las rutas, cambian los sistemas autónomos. Todo esto hace al ecosistema de Internet más divertido e interesante.

Muchos de los que leemos diferentes listas de correo probablemente estemos acostumbrados a recibir un email los viernes llamado: “Weekly Global IPv4 Routing Table Report”, generado por Phillips Smith de NSRC (Network Startup Research Center). Lo cierto es que en ese correo envían datos muy valiosos sobre BGP y el mundo IPv4. Desde LACNIC nos preguntamos ¿qué podemos hacer con esa información? Y la respuesta fue: ¡vamos a procesarla!

Con todo esto en mente, construimos un parser para rescatar diferentes variables en el mundo de BGP de la lista de correo de LACNOG [1] con la intención de construir un histórico de diferentes variables en el mundo BGP que abarque varios años. Con esta información nos preguntamos ¿Cuánto cambiaron las estadísticas de BGP en nuestra región durante el 2022? Aquí te damos la respuesta.


Los datos utilizados

Los datos utilizados para el presente análisis son tomados exclusivamente de la lista de correo de LACNOG en: https://mail.lacnic.net/mailman/listinfo/lacnog, filtrado por los emails con el título: “Weekly Global IPv4 Routing Table Report”


Alcance

Este análisis abarca únicamente el área de cobertura de LACNIC durante el periodo que comprende desde el 1 de enero al 31 de diciembre de 2022. Es importante destacar que los datos son exclusivamente en el ámbito de IPv4.


Las variables estudiadas fueron:

  •     Prefijo anunciado por los AS de la región de LACNIC
  •     AS de origen de la región de LACNIC presentes en la tabla de enrutamiento de Internet
  •     AS de origen de la región de LACNIC que anuncian un solo prefijo
  •     AS de la región de LACNIC que brindan tránsito y que están presentes en la tabla de enrutamiento de Internet
  •     Número de direcciones de LACNIC anunciadas a Internet
  •     Factor de desagregación de LACNIC
  •     Prefijos de LACNIC por ASN


¿Por qué estas variables?

Las variables expresadas anteriormente son las que consideramos principales debido a que representan el estado de BGP en algún momento determinado, con las mismas y colocándolas en una línea de tiempo podemos conocer con precisión cambios importantes en nuestra región y a su vez, muchas de las otras variables mencionadas en el informe semanal son una sencilla matemática de las que ya tenemos.


Ejemplo de los datos procesados (tomado [2])

Resumen de datos de la región de LACNIC

——————————

Prefixes being announced by LACNIC Region ASes: 117404

Total LACNIC prefixes after maximum aggregation: 28499

LACNIC Deaggregation factor: 4.12

Prefixes being announced from the LACNIC address blocks: 116794

Unique aggregates announced from the LACNIC address blocks: 48887

LACNIC Region origin ASes present in the Internet Routing Table:  10986

LACNIC Prefixes per ASN: 10.63

LACNIC Region origin ASes announcing only one prefix: 2672

LACNIC Region transit ASes present in the Internet Routing Table:  2278

Average LACNIC Region AS path length visible: 4.9

Max LACNIC Region AS path length visible: 55

Number of LACNIC region 32-bit ASNs visible in the Routing Table:  8784

Number of LACNIC addresses announced to Internet: 176436224

Equivalent to 10 /8s, 132 /16s and 52 /24s

LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-273820 + ERX transfers

LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8,


Procesamiento de los datos 

Los datos fueron procesados en su totalidad utilizando Python3 sobre Linux. Particularmente la librería beautifulsoup [3] fue muy útil para realizar el scraping de la lista de correo. Las gráficas son generadas por Google Charts a través de su API.


Resultados:

  •     Prefijo anunciado por los AS de la región de LACNIC












Este indicador expresa el número de prefijos anunciados a Internet por sistemas autónomos de LACNIC. Muestra un crecimiento ligero pero constante, el mismo tuvo un alza de 5%, aumentando 5.857 prefijos en un periodo de 364 días, comenzando el 1 de enero de 2022 con 111.641 y finalizando el 31 de diciembre del mismo año en 117.498 prefijos.

  • AS de origen de la región de LACNIC presentes en la tabla de enrutamiento de Internet



Este indicador representa la cantidad de sistemas autónomos asignados por LACNIC que son visibles en la tabla global de Internet (DFZ – Default Free Zone). Se aprecia una gráfica muy constante, con un muy leve crecimiento de apenas 1%, aumentando 117 ASs en un periodo de 364 días, comenzando el 1 de enero de 2022 con 10.893 y finalizando el 31 de diciembre del mismo año en 11.010.


  • AS de origen de la región de LACNIC que anuncian un solo prefijo


Esta variable indica la cantidad de sistemas autónomos asignados por LACNIC que anuncian sólo un prefijo a la tabla global de Internet (DFZ – Default Free Zone). A pesar de parecer senoidal, las variaciones en esta gráfica tampoco son tan marcadas (se puede apreciar observando el eje de las Y y su escala). Fue un valor muy estable durante todo el año y al final tuvo una pequeña alza de 0,2%, aumentando 6 ASs que anuncian sólo un prefijo en un periodo de 364 días, comenzando el 1 de enero de 2022 con 2662 y finalizando el 31 de diciembre del mismo año en 2668.

  • AS de la región de LACNIC que brindan tránsito y que están presentes en la tabla de enrutamiento de Internet





Esta interesante variable expresa la cantidad de ASs en la región de LACNIC que realizan tránsito a otro AS;la misma tuvo un crecimiento de 4,2%, con una añadidura de 92 ASs de LACNIC que realizan tránsito a otro AS en un periodo de 364 días, comenzando el 1 de enero de 2022 con 2188 y finalizando el 31 de diciembre del mismo año en 2280.

  • Número de direcciones de LACNIC anunciadas a Internet


Este valor indica la cantidad de direcciones IPv4 únicas asignadas por LACNIC que son visibles en la tabla global de enrutamiento (DFZ – Default Free Zone). La cantidad de direcciones IPv4 visibles tuvo un decrecimiento de 0,3% disminuyendo en 447488 direcciones. Para el 1 de enero de 2022 fueron visibles 176521472 direcciones y para el 31 de diciembre del mismo año 176073984.

  • Factor de desagregación de LACNIC


El factor de desagregación puede sonar complicado, pero a su vez es un valor a tener muy en cuenta. Este es el típico caso donde menos quiere decir más.  En esta oportunidad la región de LACNIC termina el año (31/Dic/2022) con un factor de desagregación de 4.13 comenzando con 4.09 (1/Enero/2022), lo que significa que ocurrió un aumento de 0,04. Un factor de desagregación más alto implica que se están anunciando más prefijos específicos para la dirección de destino/padre, lo que puede proporcionar una granularidad y precisión mayores en las decisiones de enrutamiento. Sin embargo, un factor de desagregación más alto también puede llevar a un aumento en los requisitos de memoria y procesamiento para los routers. Lo ideal en este caso es que los operadores de red revisen sus anuncios y que no realizar anuncios sin necesidad, por ejemplo, minimizar el subnetting en el anuncio.


Para que veamos el impacto, una red con 10.000 anuncios y con un factor de 4 de desagregación, en el caso utópico que lleven el factor 1, tan solo tendría 2.500 anuncios.


  • Prefijos de LACNIC por ASN




Este valor representa la cantidad de prefijos promedios que realizan los AS de la región de LACNIC, una variable sin mayores variaciones durante todo el año.  Tuvo un crecimiento de 0,48% aumentando de 10,32 a 10,8 prefijos promedio por ASs.

Conclusiones:

A continuación, se presentan las conclusiones principales:
  •     Se observa un crecimiento constante de un 5% de los prefijos anunciados a Internet por sistemas autónomos de LACNIC durante 2022 (de 111.641 a 117.498)
  •     El número de sistemas autónomos asignados por LACNIC que son visibles en la tabla global de Internet muestra una gráfica constante con un leve crecimiento del 1%. Durante el año, se incrementaron en 117, pasando de 10,893 a 11,010 ASes.
  •     Estabilidad en los ASes de origen de LACNIC que anuncian solo un prefijo: La cantidad de sistemas autónomos asignados por LACNIC que anuncian únicamente un prefijo a la tabla global de Internet se mantuvo relativamente estable a lo largo del año. Hubo un aumento del 0.2%, pasando de 2,662 a 2,668 ASes que anuncian solo un prefijo.
  •     Se aprecia un crecimiento del 4.2% en la cantidad de sistemas autónomos que realizan tránsito a otros sistemas autónomos. Durante el año, se agregaron 92 ASes de LACNIC que realizan tránsito, pasando de 2,188 a 2,280.
  •     En cuanto a la cantidad de direcciones IP visibles en la DFZ y teniendo en cuenta que no son prefijos sino números de IP podríamos decir que se mantiene estable. La disminución es despreciable. Quizás la conclusión principal es que no han aumentado pese al agotamiento, lo que daría a entender que no hay nuevos bloques que se hayan comenzado a anunciar
  •     El factor de desagregación se mantuvo sin casi variaciones, pero tuvimos al final un aumento pequeño, como se mencionó anteriormente esto no es positivo para el ecosistema de Internet.

Referencias:

[1] https://mail.lacnic.net/mailman/listinfo/lacnog

[2] https://mail.lacnic.net/pipermail/lacnog/2023-March/009429.html

[3] https://pypi.org/project/beautifulsoup4/

[4] https://stats.labs.lacnic.net/BGP/ParserWeeklyBGPUpdate/ParserWeeklyBGPUpdate.html

[5} Github del parser: https://github.com/LACNIC/WeeklyParserForBGPStats


viernes, 4 de noviembre de 2022

Un cambio interesante se avecina en BGP

Sobre la fugas de rutas

Una fuga de rutas (route leaks) se define como la propagación de un anuncio más allá del alcance previsto (RFC 7908). Pero, ¿por qué ocurren? Existen muchas razones tales como  errores (alguien digita mal un número), desconocimiento, falta de filtros, ingeniería social, entre otras.


Si bien existen varias formas de prevenirlo y en los últimos 3 años la cantidad de fugas de rutas ha disminuido  (gracias a RPKI, IRR y otros mecanismos), mi idea es explicarles lo que pienso va a ser en el futuro las configuraciones en BGP. Y para eso hablaremos del RFC 9234, cuyo título es Prevención de fuga de rutas y detección de roles utilizando mensajes UPDATE y OPEN. De este concepto me interesa destacar la “detección de roles”, ya que a partir de este  RFC, en el futuro vamos a asignar roles en nuestra configuraciones BGP.


Para ir comprendiendo a qué queremos llegar recordemos algunos casos típicos en un ISP: 


  • Llega un cliente nuevo con el cual hablaremos BGP;
  • Se conecta a un IXP;
  • El ISP contrata un nuevo upstream provider;
  • Realizaremos un nuevo peering privado.

En todos esos casos es necesario tomar decisiones. Hay muchas maneras de configurar BPG: route maps, AS filters, prefix-lists, comunidades, ACLS, entre otros. Incluso puedo estar usando más de una de estas opciones.  


Y aquí es donde aparece el RFC 9324: este documento define los roles dentro del mensaje Open. Se trata de un acuerdo al que van a llegar los dos enrutadores. Por ejemplo, si yo soy un enrutador y converso con otro, le digo que soy “cliente” y él en su sesión BGP puede decir “yo soy tu proveedor”. En base a eso todas las configuraciones (léase filtros) se harán de forma automática y, en consecuencia, esto debería disminuir los route leaks.


Estas capacidades entonces se negocian en el mensaje Open de BGP.


En el RFC se definen 5 roles:


Proveedor: el emisor es un proveedor de tránsito para el vecino;

Cliente: el emisor es un cliente de tránsito del vecino;

RS: el emisor es un servidor de rutas (route server), generalmente en un punto de intercambio de tráfico (IXP);

Cliente RS: el emisor es cliente de un RS;

Peer: el emisor y el vecino son peers.

¿Cómo se configuran los roles?

Si por ejemplo tengo un router con una sesión BGP contra alguien y de un lado está el provider, del otro lado tiene que estar customer, y viceversa. Si tengo un Route Server (RS) de un lado, del otro lado debo tener un cliente route server y viceversa; y peer contra peer (ver tabla)





A continuación, podemos ver un ejemplo



Capacidades BGP

Las capacidades BGP son lo que el enrutador anuncia a sus peers BGP para informarles qué características puede admitir y, si es posible, intentará negociar esa capacidad con sus vecinos. Un router BGP determina las capacidades admitidas por su peer examinando la lista de capacidades presentes en las capacidades transportadas por el mensaje OPEN. Podríamos compararlo con dos personas políglotas que se encuentran: uno habla inglés español y portugués, y el otro francés, chino e inglés. El idioma común en el que coinciden es el inglés, por lo que se comunicarán en ese idioma. Pero no lo harán en francés, ya que solo una de ellas lo habla. Eso es lo que básicamente ha permitido que BGP haya crecido tanto y el impacto en nuestras redes ha sido muy pequeño, porque tiene esos conceptos de compatibilidad hacia atrás (backward compatibility) que funcionan perfectamente.


Este RFC añadió una nueva capacidad




¿Funciona este código? Totalmente; aquí un ejemplo:




Modo estricto

En general las capacidades se negocian entre los BGP Speakers y se utilizan exclusivamente las que ambos soportan. Strict Mode es una opción que, en el caso que se configure, ambos enrutadores deberán soportar esta capacidad.


Conclusión

En conclusión, creo que la manera como el RFC 9234 hace las cosas será el futuro de la configuración BGP a nivel global, reemplazando y mejorando notablemente la fuga de rutas y anuncios indebidos en Internet. Facilitará las configuraciones en BGP, y será un complemento a RPKI e IRR en el tema de fugas de rutas, y en que las tablas de enrutamiento se encuentren más limpias.


Puedes ver la presentación completa en el marco de LACNIC 38 LACNOG 2022 aquí

miércoles, 21 de septiembre de 2022

HowTo: Como levantar un peering en IPv6 Only v1.0

Introducción

  El siguiente artículo presenta de manera ordenada los pasos a seguir para levantar un peering BGP entre dos routers IPv6 Only.


  En el argot de BGP peering se conoce como ( traducido de [1]):


“Dos enrutadores que han establecido una conexión para intercambiar información BGP se denominan pares BGP. Dichos pares BGP intercambia información de enrutamiento entre ellos a través de sesiones BGP ….. “


Prerrequisitos

  • Dos enrutadores

  • Conectividad entre los enrutadores

  • Soporte IPv6 en ambos equipos tanto en conectividad como en BGP


Topología









Para Enrutador R1:

  • IPv6 de R1: 2001:db8:12::1/64  

  • Router-ID de R1: 10.111.111.1

  • Prefijo v6 que será anunciado por R1: 2001:db8:1::/48

  • IPv6 /128 de Loopback:  2001:db8:1:11::cafe/128


Para Enrutador R2:

  • IPv6 R2: 2001:db8:12::2/64

  • Router-ID de R2: 10.222.222.2

  • Prefijo v6 que será anunciado por R2: 2001:db8:2::/48

  • IPv6 /128 de Loopback:  2001:db8:2:11::cafe/128



Pasos a seguir

Paso 1 - Conectividad IPv6 entre los enrutadores

Para establecer y probar la conectividad entre los enrutadores debemos:

  1. Establecer la conexión física:

    • Asegurarse que esté realizada la conexión física entre las interfaces asignadas de ambos enrutadores.

    • Verificar que dicho enlace esté UP.

  2. Configurar IPv6 en las interfaces relacionadas:

    • Asignar el direccionamiento IPv6 de WAN que se utilizará en el enlace. Todo el direccionamiento utilizado en este documento pertenece al segmento 2001:db8::/32 reservado para documentación.

    • Configurar IPv6 en las interfaces relacionadas.

  3. Probar conectividad IPv6:

    • Realizar un Ping IPv6 desde alguno de los dos equipos.

    • Si no se puede alcanzar es imprescindible arreglar esta situación antes de continuar.

    • Es posible que el destino esté filtrando los paquetes de Ping IPv6 (ICMPv6 Echo Request/Reply y eso no implica que no vaya a funcionar BGP; verificar en el otro equipo.


Nota: BGP por defecto piensa que su vecino se encuentra directamente conectado, es decir, el vecino es el siguiente dispositivo en la red. En caso de no ser así se puede requerir mayor configuración tal como eBGP Multihop [2], pero este tema no lo cubriremos en este howto.


Cisco (IOS-15.4)

R1

Estado de Interfaz:

R1#sh int et0/0

Ethernet0/0 is up, line protocol is up 

  Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)


Configuración de Interfaz:

interface Ethernet0/0

 description ## R1 to R2 ##

 no ip address

 ipv6 address 2001:DB8:12::1/64

 ipv6 nd ra suppress #recomendado, no envía mensajes de RA




R2

Estado de Interfaz:

R2#sh int et0/0    

Ethernet0/0 is up, line protocol is up 

  Hardware is AmdP2, address is aabb.cc00.0200 (bia aabb.cc00.0200)


Configuración de Interfaz:

interface Ethernet0/0

 description ## R2 to R1 ##

 no ip address

 ipv6 address 2001:DB8:12::2/64

 ipv6 nd ra suppress


Prueba de conectividad:

R2#ping ipv6 2001:DB8:12::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:12::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/6 ms

R2#

R2#sh ipv6 neighbors 

IPv6 Address                              Age Link-layer Addr State Interface

2001:DB8:12::1                              0 aabb.cc00.0100  REACH Et0/0

FE80::A8BB:CCFF:FE00:100                   12 aabb.cc00.0100  STALE Et0/0


¿Crear la sesión BGP entre direcciones Link Local (LLA) o Global Unicast Addresses (GUA)?

En algunas ocasiones tendremos que tomar la decisión de cómo crear la sesión BGP, existen 3 posibilidades: 

  • Utilizar direcciones Link Local (LLA), 

  • Utilizar direcciones globales (GUA),

  • Utilizar direcciones ULA (Unique Local Address). 

Las primeras dos opciones son las más comúnmente utilizadas. 


Entonces, ¿qué utilizo para crear la sesión BGP?. 


Te daremos una respuesta directa, sin embargo queremos realizar la explicación como es debido. 

Repasa estas premisas:


  1. Recordemos que los mensajes BGP contienen atributos, siendo uno de ellos el atributo NextHop [3]. Este atributo contiene una información muy sencilla: el salto que se debe utilizar para alcanzar un destino. 

  2. Un router (un eBGP Speaker) al aprender un prefijo de otro AS copia el atributo de nexthop hacia su red iBGP.

  3. Una red de speakers iBGP tradicionalmente tendrá un IGP.

  4. Las direcciones Link Local tienen alcance local, tan solo el propio bus de la red, la LAN, el SSID, etc. No pueden ser enrutadas.



Quizás ya en este momento te has respondido que utilizar :-)  

Nuestra recomendación es crear la sesión BGP sobre GUA y ahora que repasamos las premisas es fácil responder con una pregunta:  ¿Cómo un eBGP speaker va a copiar una dirección Link Local en el nexthop hacia sus iBGP speakers?.   Sencillo, no puede (claro, existen algunos trucos pero no lleguemos hasta ello).


Paso 2 - Definir el Router-ID en los diferentes routers

Debido a que estamos hablando de equipos IPv6 Only, asumimos que los dispositivos no tendrán direccionamiento IPv4. ¿Qué tiene que ver?

Explicamos brevemente:

  • ¿Para qué un router-id?. El router-id es un campo de 32 bits que viaja en el mensaje OPEN de BGP, dicho campo (llamado BGP Identifier) es obligatorio y se representa en un formato de dirección IPv4.

  • Los enrutadores tienen un mecanismo para obtener su router-id. 

  • Si el router es IPv6 Only el equipo no podrá averiguar su router-id

  • Si el router no puede averiguar su router-id el administrador debe configurar uno explícitamente dentro del proceso BGP. 


Paso 3 - Realizar las configuraciones en los routers

Vamos a mostrar dos ejemplos: Mikrotik y Cisco.Podremos darnos cuenta que la información es exactamente la misma, lo que cambia es la manera y comandos del sistema operativo. En el caso de Mikrotik utilizaremos la versión 6.x. 

Configuración en routers

Mikrotik (RouterOS v6)

Enrutador R1


Configuración de la interfaz loopback

/interface bridge add name=loopback protocol-mode=none disabled=no

/ipv6 address add address=2001:db8:1:11::cafe/128 advertise=no interface=loopback


Configuración del proceso/instancia BGP

/routing bgp instance add name=AS65001 as=65001 router-id=10.111.111.1


Configuración del Peer

/routing bgp peer add name=HACIAR2 instance=AS65001 remote-address=2001:db8:12:2 remote-as=65002 address-families=ipv6


Anuncio de prefijo

routing bgp network add network=2001:db8:1::/48 synchronize=no


Enrutador R2

Configuración de la interfaz  loopback

/interface bridge add name=loopback protocol-mode=none disabled=no

/ipv6 address add address=2001:db8:2:11::cafe/128 advertise=no interface=loopback


Configuración del proceso/instancia BGP

/routing bgp instance add name=AS65002 as=65002 router-id=10.222.222.2


Configuración del Peer

/routing bgp peer add name=HACIAR1 instance=AS65002 remote-address=2001:db8:12:1 remote-as=65001 address-families=ipv6


Anuncio de prefijo

routing bgp network add network=2001:db8:2::/48 synchronize=no

Revisar la sesión BGP/Troubleshooting


Desde R2


Es importante que la letra “E” aparece en la salida, la misma indica que la sesión BGP se encuentra establecida correctamente




Cisco (IOS-15.4)

Habilitar IPv6

Antes de comenzar con la configuración de BGP, en algunas versiones de IOS, es necesario primero habilitar:

  • ipv6 unicast-routing: Habilita el enrutamiento de paquetes IPv6.

  • ipv6 cef: Habilita Cisco Express Forwarding para paquetes IPv6 de esta manera el procesamiento de dichos paquetes se realiza en Hardware, sino se realizaría en Software impactando directamente en la CPU del equipo.


R1#configure terminal #entramos en modo configuración

R1(config)#

R1(config)#ipv6 unicast-routing 

R1(config)#ipv6 cef


R1

Entramos en Modo Configuración:

R1#configure terminal

R1(config)#


Configuramos la interface Loopback0:

R1(config)#interface loopback 0 #configuración de la interfaz loopback

R1(config-if)#ipv6 address 2001:db8:1::1/128 #dirección ipv6 de la interfaz loopback

R1(config-if)#exit

R1(config)#


Configuramos BGP:

R1(config)# router bgp 65001 #creamos el proceso de BGP con el ASN

R1(config-router)# bgp router-id 10.111.111.1 #definimos el router-id

R1(config-router)# no bgp default ipv4-unicast #desactivar la configuración default de un neighbor en el AF IPv4

R1(config-router)#neighbor 2001:DB8:12::2 remote-as 65002 #definimos el neighbor

R1(config-router)# address-family ipv6 #entramos en el AF de IPv6

R1(config-router-af)#  neighbor 2001:DB8:12::2 activate #activamos el neighbor en este AF

R1(config-router-af)#  network 2001:DB8:1::/48 #prefijo a ser anunciado

R1(config-router-af)#exit

R1(config-router)#exit

R1(config)#ipv6 route 2001:db8:1::/48 Null0 #Cisco necesita que el prefijo a ser anunciado se encuentre en la tabla de enrutamiento


R1(config)#exit

R1#


R2

Entramos en Modo Configuración:

R2#configure terminal

R2(config)#


Configuramos la interfaz Loopback0:

R2(config)#interface loopback 0

R2(config-if)#ipv6 address 2001:db8:2::1/128

R2(config-if)#exit

R2(config)#


Configuramos BGP:

R2(config)#router bgp 65002

R2(config-router)# bgp router-id 10.222.222.2

R2(config-router)# no bgp default ipv4-unicast

R2(config-router)# neighbor 2001:DB8:12::1 remote-as 65001

R2(config-router)# address-family ipv6

R2(config-router-af)#  neighbor 2001:DB8:12::1 activate

R2(config-router-af)#  network 2001:DB8:2::/48

R2(config-router-af)#exit-address-family 

R2(config-router)#exit 

R2(config)#ipv6 route 2001:db8:2::/48 Null0 #Cisco necesita que el prefijo a ser anunciado se encuentre en la tabla de enrutamiento


R2(config)#exit

R2#

Revisar la sesión BGP/Troubleshooting

show bgp ipv6 unicast summary

Con este comando podemos revisar los peers existentes. Un indicador de que la sesión BGP se encuentra levantada es revisar la columna “State/PfxRcd” y revisar que contenga un número. Dicho número indica la cantidad de prefijos recibidos. En nuestro caso esperamos recibir 1 prefijo (la IPv6 de la interfaz loopback del neighbor):


R1#show bgp ipv6 unicast summary                 

BGP router identifier 10.111.111.1, local AS number 65001

BGP table version is 3, main routing table version 3

2 network entries using 328 bytes of memory

2 path entries using 208 bytes of memory

2/2 BGP path/bestpath attribute entries using 288 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 848 total bytes of memory

BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs


Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

2001:DB8:12::2  4        65002      14      13        3    0    0 00:08:39        1

R1#


show bgp ipv6 unicast

Con este comando se puede observar la tabla BGP IPv6 del equipo e identificar detalladamente los prefijos aprendidos.

R1#show bgp ipv6 unicast 

BGP table version is 3, local router ID is 10.111.111.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found


     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:DB8:1::/48  ::                       0         32768 i #prefijo IPv648 local

 *>  2001:DB8:1::/48  2001:DB8:12::2           0         0 65002 i #prefijo IPv6 remoto

R1#

Verificar conectividad end-to-end

Luego de que estamos seguros de que ambos routers aprenden correctamente el prefijo del vecino podemos verificar la conectividad IPv6 entre las IPs de las Interfaces Loopback en ambos extremos:


Ping desde R1:

R1#ping ipv6 2001:db8:2::1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:2::1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/5 ms

R1#


Chequeo de Conectividad PING6 de R1 a R2, a nivel de las IPv6 de Loopback

Un aspecto interesante de Mikrotik es que para hacer PING (IPv4) y PING6 (IPv6) se utiliza el mismo comando y Mikrotik identifica la IP destino y procede a realizar el PING ó PING6 de acuerdo al protocolo correspondiente. En otros routers, esto no ocurre y hay que explicitar que el PING es IPv6 usando comandos distintos como ‘ping6’ (Cisco Nexus) ó ‘ping ipv6’. 

[admin@R1] > /ping 2001:db8:2:11::cafe src-address=2001:db8:1:11::cafe count=4

  SEQ HOST                                     SIZE TTL TIME  STATUS                                             

    0 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    1 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    2 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    3 2001:db8:2:11::cafe                       56 123 0ms   echo reply                                         

    sent=4 received=4 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms 




Ejemplo Filtros Básicos en BGP

En esta sección mostraremos un ejemplo básico de como realizar filtros salientes y entrantes en BGP.


Se configuran los siguientes filtros para que solo se propaguen los direccionamientos de las Interfaces Loopback0 de ambos routers:

  • Filtro saliente en R1 permitiendo anunciar solo su Loopback0 a R2.

  • Filtro entrante en R2 permitiendo recibir solo la Loopback0 de R1.

  • Filtro saliente en R2 permitiendo anunciar solo su Loopback0 a R1.

  • Filtro entrante en R1 permitiendo recibir solo la Loopback0 de R2.


Conceptos previos a la configuración:

  • Prefix-List:

    • Las Listas de Prefijos se utilizan para definir los prefijos a utilizar en el filtro.

    • En nuestro caso utilizaremos:

      • PREFIXES-AS6500X: Para identificar los prefijos del ASN.

      • ALL-v6: Todos los prefijos IPv6. Para poner al final y filtrar todo el resto.

  • Route-map:

    • Es una secuencia ordenada de sentencias de permiso o rechazo.

    • En este caso se utiliza para permitir o rechazar el anuncio de prefijos en BGP.



Filtrado Básico BGP Mikrotik

Ejemplo en Mikrotik

En mikrotik existen varias formas de programar los filtros a ser utilizados en las sesiones eBGP. Existen desde aquellas muy sencillas y básicas, pasando por las de detalles y complejidad intermedia hasta las más avanzadas que incluyen filtrado basado en manejo y configuración de atributos avanzados como MED, NEXT_HOP, AS_PATH, LOCAL_PREF, entre otros tantos. En este caso, a objeto de ilustrar de primera mano el concepto, haremos uso de una configuración básica y sencilla del filtrado BGP, y haremos uso solamente de los parámetros PREFIX y PREFIX_LEN para la definición de los filtros.

Al igual que en toda configuración de filtrado de sesiones BGP, debemos configurar un filtro BGP de entrada (IN) y un filtro BGP de salida (OUT) en cada par BGP. Esto es, para R1 debemos configurar un filtro para IN y otro para OUT, y para R2 debemos definir un filtro para IN y otro para OUT. Dicho esto, definiremos los siguientes parámetros de configuración para cada router de la sesión eBGP:

Router R1:

  • ·         Nombre del Filtro IN:                 ebgp-r2-ipv6-IN

  • ·         Nombre del Filtro OUT:            ebgp-r2-ipv6-OUT

  • ·         Prefijo IPv6 a Anunciar:            2001:db8:1::/48

Router R2:

  • ·         Nombre del Filtro IN:                 ebgp-r1-ipv6-IN

  • ·         Nombre del Filtro OUT:            ebgp-r1-ipv6-OUT

  • ·         Prefijo IPv6 a Anunciar:            2001:db8:2::/48


La configuración de los filtros en Mikrotik se realiza en la sección de configuración ‘/routing filter’. Las configuraciones, para Mikrotik RouterOS v6, serían las siguientes:

Para Router R1:

[admin@RouterOS-v6-R1] > /routing filter

[admin@RouterOS-v6-R1] /routing filter > add chain=ebgp-r2-ipv6-IN

prefix=2001:db8:2::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R1] /routing filter > add chain= ebgp-r2-ipv6-IN

prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R1] /routing filter > print where

Chain=ebgp-r2-ipv6-IN

Flags: X - disabled

 0   chain=ebgp-r2-ipv6-IN prefix=2001:db8:2::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r2-ipv6-IN prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""

 [admin@RouterOS-v6-R1] > /routing filter

[admin@RouterOS-v6-R1] /routing filter > add chain=ebgp-r2-ipv6-OUT prefix=2001:db8:1::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R1] /routing filter > add chain=ebgp-r2-ipv6-OUT prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R1] /routing filter > print where chain=ebgp-r2-ipv6-OUT

Flags: X - disabled

 0   chain=ebgp-r2-ipv6-OUT prefix=2001:db8:1::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r2-ipv6-OUT prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""



Para Router R2:

[admin@RouterOS-v6-R2] > /routing filter

[admin@RouterOS-v6-R2] /routing filter > add chain=ebgp-r1-ipv6-IN

prefix=2001:db8:1::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R2] /routing filter > add chain= ebgp-r1-ipv6-IN

prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R2] /routing filter > print where Chain=ebgp-r1-ipv6-IN

Flags: X - disabled

 0   chain=ebgp-r1-ipv6-IN prefix=2001:db8:1::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r1-ipv6-IN prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""

 [admin@RouterOS-v6-R2] > /routing filter

[admin@RouterOS-v6-R2] /routing filter > add chain=ebgp-r1-ipv6-OUT prefix=2001:db8:1::/48 prefix-length=48-48 action=accept

[admin@RouterOS-v6-R2] /routing filter > add chain=ebgp-r1-ipv6-OUT prefix=::/0 prefix-length=0-128 action=discard

[admin@RouterOS-v6-R2] /routing filter > print where chain=ebgp-r1-ipv6-OUT

Flags: X - disabled

 0   chain=ebgp-r1-ipv6-OUT prefix=2001:db8:2::/48 prefix-length=48 invert-match=no action=accept set-bgp-prepend-path=""

 1   chain=ebgp-r1-ipv6-OUT prefix=::/0 prefix-length=0-128 invert-match=no action=discard set-bgp-prepend-path=""



Luego de crear los filtros de IN y OUT, tanto para R1 como para R2, debemos entonces asignar esos filtros a las sesiones eBGP correspondientes. A continuación los comandos para esta configuración:

Para Router R1:

[admin@RouterOS-v6-R1] > /routing bgp peer

[admin@RouterOS-v6-R1] /routing bgp peer> set [find name=HACIAR2]

in-filter=ebgp-r2-ipv6-IN

[admin@RouterOS-v6-R1] /routing bgp peer> set [find name=HACIAR2] 

out-filter=ebgp-r2-ipv6-OUT

[admin@RouterOS-v6-R1] /routing bgp peer> print detail


Para Router R2:

[admin@RouterOS-v6-R2] > /routing bgp peer

[admin@RouterOS-v6-R2] /routing bgp peer> set [find name=HACIAR1]

in-filter=ebgp-r1-ipv6-IN

[admin@RouterOS-v6-R2] /routing bgp peer> set [find name=HACIAR1] 

out-filter=ebgp-r1-ipv6-OUT

[admin@RouterOS-v6-R2] /routing bgp peer> print detail


Importante: Un detalle de configuración importante es lo relativo a la configuración del prefijo IPv6 a anunciar. La forma más comúnmente utilizada es configurar dicho  prefijo IPv6 en la sección ‘/routing bgp network’ con el atributo ‘synchronize=no’. De esta forma, Mikrotik (versión 6) anunciará el prefijo IPv6 de manera ‘incondicional’ (ojo: pasado por los correspondientes filtros de OUT) . Como forma alternativa, podemos colocar el prefijo IPv6 en los BGP networks de Mikrotik y colocando el atributo ‘synchronize=yes’, pero en este caso el prefijo será anunciado si y sólo si se encuentra activo en la tabla de rutas IPv6 de Mikrotik. Por último, también se pueden hacer uso de técnicas de ‘redistribute’ para anunciar prefijos IPv6. También, es importante comentar que podemos anunciar vía eBGP cualquier prefijo con longitud entre /32 y /48 (ambos inclusive), tomado de nuestro prefijo base asignado por LACNIC.



Ejemplo en Cisco

R1:

ipv6 prefix-list ALL-v6 seq 5 permit ::/0 le 128

!

ipv6 prefix-list PREFIXES-AS65001 seq 5 permit 2001:DB8:1::/48

!

ipv6 prefix-list PREFIXES-AS65002 seq 5 permit 2001:DB8:2::/48

!

route-map RM-R1-R2-IN permit 10 #permite recibir los prefijos del AS65002

 match ipv6 address prefix-list PREFIXES-AS65002

!

route-map RM-R1-R2-IN deny 20 #no permite recibir ningún otro prefijo

 match ipv6 address prefix-list ALL-v6

!

route-map RM-R1-R2-OUT permit 10 #permite anunciar los prefijos del AS65001

 match ipv6 address prefix-list PREFIXES-AS65001

!

route-map RM-R1-R2-OUT deny 20 #no permite anunciar ningún otro prefijo

 match ipv6 address prefix-list ALL-v6

!

router bgp 65001

 address-family ipv6

  neighbor 2001:DB8:12::2 route-map RM-R1-R2-IN in #asocia el route-map al neighbor

  neighbor 2001:DB8:12::2 route-map RM-R1-R2-OUT out #asocia el route-map al neighbor

 exit-address-family

!


R2:

ipv6 prefix-list ALL-v6 seq 5 permit ::/0 le 128

!

ipv6 prefix-list PREFIXES-AS65001 seq 5 permit 2001:DB8:1::/48

!

ipv6 prefix-list PREFIXES-AS65002 seq 5 permit 2001:DB8:2::/48

!

route-map RM-R2-R1-IN permit 10

 match ipv6 address prefix-list PREFIXES-AS65001

!

route-map RM-R2-R1-IN deny 20

!

route-map RM-R2-R1-OUT permit 10

 match ipv6 address prefix-list PREFIXES-AS65002

!

route-map RM-R2-R1-OUT deny 20

 match ipv6 address prefix-list ALL-v6

!

router bgp 65002

 address-family ipv6

  neighbor 2001:DB8:12::1 route-map RM-R2-R1-IN in

  neighbor 2001:DB8:12::1 route-map RM-R2-R1-OUT out

 exit-address-family

!



Verificación


R1:

R1#show bgp ipv6 unicast 

BGP table version is 9, local router ID is 10.111.111.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found


     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:DB8:1::/48  ::                       0         32768 i

 *>  2001:DB8:2::/48  2001:DB8:12::2           0             0 65002 i

R1#


R2:

R2#show bgp ipv6 unicast 

BGP table version is 9, local router ID is 10.222.222.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found


     Network          Next Hop            Metric LocPrf Weight Path

 *>  2001:DB8:1::/48  2001:DB8:12::1           0             0 65001 i

 *>  2001:DB8:2::/48  ::                       0         32768 i

R2#


Errores comunes


  A pesar de que pueden existir muchos errores en el mundo de sesiones BGP quisimos enumerar dos casos muy típicos: 


  1. La sesión BGP no levanta

Pueden existir muchas razones por la cual una sesión BGP no levante entre dos peers. Las más probables son:

  1. No hay conectividad IP entre ellos

  2. Existe discrepancia de información entre los peers (por ejemplo, dirección IP, sistema autónomo incorrectos)


  1. Mi prefijo no se encuentra anunciado

Nuevamente pueden haber muchas razones por la cual no se encuentra anunciado un prefijo, las tres más comunes son:

  1. Existe algún filtro implementado saliente en la sesión BGP que prohíbe el anuncio del prefijo

  2. El prefijo que deseas anunciar no se encuentra en la tabla de enrutamiento

  3. Modernas implementaciones de BGP exigen implementaciones de políticas en la sesión BGP antes de realizar los anuncios de los prefijos



Conclusiones

  Levantar una sesión BGP (léase crear un peering BGP) es algo muy sencillo, tan solo hay que conocer los parámetros adecuados y saber colocarlos en la configuración según el dispositivo.

  La parte complicada de BGP entra al momento de tener varios peers, necesitar filtros de entrada y/o salida en las sesiones BGP, y sobre todo cuando un sistema autónomo hace tránsito de tráfico y prefijos de otros ASs.  La recomendación general es estudiar mucho y ser excesivamente cauteloso al momento de realizar cualquier configuración.



TODO

  Siempre es importante estar muy pendiente de la seguridad, anuncios, filtros y operación de BGP. Se sugiere revisar el siguiente BCP BGP (Operations and Security):


  https://datatracker.ietf.org/doc/html/rfc7454



  A su vez en LACNIC tenemos gran cantidad de videos sobre BGP:

https://www.youtube.com/c/lacnicstaff/search?query=bgp


  Y tenemos un curso en nuestro CAMPUS donde cubrimos bastante esta temática:

https://campus.lacnic.net/mod/page/view.php?id=10647


  Seleccionar el Router-ID de cada router “sabiamente”



Referencias

https://blog.cdemi.io/beginners-guide-to-understanding-bgp/

https://datatracker.ietf.org/doc/html/rfc7454

[2] https://networklessons.com/bgp/ebgp-multihop

[3] https://www.networkurge.com/2017/06/bgp-next-hop-attribute-and-rules.html


Autores:
Por: Jose G. Cotua (@SimeonSpa) / Alejandro D’Egidio (@Ale_Degidio) / Alejandro Acosta (@ITandNetworking)


서민통합지원센터
Elder Law Attorney - Elder Law Lawyer Evergreen Elder Law Our goal is to help you put a flexible, thoughtful plan in place that protects as much of your estate as possible. We know you’ve worked hard to build up your estate and understand how hard it is to just let it go to pay for long-term care.

BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...