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

Comportamiento extraño de ssh en MAC - Problemas de copiar / Pegar

 Situación:

  Comportamiento extraño de SSH en MAC, problemas para copiar / pegar en el terminal durante el ssh. Funciona el portapapeles en otras aplicaciones

Solución:

  Al menos en "vi" la solución es muy sencilla. Edita el archivo: ~/.vimrc y pega el siguiente contenido:

if !has("gui_running")

  set mouse=

endif

Suerte!

Una mirada a los miembros IPv6 Only de LACNIC

Introducción

El siguiente trabajo busca analizar la publicación de prefijos y el estado de los mismos, por parte de los miembros de LACNIC conocidos como IPv6 Only.

Se trata de organizaciones que han recibido prefijos IPv6, con o sin sistema autónomo (ASN), y no cuentan con prefijo IPv4 asignado por LACNIC. Los resultados de este análisis nos ayudarán a mejorar nuestra comprensión de los usos y necesidades de nuestros asociados en la región.

Fuentes de información utilizadas en este análisis

 La fuente de información utilizada en este análisis  fue el whois de LACNIC, con datos  obtenidos a lo largo del mes de enero de 2023. Esta información  incluye únicamente a aquellos miembros que posean IPv6 y no poseen IPv4 por parte de LACNIC. Pueden o no tener asignado un sistema autónomo.

Procesamiento de los datos

Python3 sobre un notebook Jupyter. Nos apoyamos en los API públicos de LACNIC y de RIPE NCC

            WHOIS de LACNIC

            RIPE NCC API

            APNIC Penetración IPv6 por ASN

            Delegated Extended de LACNIC:

Resultados

  Obtuvimos 483 miembros de LACNIC que se consideran IPv6 Only, a los que dividimos en:

            IPv6 Only con ASN: 343 miembros

            IPv6 Only sin ASN: 140 miembros

Resultados sobre los 483 miembros IPv6 Only (con y sin ASN):

 De los 483 miembros analizados obtuvimos la siguiente información:

-261 Anuncian el prefijo en su totalidad o parcialmente

-208 Anuncian el prefijo recibido por LACNIC en su totalidad

-53 Anuncian el prefijo recibido por LACNIC parcialmente

-222 No anuncian el prefijo

Resultados sobre los 343 miembros IPv6 Only con ASN:

De los 483 miembros IPv6 Only 343 tienen ASN (71%)

De los 343 con ASN:

                        163 anuncian el prefijo (47,52%)

120 Anuncian el prefijo IPv6 completo (73,61 %)

43 Anuncian el prefijo IPv6 parcialmente (26,38 %

180 No anuncian el prefijo Pv6  (52,48%)

Resultados sobre los 140 miembros IPv6 Only Sin ASN

De los 483 miembros IPv6 Only 140 no tienen ASN (29%)

De los 140 sin ASN obtuvimos

98 Anuncian el prefijo (70%)

82 Anuncian el prefijo completo (83,67%)

16 Anuncian el prefijo parcialmente (16,32%)

42 No anuncian el prefijo (30%)

¿Qué podemos extraer de los gráficos anteriores?

Lo primero que me llama poderosamente la atención es que los miembros IPv6 Only sin ASN poseen 23 puntos porcentuales más anuncios que aquellos miembros de LACNIC que si poseen su ASN. Es decir, estos miembros han pedido a otra organización que anuncie su prefijo.

En ambos casos la cantidad de prefijos no anunciados es muy alta; puede ser interesante averiguar si existe algún motivo detrás de esta situación. 

Es particularmente llamativo que el porcentaje de anuncio parcial es casi idéntico (11% miembros con ASN y 12% miembros sin ASN)

Intentando identificar si los ASNs poseen tráfico IPv6

Conociendo que existen 343 ASNs con prefijos IPv6 asignados y pensando que además son IPv6 Only, se puede presumir que deben tener un tráfico IPv6 “medio alto”.  Por ello, evaluamos cada AS para conocer su tráfico IPv6 para el 23 de Enero 2023.

¿Cómo averiguamos si un ASN posee tráfico IPv6?

Como es conocido por varios de ustedes, APNIC lleva muchos años midiendo el tráfico IPv6 de cada ASN. Se puede conocer más de estos estudios aquí: https://stats.labs.apnic.net/ipv6

En base a lo anterior, con los ASNs conocidos de los miembros IPv6 Only de LACNIC quisimos averiguar si efectivamente poseen tráfico IPv6 (es decir, más allá de realizar el anuncio de su prefijo). 

Lastimosamente no se pudo conseguir información de 274 ASs (79,88 %) de los 343 evaluados, Sin embargo, es importante destacar que esto no necesariamente significa que no hayan desplegado IPv6, sino que el tráfico generado es muy bajo y no aparecen en las mediciones de APNIC. 32 ASN fueron reportados con 0% de tráfico IPv6 y 1 ASN con 88% de tráfico IPv6.

¿Nuestros miembros IPv6 Only son en realidad tan IPv6 Only?

Finalmente, quisimos averiguar si efectivamente nuestros miembros (IPv6 Only con ASN) son tan IPv6 Only como nosotros los llamamos.

Para este caso en particular nos apoyamos en el API de RIPE NCC para obtener la información presentada a continuación.

De los 343 miembros con ASNs obtuvimos:

-540 prefijos totales anunciados (entre v4 y v6)

                        Anuncios v4: 220

                        Anuncios v6: 320

                        La máscara media en los anuncios v4 es: 23,56

                        La longitud de prefijo media en los anuncios IPv6 es: 38,09

-66 miembros se “volvieron” DualStack, es decir el ASN anuncia IPv4 e IPv6

-90 miembros anuncian solo IPv6

-27 miembros anuncian solo IPv4

-160 no anuncian prefijo alguno

Y los prefijos IPv4 que anuncian los miembros IPv6 Only de LACNIC,  ¿a cuál RIR pertenecen?

LACNIC ARIN RIPE NCC AFRINIC APNIC

28 166 17 9 0

Diagrama Sankey – Mirada a los miembros IPv6 Only

Conclusiones

Los resultados sugieren que, aunque existe una cantidad significativa de miembros de LACNIC que se consideran IPv6 Only, pudimos notar que más del 50% de ellos no han comenzado con el anuncio de su prefijo v6. A su vez pudimos apreciar que muchos de los que han desplegado IPv6 continúan utilizando IPv4. Esto significa que, aunque la adopción de IPv6 en la región ha crecido en los últimos años, aún hay un largo camino por recorrer para alcanzar un despliegue generalizado de IPv6. En cualquier caso, es importante continuar monitoreando la adopción del nuevo protocolo.

Finalmente ser un miembro IPv6 Only de LACNIC igualmente permite a las organizaciones participar en el ecosistema de Internet.

El juego del dominó y TCP/IP

En mi vida, al igual que muchas personas, tengo varias pasiones: familia, trabajo, deporte; y en este último incluyo el hermoso juego del dominó. Hace unos 25 años alcancé mi mejor nivel en este juego, participé de varios torneos (ganando algunos pocos) y la guinda de la corona, obtuve un 6to lugar en un torneo nacional. Adicionalmente, menciono que vengo de una familia con alguna herencia de fanáticos del dominó, como lo eran dos tíos, mi padre y mi hermano.

Jugar dominó es una de las cosas más lindas entre familia, amigos y no tan amigos. Ahora bien, ¿en qué se parece el juego del dominó al protocolo TCP/IP? Alguno quizás ya debe estar pensando “Alejandro ahora sí se volvió loco”; quizás no me volví loco, probablemente ya lo estaba.

Pero ese no es el punto, te demostraré que TCP/IP y el dominó tienen mucho en común.

Los protocolos TCP/IP según IBM [1] lo definen como:

“Los protocolos son conjuntos de normas para formatos de mensaje y procedimientos que permiten a las máquinas y los programas de aplicación intercambiar información. Cada máquina implicada en la comunicación debe seguir estas normas para que el sistema principal de recepción pueda interpretar el mensaje.”

Suena interesante…, pero probablemente aún no veas qué tiene que ver con el dominó, y  sigues pensando que es una locura. ¡A no desesperar, ya vamos a llegar!

Y el Dominó (según chatgpt):

“El juego de dominó es un juego de mesa en el que los jugadores utilizan fichas con números en ambos extremos para colocarlas en un tablero. El objetivo del juego es colocar todas las fichas antes que los demás jugadores. La comunicación entre los jugadores en el juego de dominó se basa en la estrategia y en la planificación. Los jugadores deben comunicar qué fichas tienen y qué fichas pueden jugar, y deben trabajar juntos para encontrar la mejor manera de colocar las fichas en el tablero. Además, los jugadores deben estar atentos a las jugadas de los demás jugadores y adaptar su estrategia en consecuencia. En resumen, la comunicación en el juego de dominó es esencial para el éxito del equipo y para ganar el juego.”

Ahora, pensemos un poco macro, a estas alturas podemos apreciar que en ambos hay piezas que deben ser enviadas/jugadas, y las mismas deben mantener un orden para poder alcanzar una comunicación exitosa. Además, en ambos hay estrategia y planificación para lograr el objetivo, en uno se conectan las piezas y en el otro dispositivos, ¿ya comencé a convencerte?

Ahora hablemos de comunicación y el Dominó en parejas, y es aquí donde está el corazón del tema al que quiero llegar.

Independiente del estilo de dominó que cada uno juegue (Cubano, Latino, Méxicano, Chileno, etc) “el dominó en parejas” es un juego de comunicación, no es diferente a una red de datos. Un jugador tiene que comunicarse con su pareja (A → B, B → A) para indicarle qué piezas tiene o no.

Igualmente, ¿cómo me comunico si una de las reglas es no poder hablar?. Allí está la grandeza de los buenos jugadores, al igual que TCP/IP -y cualquier otro protocolo de comunicación- hay que seguir ciertas reglas.

Luego de mis tres décadas de experiencia en ambos mundos, aquí les dejo lo que considero los principales jugadas en el ecosistema del dominó en parejas y su contraparte en TCP/IP:

La salida en el dominó

La salida en el dominó (primera pieza que coloca el salidor) es idéntica a un SYN Packet de TCP (y más específicamente es un SYN con payload al estilo TCP Fast Open).  Esta es una comparación hermosa, porque la salida en el dominó por parejas *siempre* lleva información, generalmente se refiere al palo (número) que uno más desea. TCP Fast Open (una lindura del mundo de TCP) se encuentra definido en el RFC 7413 y su principal objetivo es poder enviar información en el primer paquete con en el que comienza toda comunicación TCP (SYN)

La pensada (double ACK)

Se considera payload no necesario en algunas redes pero puede valer la pena. La “pensada” de un jugador indica explícitamente que el jugador tiene más de una pieza del “palo” (número) jugado; con ello, el jugador está comunicando eficientemente información a su compañero quien debe darse notar estas pensadas, es muy similar a aquellos servidores y redes donde se configuran dispositivos para enviar más de un ACK en TCP (acuso de recibo)

Pasar (packet dropped)

En TCP al perder un paquete se entra en la fase de “Congestion Avoidance”, allí disminuye en un 50% la ventana TCP y por ende la velocidad de transmisión. Nada más similar al pasar en dominó; claro, aquí se entra en etapa de pánico, sobre todo cuando hay mucho que transmitir.

La versión

En el mundo de IP estamos acostumbrados a IPv4 e IPv6, en el dominó la única diferencia es que la versión va del 0 (blancas) al 6. (si, si, ciertamente existen Dominoes hasta 9, toda regla tiene su excepción ;-) 

Pensar en falso

TCP Half-Open, ¿se recuerdan?, es cuando en el saludo de tres vías (SYN, SYN+ACK, ACK) se queda en la mitad del saludo (ojo, este es el concepto moderno, en honor a la verdad no respeta RFC 793). También es comúnmente utilizado para realizar ataques de DoS.

Tamaño de la carga (Total Length)

Cuando vamos levantando nuestras fichas en dominó, ¿cuántos -puntos- cargué?.

La dirección origen y el destino

Aquí nos encontramos específicamente en el mundo de capa 3. Este es un caso muy interesante donde, al igual que en redes de comunicación, un host se comunica con algún otro. Lo mismo sucede en el dominó, es decir,  algunos paquetes pueden ir orientados al compañero; sin embargo, en algunos casos se puede orientar a los oponentes según la necesidad (ejemplo, cuando se busca “tal palo”).

Pensar en cada jugada

 Bufferbloat es una situación muy particular pero a su vez ocurre con mucha frecuencia. Básicamente son situaciones donde los hosts (principalmente middlewares al estilo, routers, firewalls, Switches) agregan delay (cargando los buffers) al momento de conmutar los paquetes. Lo anterior crea latencia y jitters innecesarios. Por favor, si administras redes no dejes de revisar si sufres de bufferbloat..

Trancar la partida/mano

 Es el momento donde ya es imposible jugar alguna pieza de dominó, y en TCP/IP supone la caída de la red, por lo que tampoco se puede enviar ningún paquete.

Consecuencias de la buena y mala comunicación

En dominó en pareja, al igual que en cualquier protocolo de red, comunicarse bien o mal trae sus consecuencias. Si uno tiene buena comunicación en el dominó alcanzará -muy seguramente- la victoria. Si la comunicación *no* es buena, el resultado será la pérdida del partido. En TCP/IP si la comunicación es buena se establecerá la conexión correctamente y se entregarán los datos. Si la comunicación es mala, obtendremos datos corruptos y/o el no establecimiento de la conexión.

Doble Cabeza

En el dominó se entiende que tienes doble cabeza cuando llevas la última pieza de dos números diferentes. ¿Con qué se puede comparar? Con TCP Multipath (MPTCP), definido en el RFC 8684.que permite operar conexiones por diferentes caminos. Es  por ello que MPTCP ofrece redundancia y eficiencia en el ancho de banda a consumir.

¿Aún no los convencí? Bueno, tengo una oportunidad más a ver si lo logro.

A continuación les presento un modelo capa a capa entre TCP/IP vs dominó

Modelo TCP/IP (+ capa de usuario)	Modelo Dominó
Usuario	Jugador
Aplicación	Construir la jugada
Transporte	Seleccionar la ficha/piedra
Red	Tomar las piedras
Enlace	Piedras/Fichas
Física	Colocar en la mesa la ficha

Un paquete en el modelo TCP/IP se construye desde las capas superiores a las inferiores (posteriormente se inyecta a la red, etc), lo recibe el host destino y lo procesa “a la inversa”, desde la capa física hasta la aplicación. En el modelo dominó, ocurre exactamente igual: el jugador arma su jugada, selecciona su ficha/piedra, la toma para luego inyectarla en el juego.

Conclusión

La comparación entre el juego de dominó en parejas y el protocolo de comunicación TCP/IP puede parecer extraña al principio. Sin embargo,  si observamos con atención, podemos encontrar similitudes, En el dominó  existen dos jugadores que actúan como emisores y receptores de información, ya que cada uno tiene su propio conjunto de fichas y deben comunicarse entre sí para decidir qué ficha jugar en cada turno. Del mismo modo, en TCP/IP existen dispositivos que actúan como emisores y receptores de información.

Estos contrastes ilustran cómo a menudo pueden existir similitudes entre sistemas aparentemente disímiles, y que comprender estas semejanzas pueden ser útiles para entender conceptos complejos y ver las cosas desde una perspectiva diferente.

Python: leyendo un archivo de texto -

Situación:

  Leyendo un archivo en python3 de texto (csv o txt) hay un carácter que se puede "apreciar" utilizando "more" en terminal pero en python3 es más complicada la situación. 

Ejemplo 1:

 $ more epa.csv 

<U+FEFF>el texto

   En mi caso, el archivo lo generé utilizando Excel y grabando como csv.

Ejemplo 2:

 

Problema:

  Python3 lee el archivo bien, no arroja error pero ese "carácter" invisible queda en las variables, los textos, etc y puede traer algún inconveniente.

Solución:

  La solución es leer el archivo y especificar el encoding, algo tan sencillo como:

FILENAME="epa.csv"

with open(FILENAME, encoding='utf-8-sig') as file:

    for line in file:

        print (line)

Explicación (tomado de: https://stackoverflow.com/questions/17912307/u-ufeff-in-python-string):

The Unicode character U+FEFF is the byte order mark, or BOM, and is used to tell the difference between big- and little-endian UTF-16 encoding.

Espero te haya ayudado

4 posibles soluciones en Python3 a: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 503: ordinal not in range(128)

Problema: 

 Al ejecutar un script en python se recibe un mensaje similar a: 

return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 503: ordinal not in range(128) 

Causa:

  Por defecto python intenta utilizar ASCII como encoding, en caso de que el archivo a leer, la variable a declarar tenga otro codec debe ser especificado, sin embargo, en líneas generales UTF-8 es capaz de solucionar la mayoría de las situaciones

Soluciones

1) Especifar el encoding al momento de leer un archivo:

 with open(os.path.expanduser(path), encoding='utf-8') as f:

2) Asignar una variable e indicar la forma de decodificarla:

s = s.decode('utf-8')

3) Declarar variables de entorno (Linux). Por ejemplo

 export LANG=en_US.UTF-8 

export LC_ALL=en_US.UTF-8 export 

export PYTHONIOENCODING=utf8

4) Indicar al comienzo del script el coding. Por ejemplo

#!/usr/bin/python

# coding: utf-8

Suerte, espero haya sido de tu ayuda.

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í