7 desafíos que enfrentó IPv6 y cómo fueron resueltos

¿Alguna vez pensaste que IPv6 no lograría despegar realmente? Si tu respuesta es “sí”, este blog es para ti.

En los últimos 20 años IPv6 pasó por muchos obstáculos que hicieron dudar a más de uno sobre su futuro. Desde el principio tuvo que enfrentar desafíos técnicos importantes: no era compatible con IPv4, muchos equipos antiguos no lo soportaban y, como suele pasar, hubo bastante resistencia al cambio por parte de operadores y empresas. A esto se sumaron varios mitos —como que era demasiado complejo o poco seguro— que también jugaron en su contra.

Pero el tiempo y la tecnología hicieron lo suyo. Gracias a herramientas de transición, mejoras en el enrutamiento y el desarrollo de hardware más preparado, IPv6 no solo demostró que puede escalar (¡estamos hablando de 340 undecillones de direcciones disponibles!), sino que también es más eficiente y seguro que el viejo IPv4.

Hoy, IPv6 ya no es una promesa: es una realidad. Está detrás del 5G, del futuro 6G, del Internet de las Cosas a gran escala y de la nube hiperconectada. Y además, soluciona problemas que arrastramos hace años, como la falta de direcciones y la fragmentación de las redes.

En este artículo vamos a desarmar algunos de los mitos más comunes —como que IPv6 baja el rendimiento o que no se lleva bien con sistemas antiguos— y vamos a mostrarte con datos y ejemplos reales por qué migrar a IPv6 no solo es posible: es necesario si querés que tu red esté preparada para lo que viene.

1. Mejora en la conmutación de paquetes a nivel de hardware

En los últimos 15 años los circuitos integrados de aplicación específica (ASICs) para redes han pasado de un soporte marginal a una implementación nativa y optimizada de IPv6. Antes de 2010, el procesamiento de IPv6 dependía de CPUs generales, generando alta latencia y bajo rendimiento. Entre 2010-2015, fabricantes como Cisco y Broadcom integraron tablas de forwarding IPv6 en hardware (TCAM), soporte para NDP/ICMPv6 y lookup eficiente en chips como el Cisco Nexus 7000 o Broadcom StrataXGS. Para 2015-2020, los ASICs alcanzaron madurez con tablas de routing escalables, offloading de extensiones IPv6 (headers, tunneling) e integración con SDN/NFV, ejemplificado por el Broadcom Tomahawk y Cisco Silicon One.

Desde 2020, IPv6 es prioritario en diseños de ASICs, con capacidades avanzadas como: Segment Routing IPv6 (SRv6) acelerado, seguridad nativa (IPsec en hardware), y optimización para IoT/5G. Chips como el Broadcom Jericho2 (2020), Marvell Octeon 10 (2022) e Intel Tofino 3 (2023) soportan millones de rutas IPv6 y procesamiento programable (P4), consolidando IPv6 como estándar en redes modernas. Esta evolución refleja la transición de IPv6 de un complemento software a un componente crítico en el hardware de red.

Período Soporte IPv6 en ASICs Limitaciones

Pre-2010 Mínimo o por software Alto costo de CPU, baja eficiencia

2010-2015 Primeras implementaciones en TCAM/ASICs Tablas IPv6 limitadas

2015-2020 Madurez en switches/routers empresariales  

2020-Actualidad IPv6 nativo, optimizado para cloud/5G/SRv6  

Comparativa Resumida sobre evolución de las ASICs

2. El dilema del huevo y la gallina en IPv6

El dilema del huevo y la gallina en el contexto de IPv6 se refiere a la paradoja de cómo impulsar la adopción de esta nueva versión del Protocolo de Internet. Es como si nadie quisiera comprar un nuevo tipo de teléfono porque no hay apps para él, pero los desarrolladores no crean apps porque casi nadie tiene ese teléfono.

Por un lado, los proveedores de contenido (como plataformas de streaming y sitios web) necesitan que haya suficientes usuarios que utilicen IPv6 para justificar la inversión en infraestructura y optimización para este protocolo. Por otro lado, los usuarios finales requieren acceso a contenido disponible a través de IPv6 para motivarse a hacer la transición desde IPv4. Sin una base sólida de ambos lados, se crea un ciclo vicioso donde la falta de usuarios limita el contenido disponible y la escasez de contenido desincentiva a los usuarios a adoptar IPv6.

La realidad en 2025 es muy distinta: una larga lista de las principales CDNs (redes de distribución de contenidos) y sitios web a nivel mundial ya soportan IPv6 desde hace varios años. Como resultado, los clientes que aún no implementan IPv6 suelen experimentar un rendimiento de conectividad ligeramente inferior en comparación con aquellos que sí lo utilizan.

Un hecho no menor que ha impulsado considerablemente la adopción de IPv6 entre los proveedores es el impacto del mundo de los videojuegos y la comunidad gamer. Resulta ampliamente conocido el fuerte respaldo que las principales consolas han brindado a IPv6, como es el caso de Xbox (desde 2013) y PlayStation (desde 2020).

CDN/Sitio Web Año de Adopción IPv6  

Cloudflare 2011 Primer CDN en soportar IPv6 globalmente

Google (Búsqueda, YouTube) 2012 Habilitación progresiva

Facebook/Instagram 2013 Adopción completa en 2014

Wikipedia 2013 Uno de los primeros sitios en adoptar

Akamai 2014 Soporte gradual por región

Netflix 2015 Prioriza IPv6 para reducir latencia

Amazon CloudFront 2016 Soporte completo en edge locations

Apple (App Store) 2016 Requisito obligatorio para apps iOS

Microsoft Azure CDN 2017  

Fastly 2018 Soporte nativo en toda su red

Tabla de adopción IPv6 en contenido .Fuente: Deepseek (Mayo 2025)

3. Enrutamiento con Prefix Delegation

Una situación muy interesante, que ocurrió hace 10-15 años, era la dificultad que muchos proveedores de servicios de Internet (ISPs) enfrentaban al implementar DHCPv6-PD (Prefix Delegation). Era común que surgieran problemas de enrutamiento: por ejemplo, un host o una red remota (CPE) podía recibir correctamente un prefijo IPv6, pero las rutas necesarias para alcanzar ese prefijo no estaban configuradas en el ISP. Era como si el cartero supiera tu dirección, pero no tuviera un mapa para encontrar cómo llegar a tu casa.

Hoy os ISPs han actualizado sus infraestructuras para manejar automáticamente el enrutamiento de los prefijos delegados, mientras que los routers modernos (tanto domésticos como empresariales) incluyen soporte robusto para DHCPv6-PD. Ahora, cuando un cliente recibe su bloque IPv6, el ISP inmediatamente propaga las rutas necesarias, y el router local configura automáticamente las subredes internas. Esto ha hecho que la delegación de prefijos IPv6 sea tan confiable como el DHCP tradicional de IPv4, eliminando uno de los dolores de cabeza iniciales de la transición.

Aspecto Hace 10 Años Actualidad (2024)

Asignación de prefijo DHCPv6-PD sin rutas en el core DHCPv6-PD + auto-anuncio BGP/IGP

Comportamiento del CPE Recibía el prefijo o no configuraba rutas Configura automáticamente LAN + rutas

Conectividad Solo tráfico saliente (entrante perdido) Full bidireccional (entrante/saliente)

Soluciones temporales NAT66, túneles manuales, redistribute connected en el CPE Enrutamiento nativo sin hacks

Comparativa: 2014 vs. 2024

4. Formación y aprendizaje colectivo

Hace dos décadas, adoptar IPv6 era un desafío técnico y educativo. La documentación resultaba escasa, dispersa y a menudo demasiado técnica, dejando a muchos administradores de redes aprendiendo mediante ensayo y error. Los primeros cursos disponibles se limitaban principalmente a especificaciones teóricas del protocolo, con poca orientación práctica sobre implementación real en redes operativas. Esta falta de recursos formativos de calidad ralentizó inicialmente la adopción de IPv6, especialmente en entornos empresariales y operadores pequeños.

Hoy en día, diferentes organizaciones, incluyendo LACNIC, han liderado un esfuerzo educativo masivo para reducir las barreras de entrada a IPv6. Ejemplos de esto son el Campus de LACNIC, con cursos que van desde nivel básico hasta avanzado, publicaciones en blogs, videos, podcasts, y otros recursos didácticos.

Además, iniciativas como LACNOG (y otros NOGs regionales) y los ya clásicos talleres prácticos de IPv6 de LACNIC han contribuido a crear espacios de formación y discusión técnica sobre la implementación de IPv6 en redes reales.

A seu vezmuchas empresas privadas han incluido IPv6 como tema obligatorio en sus programas de formación y certificación, tanto en cursos como en exámenes.

La comunidad técnica tampoco se ha quedado atrás: cientos de personas, desde estudiantes hasta ingenieros de redes senior, comparten regularmente recursos en diferentes redes sociales, generando artículos, videos, blogs y notas técnicas que ayudan a cerrar las brechas de conocimiento y a fortalecer el aprendizaje colectivo sobre IPv6.

5. Compatibilidad con aplicaciones

Veinte años atrás, el soporte IPv6 en aplicaciones era una suerte de lotería. Si existía IPv4 e IPv6 en la red era aún más complicado. Por ejemplo, en una red IPv6 Only si la app usaba direcciones IPv4 literales lógicamente iba a fallar. Muchos desarrolladores asumían que en todas las redes había IPv4 de facto. También en los sistemas operativos existían bibliotecas obsoletas que no soportaban el nuevo protocolo. Esto creaba una situación absurda: incluso cuando un usuario o empresa tenía una red IPv6 perfectamente configurada, sus herramientas cotidianas -como lector de correo electrónico- simplemente dejaban de funcionar.

Hoy la situación ha dado un vuelco radical. Grandes plataformas como la App Store de Apple (desde 2016) y Google Play exigen que las aplicaciones nuevas sean IPv6-compatibles (a pesar de esta última no lo coloca de manera explícita) como requisito obligatorio. Adicionalmente mecanismos como Happy Eyeballs apoyan la transición a IPv6 a nivel de software de manera transparente. Las principales bibliotecas de programación (como las de Python, Java y Node.js) incluyen soporte nativo para IPv6 desde hace años, eliminando excusas para los desarrolladores. Empresas como Microsoft, Google y Cloudflare han liderado este cambio, demostrando que el rendimiento en IPv6 puede ser incluso mejor que en IPv4. Lo que antes era un dolor de cabeza ahora es una ventaja competitiva: las aplicaciones que adoptan IPv6 primero disfrutan de menor latencia, mejor seguridad y acceso a la próxima generación de usuarios conectados.

6. Fragmentación y MTU (Maximum Transmission Unit)

A diferencia de IPv4, IPv6 elimina la fragmentación en los routers intermedios, lo que significa que los paquetes deben respetar el MTU (Maximum Transmission Unit) de toda la ruta desde el origen hasta el destino. Esta decisión de diseño mejora la eficiencia general de la red, pero en sus primeros años (hace 10, 15 o 20 años), generó bastantes dolores de cabeza: muchos dispositivos implementaban de forma incorrecta el mecanismo de Path MTU Discovery (PMTUD), lo que provocaba pérdida de conectividad en situaciones comunes.

En particular, routers antiguos y sistemas operativos sin actualizar no sabían manejar bien los mensajes ICMPv6 “Packet Too Big”, que son esenciales para que el emisor ajuste el tamaño de los paquetes. Como resultado, la comunicación se rompía en redes donde el MTU era más bajo de lo esperado.

Actualmentelos sistemas operativos modernos y los equipos de red actuales ya manejan correctamente el PMTUD, respondiendo y ajustando dinámicamente el tamaño de los paquetes en función de los mensajes ICMPv6. Esto ha hecho que estos problemas sean mucho menos frecuentes y que la red funcione de manera más estable y eficiente bajo IPv6.

7. El envío de DNS vía RA

En los primeros años de IPv6 (hasta aproximadamente 2010), configurar servidores DNS en los clientes de red era un proceso más complejo e indirecto. Los routers enviaban mensajes Router Advertisement (RA) con el flag O (Other Configuration) activado, lo que obligaba a los clientes a hacer una solicitud adicional mediante DHCPv6 para obtener la información de los servidores DNS. Este enfoque, heredado del mundo IPv4, traía consigo varios inconvenientes: mayor latencia en la configuración, dependencia de un servicio adicional y mayor complejidad para redes simples o dispositivos con recursos limitados, como muchos equipos IoT.

Esta limitación se resolvió con la introducción de la opción RDNSS (Recursive DNS Server) dentro de los propios mensajes RA de ICMPv6, formalizada en el RFC 6106 (2010). A partir de entonces, los routers pudieron anunciar directamente los servidores DNS a los clientes, simplificando drásticamente la autoconfiguración.

Aunque al principio hubo cierta resistencia por parte de fabricantes de sistemas operativos y routers, entre 2015 y 2017 el soporte para RDNSS se volvió común: Windows 10, Linux (con systemd-networkd), iOS 9+ y la mayoría de los routers empresariales ya lo implementaban.

Hoy esta funcionalidad está prácticamente universalizada en equipos modernos y se considera una mejor práctica en redes IPv6, eliminando la necesidad de usar DHCPv6 solo para DNS y habilitando despliegues mucho más simples, tipo “plug and play”.

Conclusiones

En retrospectiva, tras más de dos décadas de evolución, IPv6 ha superado obstáculos que en su momento parecían insalvables, pasando de ser un protocolo casi teórico a convertirse en la columna vertebral de la Internet moderna.

Los desafíos técnicos que antes generaban incertidumbre hoy cuentan con soluciones estandarizadas, eficientes y ampliamente adoptadas, fruto de la colaboración entre la industria y organismos como el IETF. Mitos como su supuesta “complejidad” o “incompatibilidad” han sido superados por evidencias concretas de mejor rendimiento, mayor seguridad y capacidad de escalado real.

IPv6 es el presente. Con casi el 50% del tráfico global circulando sobre IPv6 (y cerca del 40% en América Latina y el Caribe), soporte nativo en CDNs, sistemas operativos y aplicaciones, y un papel fundamental en tecnologías como 5G, IoT y cloud hiperconectada, la transición total es solo cuestión de tiempo. Seguir postergando su adopción no solo significa perder ventajas técnicas: es avanzar hacia la obsolescencia.

La lección es clara: adoptar IPv6 es un imperativo estratégico. No implementarlo es correr el riesgo de quedar aislado en una Internet que ya ha dado el siguiente paso.

Referencias:

    RFC 6106: https://datatracker.ietf.org/doc/html/rfc6106

    Centro de estadísticas de LACNIC: https://stats.labs.lacnic.net/IPv6/graph-access.html

    https://developer.apple.com/support/downloads/terms/app-review-guidelines/App-Review-Guidelines-20250430-English-UK.pdf

Solución: "The following security updates require Ubuntu Pro with 'esm-apps' enabled"

Situación

 Al momento de querer hacer algunas operaciones en Ubuntu utilizando apt/do-release-upgrade se recibe el mensaje:

"The following security updates require Ubuntu Pro with 'esm-apps' enabled"

Solución

  La solución que me funcionó fue ejecutar esto:

cd /etc/apt/sources.list.d 
for i in *.list; do mv ${i} ${i}.disabled; done 
apt clean
apt autoclean 
sudo do-release-upgrade 

Referencia

Upgrade from Ubuntu 18.04

Solución a: Error: eth0 interface name is not allowed for R2 node when network mode is not set to none

Problema:

  Containerlab devuelve un error similar:

Error: eth0 interface name is not allowed for R2 node when network mode is not set to none

Solución:

  En el archivo .yml en la sección del nodo que indica el error de la topología especificar: 

network-mode: none

Ejemplo:

topology:

  kinds: 

    linux:

      image: quay.io/frrouting/frr:8.4.1

  nodes:

    R1:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      network-mode: none

  Volver a ejecutar la topología con clab dep -t archivo.yml y listo!

Suerte.

La verdadera solución para correr ContainerLAB en MAC m1, m2, m3 apple silicon

 

Paso 1: Instalar Multipass de Canonical

$brew install multipass

Paso 2: Instalar la VM llamada docker

$multipass launch docker --name mydocker

Paso 3: Conectarse a la nueva VM

$multipass shell mydocker

Paso 4: Dentro de la VM instalar ContainerLab

$sudo su

#bash -c "$(curl -sL https://get.containerlab.dev)"

Vamos a probar con esta sencilla topología back2back de dos equipos Linux con FRR

-- 2-frr-back2back.yml --

name: ipv6-ws

topology:

  kinds:

    linux:

      image: ghcr.io/hellt/network-multitool

  nodes:

  ROUTERS ###

    R1:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      exec:

        - "sysctl -w net.ipv6.conf.all.forwarding=1"

        - "ip address add dev eth1 2001:db8:ffab::1/64"

    R2:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      exec:

        - "ip address add dev eth1 2001:db8:ffab::2/64"

        - "sysctl -w net.ipv6.conf.all.forwarding=1"

  links:

    - endpoints: ["R1:eth1", "R2:eth1"]

--- yml --

Paso 5: Levantemos la topología con clab:

clab dep -t 2-frr-back2back.yml

Paso 6: finalmente vamos a conectarnos a una de las VMs dentro de ContainerLAB

docker exec -i -t clab-ipv6-ws-R2 bash

Google devuelve: 403. That’s an error. Your client does not have permission to get URL / from this server. That’s all we know.

Introducción:

  Quieres hacer una búsqueda en google y la página te devuelve: "403. That’s an error.

Your client does not have permission to get URL / from this server. That’s all we know."

En mi caso me encontraba utilizando un túnel IPv6 con Hurricane Electric, específicamente el /64 que entregan en los tuneles. 

¿Solución?

   Pedirle a Hurricane Electric en el portal un /48 enrutado.  Listo!, quité el anterior prefijo /64 del SLAAC del router, dejé solo un /64 perteneciente al /48.

Suerte!

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!

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.

Solución "Unable to parse package file " luego de apt

 Problema:

    Obtenemos un error después de ejecutar cualquier comando apt en Linux

Solución:

    La solución es muy fácil, les comento que pasé muchas horas arreglándolo.

    Solo tiene que eliminar el archivo mencionado en el error, en mi caso obtuve: "E: Unable to parse package file /var/lib/apt/extended_states (1)"

    Acabo de borrar el archivo /var/lib/apt/extended_states

  Ejemplo:

    #sudo rm /var/lib/apt/extended_states

  Eso es todo, suerte!

Solución: VBoxGuestAdditions.iso (VERR_PDM_MEDIA_LOCKED)

Situación: 

   Cuando intentando insertar los Guest Addition en una VM Debian recibes: VERR_PDM_MEDIA_LOCKED 

Solución: 

   Hay varias soluciones, por ejemplo: 

1) Ejecutar: 

   sudo apt-get upgrade 

   sudo apt-get install virtualbox-guest-additions-iso

2) Remover e insertal el CD dentro de la configuración de la máquina virtual

3) Dejando una unidad óptica en blanco

y una cuarta solución que justo la acabo de hacer y quise publicar este post:

a) Arranca la VM

b) Abre un terminal

c) Ejecuta:

  sudo su

  cd /media

  mkdir cdrom

  mount /dev/cdrom /media/cdrom

  cd cdrom

  sh VBoxLinuxAdditions.run

Espero sea de utilidad.

Alejandro,

Global spending on public cloud services is expected to grow 18.4% in 2021 to total $304.9 billion (Gartner).

Solución: GNS3 - Private Vlan - non-operational - Cisco

Situación:

  En resumen: no te funcionan las private VLAN en GNS3 (IOU - VIRL).

Solución:

  Utiliza IOU i86bi-linux-l2-adventerprisek9-15.2d.bin

Test:

IOU3#show vlan private-vlan 

Primary Secondary Type              Ports

------- --------- ----------------- ------------------------------------------

500     501       community         Et0/1, Et0/2, Et1/0

500     502       isolated          Et0/0, Et0/3, Et1/0

Suerte!,

Solución: Finder en MAC no consigue ningún archivo en sus búsquedas

Problema:

  Finder no consigue archivos al momento de realizar alguna búsqueda.

Solución:

  Se que hay muchas soluciones, muchas con spotlight en preferencias del sistema, pero la que me funcionó a mí fue abrir una ventana terminal y ejecutar:

 #sudo mdutil -E /

   Espero sea útil,

Solucion: Closing connection because of an I/O error en FRR

 Hola,

  Si recibes el siguiente error en FRR:

Closing connection because of an I/O error

  la solución que yo tuve fue compilar de nuevo agregando el flag:

--enable-systemd

  Sería algo como:

./configure \

    --prefix=/usr \

    --includedir=\${prefix}/include \

    --enable-exampledir=\${prefix}/share/doc/frr/examples \

    --bindir=\${prefix}/bin \

    --sbindir=\${prefix}/lib/frr \

    --libdir=\${prefix}/lib/frr \

    --libexecdir=\${prefix}/lib/frr \

    --localstatedir=/var/run/frr \

    --sysconfdir=/etc/frr \

    --with-moduledir=\${prefix}/lib/frr/modules \

    --with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins \

    --enable-configfile-mask=0640 \

    --enable-logfile-mask=0640 \

    --enable-snmp=agentx \

    --enable-multipath=64 \

    --enable-user=frr \

    --enable-group=frr \

    --enable-vty-group=frrvty \

    --enable-systemd \

    --with-pkg-git-version \

    --with-pkg-extra-version=-MyOwnFRRVersion

  Puedes seguir las las instrucciones en: http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html  y agregar mi propuesta.

Suerte.

Solución: Macbook Pro Barra touch de volumen y brillo no funcionan

Problema:
  La barra touch de la Macbook pro se guindó, la toco y no funciona, no puedo cambiar brillo, volumen ni otras cosas

Solución:
1) Abrir un terminal
2) En el terminar ejecutar el comando:
 killall ControlStrip


Ejemplo:

Espero haya sido útil

GNS3. Solucion sencilla al error: "Please configure before the GNS3 VM in order to use this device"

Error:
    "Please configure before the GNS3 VM in order to use this device"


Solución:
a) Marcar/chequear "Enable the GNS3 VM" en:







Suerte,

Python3: Una solucion a UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 26: ordinal not in range(128)

Situación:

  Al ejecutar un script en python3 se recibe un error similar a:

UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 26: ordinal not in range(128)

Solución:

  El problema viene dado (tal como lo explica el mensaje) por manejo de strings y unicode, muy seguramente el código contiene algún tipo de carácteres en  

español, portugués, árabe u otro idioma no cubierto por ASCII

  Si lees en Internet hay DECENAS de maneras de solucionar esto, yo solo voy a mencionar una que funciona y es MUY sencilla.

  Si te encuentras en Linux o MAC es tan sencillo como colocar esto antes de ejecutar tu script (dentro de bash):

export PYTHONIOENCODING=utf8

  Lo que se esta haciendo es declarar la variable de entorno PYTHONIOENCODING a utf8, python3 al ser ejecutado utilizará esta variable como encoding y tu problema será resuelto.

  Claro, pudieses colocar dicha variable al entrar a tu sesión, o dentro de un script en bash que posteriormente llame a tu .py, etc, etc.

Suerte, espero haya sido útil.

 

Demostración: Antispoofing IPv6 en un router Cisco IOS

El siguiente video muestra como simular un ataque spoof en Internet y como prevenir el mismo en Cisco IOS

 

Solucion: "mtr: Failure to start mtr-packet: Invalid argument"

Hola,

  Al ejecutar mtr en MAC (en mi caso Sierra) obtienes:

mtr: Failure to start mtr-packet: Invalid argument

  El problema es que "mtr-packet" no está en tu PATH, debes ubicar donde se encuentra -generalmente en /usr/local/sbin-. Puedes buscarlo con:

#find / -name mtr-packet 

  Luego tienes que agregar el directorio que lo contiene al tu PATH. Para hacerlo:

Solución 1:

  En un terminal:
  PATH="$PATH:/usr/local/sbin"

Solución 2:

  Agregar una linea "/usr/local/sbin" /etc/paths, por ejemplo:

  echo "/usr/local/sbin" >> /etc/paths

  Espero te sirva,

Solucion a errores: OpenVPN daemon() failed or unsupported: Resource temporarily unavailable (errno=11)

Introducción: 
    Tengo estos errores en syslog luego de intentar levantar openvpn:

May 7 12:59:47 server ovpn-server[764]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
May 7 12:59:47 server ovpn-server[764]: daemon() failed or unsupported: Resource temporarily unavailable (errno=11)
May 7 12:59:47 server ovpn-server[764]: Exiting due to fatal error

Solución: 
   En el archivo:

 /lib/systemd/system/openvpn@.service 

Ubicar la linea:
LimitNPROC=10 
y comentarla, quedaría así:

#LimitNPROC=10 



   Reiniciar el servidor y listo.

 Espero te ayude.

Solución al error en gns3: "-bash: telnet: command not found"

Intro:
  Al ejecutar GNS3 y quererme conectar por consola a los equipos recibo el error: "-bash: telnet: command not found".  Muy probablemente luego de querer de hacer upgrade a MAC OS Sierra.
 
Solución:
  Hay que instalar telnet, recomiendo los siguientes pasos:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

brew tap theeternalsw0rd/telnet

brew install telnet

Referencias:

https://www.reddit.com/r/osx/comments/6jtxgz/telnet_not_found/