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!
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.
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ó (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)
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)
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.
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 ;-)
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.
Cuando vamos levantando nuestras fichas en dominó, ¿cuántos -puntos- cargué?.
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”).
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..
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.
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.
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.
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.
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
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:
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í
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 ….. “
Dos enrutadores
Conectividad entre los enrutadores
Soporte IPv6 en ambos equipos tanto en conectividad como en BGP
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
Para establecer y probar la conectividad entre los enrutadores debemos:
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.
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.
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.
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:
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.
Un router (un eBGP Speaker) al aprender un prefijo de otro AS copia el atributo de nexthop hacia su red iBGP.
Una red de speakers iBGP tradicionalmente tendrá un IGP.
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).
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.
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 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
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
Desde R2
Es importante que la letra “E” aparece en la salida, la misma indica que la sesión BGP se encuentra establecida correctamente
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
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#
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#
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#
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
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#
A pesar de que pueden existir muchos errores en el mundo de sesiones BGP quisimos enumerar dos casos muy típicos:
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:
No hay conectividad IP entre ellos
Existe discrepancia de información entre los peers (por ejemplo, dirección IP, sistema autónomo incorrectos)
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:
Existe algún filtro implementado saliente en la sesión BGP que prohíbe el anuncio del prefijo
El prefijo que deseas anunciar no se encuentra en la tabla de enrutamiento
Modernas implementaciones de BGP exigen implementaciones de políticas en la sesión BGP antes de realizar los anuncios de los prefijos
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.
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”
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
