ESNOG/GORE numero 7

Me encuentro en pleno GORE/ESNOG-7, con interesantes charlas de Geoff Huston (APNIC) y Andreas Strikos (RIPE NCC), así como de otras rutilantes estrellas del networking patrio.

Celebrado en el Customer Innovation Center de BT Spain, un precioso y sencillo mirador en la planta 14 del edificio Herre, con bonitas y poco convencionales vistas de la "skyline" de Madrid:

BT España ha proporcionado el "hosting" y la conectividad del evento, así como las pausas de café, y la comida ha sido patrocinada por Espanix.

La asistencia (45 personas presentes) ha sido récord, y todos hemos disfrutado de un dia de intercambio de esperiencias, comentarios, y también un poco de comida gratis:

También se añadió un canal en Twitter: https://twitter.com/#!/Esnog1

RIPE-62

Siguiendo el consejo de mi amigo Marcos, retomo la edición de mensajes en este BLOG. Estoy en el RIPE-62 meeting y he tenido una mala experiencia con IPv6.

Después de una intervención de PAF, hice la prueba de la "ipv6-ilidad" del dominio del laboratorio:

http://go6.se/check/?domainname=lab.bt.es

y descubrí que el correo funcionaba mal. Pensé que era el POSTFIX en el servidor de correo del dominio plutarco.lab.bt.es el que iba mal, y revisé la configuración de acuerdo a la la página de ayuda de Postfix

http://www.postfix.org/IPV6_README.html

pero resultó que estaba bien. Pensando que el problema era el piojoso servicio IPv6 de la red del RIPE meeting durante los dias 1 y 2, desactivé IPV6 de mi Mac, e intenté ver lo que podría estar pasando en la LAN del Labo. Desde que migré mi usuario del equipo anterior, el MacBook Pro va bastante mal de rendimiento, entrando la "Beach Ball of Death" cada dos por 3:

Sorprendentemente, desde que desactivé IPv6 el Mac está funcionando MUCHO MEJOR, y así lo he dejado, sin IPv6. Realmente, parece mentira... pero es cierto.

Asi, aprovechando la coyuntura me puse a revisar la máquina del Labo (plutarco.lab.bt.es), he podido comprobar que recibe RAs de una máquina del labo que le hace pensar que ese equipo (el que manda el RA) es el mejor "default route" a utilizar, y el tráfico ipv6 en salida se pierde miserablemente:

root@plutarco:~# ip -6 route show

2001:ac0::/64 dev eth1 proto kernel metric 256 expires 1036857sec mtu 1500 advmss 1440 hoplimit 4294967295

fe80::/64 dev eth0 metric 256 expires 5883730sec mtu 1500 advmss 1440 hoplimit 4294967295

fe80::/64 dev eth1 metric 256 expires 5883730sec mtu 1500 advmss 1440 hoplimit 4294967295

ff00::/8 dev eth0 metric 256 expires 5883730sec mtu 1500 advmss 1440 hoplimit 4294967295

ff00::/8 dev eth1 metric 256 expires 5883730sec mtu 1500 advmss 1440 hoplimit 4294967295

default via fe80::290:1aff:fe42:8589 dev eth1 proto kernel metric 1024 expires 652sec mtu 1500 advmss 1440 hoplimit 4294967295

default via fe80::20a:f4ff:fe1b:a040 dev eth1 proto kernel metric 1024 expires 712sec mtu 1500 advmss 1440 hoplimit 64

default via fe80::210:7bff:fe6e:d4c1 dev eth1 proto kernel metric 1024 expires 689sec mtu 1500 advmss 1440 hoplimit 64

unreachable default dev lo proto none metric -1 error -51 hoplimit 255

El RA para fe80::290:1aff:fe42:8589 proviene de un ERX que está haciendo de concentrador de acceso para clientes ADSL en test de BT (aka, Tomás), y que se anuncia como router aunque no debería (esta pata es sólo la pata de tránsito, no tiene SLAAC). Además, tiene un divertido "hoplimit" de 4294967295.

Solución: capo la VLAN 4 en el trunk que une su switch con el switch donde está plutarco, y a esperar...

Por cierto, el comando que uso en el switch "dixie" es

clear trunk 1/1 4

donde "4" es la VLAN en la que flotan los RAs.