Archivos de Categoría: Red

Nexus: Molan, hasta que se convierten en ladrillos al actualizarlos

Era un día normal para un venerable y fiable Nexus 3000, concretamente un 3064 que corría NX-OS 6.0(2)U6(6) tras una pequeña actualización sin novedad y sin hacer más que conmutar paquetes a nivel 2.

Había llegado para él el día de actualizar. Se había decidido que iba a empezar a terminar vLANes, es decir, a nivel 3; lo cual requiere ponerle direcciones IP públicas, y las versiones 6 tienen algunos feos fallos de seguridad. Por supuesto que a base de ACLs y/o cortafuegos es posible aislar lo bastante las IPs públicas de un gateway. Pero ya hace muchos años que Rommel popularizó la defensa en profundidad, y en redes es más que aplicable lo que tanto sufrimiento costó entender a los militares.

El concienzudo proceso de actualización de los Nexus requiere, en este momento, pasar por varias versiones intermedias partiendo de la 6 hasta llegar a la deseada, la 9.3.8 en el día de actos. Así que, armados con la paciencia nacida de la experiencia, mandamos la 7.0.3.I7.9. Runtime checks, boot variables, configuration copy y todo lo habitual hasta llegar a

Finishing the upgrade, switch will reboot in 10 seconds.

Fue lo último que dijo.

Mosqueados tras un ratito, consola en ristre, desenchufado de la corriente y vuelto a enchufar, nos informa por la consola:

(c) Copyright 2011, Cisco Systems.
N3000 BIOS v.4.5.0, Thu 11/09/2017, 05:38 PM

Y nada más. Ni boot loader, ni pulse Del… Nada.

Colgado.

Vaya, qué inconveniente.

Así que vamos a ver qué se hace en estos casos. Buscando por Internet no encontré nada de nada, así que escribí en los foros de Cisco. Las respuestas no pudieron ser más descorazonadoras: Una vez se aseguraron de que lo habitual no iba a funcionar, solo quedó como posibilidad abrir un caso con el TAC de Cisco y probablemente cambiarlo.

Pero estos switches ya otoñales no suelen tener un SmartNet activo, y Cisco ya no hace caso de nadie sin ello. Así que, mientras uno buscaba (con poco éxito) si aún se venden SmartNets para este modelo, el otro fue a desmontar el equipo, convencidos de que la cosa iba para largo. Tal vez, razonamos, haya alguna forma de fulminar la memoria flash y obligarle a irse al boot loader; o de hacerle arrancar de alguna manera.

Foto del módulo eUSB
Módulo eUSB fabricado por Viking Technology

Pues sí. Y más fácil que lo que nos temíamos.

El almacenamiento en estos equipos es una memoria flash USB. Es una versión un poco especial de USB, pensada para entornos industriales y para montarse de placa a placa, pero es USB al fin y al cabo. Está sujeta con un tornillo a la placa base y lleva un conector estilo DB9 miniaturizado (tal vez un Hirose DF9).

Bueno, pensó alguien. ¿Y si arranco el equipo sin la flash?

Dicho y hecho:

Press ctrl L to go to loader prompt in 2 secs

loader>

¡Tenemos boot loader! Desde aquí, ya todo es un paseo: Con el boot loader, se le puede arrancar por tftp o por un pincho USB. Esto último, con el equipo sin red fuera de la mesa, parece lo más inmediato…

loader> boot usb1:nxos.7.0.3.I7.9.bin

Pero, parafraseando al androide chungo de Blade Runner, el dios de la mecánica no se había terminado de ciscar en nosotros aún, y al equipo en cuestión no le daba la gana de arrancar desde el puerto USB.

Vaya.

Lo siguiente.

¿Y si, dado que se puede desmontar este módulo, probamos con el de otro equipo parecido?

Dicho y hecho, en menos de lo que se tarda en leerlo estábamos quitando los aproximadamente 150.000 tornillos Phillips del 1 de una aleación similar a la plastilina que sujetan la tapa del segundo equipo y cambiando su módulo al enfermito.

Y arrancó. Sin más. Bueno, es lo que esperábamos, ¿no?

Lo que no esperábamos es que el módulo del switch enfermo… Hiciera arrancar al «donante». Pero había que rendirse a la evidencia, evidencia presentada en nuestro terminal con un lacónico

%ASCII-CFG-2-CONF_CONTROL: System ready

Pofale.

Desde aquí, actualizar con mucho cuidadito nuevamente y a correr.

Mola la informática. Aunque a veces… Felix qui potuit rerum cognoscere causas. Aunque, en el caso que nos ocupa, nada más actualizar y en el siguiente arranque, pasó casi desapercibido un mensaje que decía algo así como: «Vaya, el firmware eUSB necesita actualizarse. Voy para allá… Hecho, sigamos con lo nuestro».

Vaya.

ix0: Unsupported SFP+ module detected!

Ya el año pasado, me tocó lidiar con la estúpida decisión de Intel de que sus chips de 10G no funcionan con los SFP que no entran en la corta lista de los que tienen probados.

La historia se repite, y esta vez ha sido un venerable FreeNAS 11.1 en un nuevo armario y con nuevos y flamantes cables AOC el que lleva el controlador de Intel que ha decidido, vaya hombre, que los AOC no son lo bastante flamantes; que si eso, que compre otros.

Uno no tiene tiempo ni ganas de dejarse llevar por las veleidades de una empresa que tiene gente trabajando en puestos que llevan a la vez la palabra technical y la palabra marketing (pobrecicos).

Usando la clásica técnica de poner en un buscador el mensaje de error que sale en dmesg y que da título a este artículo, en seguida se llega a algún ticket del redmine de IXsystems / FreeNAS; no en vano es uno de los mayores distribuidores de FreeBSD del momento.

El caso es que, como suele suceder, las cosas no pueden ser tan fáciles.

¿Es cierto que añadir a /boot/loader.conf las palabras mágicas:

hw.ix.unsupported_sfp=1

resuelve el problema? Si.

Pero no es menos cierto que en la versión 11.1, no. Vamos, lo ignora completamente en la versión que va en el kernel de la 11.1.

Así que, usando la clásica y probada por la experiencia técnica de la huida hacia delante, me bajé la ISO de la última estable de FreeNAS y le hice una actualización in situ. Las actualizaciones de FreeNAS son una gozada, si bien hacerlas sobre uno de esos KVM viejos de Supermicro no son la mejor experiencia del mundo. Pero en una máquina virtual Windows bien añeja (de Windows 7 para atrás) funcionan, así que no me voy a quejar demasiado. Total, hace años que por estas cosillas dejé de comprar Supermicro y pasé a comprar Dell.

Una vez hecha la actualización, arrancado el sistema nuevo, ya todo…

…Una mierda. Resulta que la actualización instala su propio /boot/loader.conf. Bueno, no pasa nada: Otra vez KVM basado en Java y volver a añadir hw.ix.unsupported_sfp=1 al final del ficherito.

Y esta vez sí, por fin, quejándose como un abuelo hablando de política en el bar del pueblo, por fin levantó los puertos de 10G. Y el resto, como se suele decir… Es historia.

Los switches HP 7900 y sus rutas inactivas

No molan mucho, la verdad.

Los HP 7900 y sus compañeros de gama pelo arriba, pelo abajo, corren Comware. Comware es un sistema operativo que HP compró en el paquete de 3Com en 2010. Había sido diseñado por H3C, en la que 3Com participaba junto con Huawei y de la que compró a su socio su parte en 2007. Esto es el motivo por el que los switches HP y los Huawei hablan el mismo idioma.

Recientemente, nos encontramos un caso en que se había instalado un par de switches HP7900 en cluster para un proveedor de servicios de alojamiento, perdón, de cloud. En seguida se hizo evidente que una de las primeras necesidades, desde un punto de vista de diseño de red, era una frontera nueva: Los HP solamente tienen memoria para 32.768 rutas aprendidas por BGP, mas alguna (unas pocas) «extra». En el momento de escribir este artículo, la Tabla va por encima de las 800.000, y subiendo. Evidentemente, no podían hacer ni un atisbo de balanceo de tráfico, y olvidémonos de puntos neutros o cualquier otro refinamiento.

Lo interesante que observé en Comware es que, cuando se le acaba la memoria para rutas, no tira la sesión de BGP que le ha llenado la memoria, como hacen los Cisco (y con ello agravando el problema); simplemente, está llena, pues está llena: Ya no se instalan más rutas.

Pero no se instalan, no se instalan: Si con la memoria llena se añade una IP a un interface, ese interface no funciona a nivel 3 porque no tiene memoria ni para la ruta conectada.

¿Solución que le daban localmente a este problema? Reiniciar el bicho. ¿Por qué si se reinicia ya funciona el nuevo interface? Fácil: Las conectadas llegan antes a la tabla que las aprendidas por BGP, que han de esperar a que la sesión se establezca. Pero claro: Toda la red sin conectividad ninguna mientras dura el rearranque. Ole.

En fin. Una pareja de Mikrotiks resolvió muy lindamente una frontera nueva. A día de hoy, la propuesta de Mikrotik no es una panacea: Seguimos esperando una implantación de BGP mejor, y sería deseable que la estabilidad mejorase un pelo. Pero funcionan en general bastante bien, conmutan tráfico como campeones, tienen IPFix (algo casi imprescindible en nuestros días), y el precio es imbatible.

Los ventiladores de los Mikrotik CCR1036

El sol lucía a mediados de Agosto en la calle cuando, en el CPD, un CCR dijo que uno de sus ventiladores había dejado de girar.

El ventilador en cuestión pertenecía a un Mikrotik CCR 1036 (si, uno de esos a los que ya a estas alturas he hecho mil perrerías, como meterles doble fuente o cambiar condensadores de estabilización de los chips Ethernet).

Algo fastidiado, porque este tipo de equipos generalmente es un tanto complicado desmontarlos estando en producción, me puse a investigar.

Por un lado, encontré un documento PDF titulado «TroubleShooting for CCR1036/CCR1016«. No estoy seguro de su autoría; los metadatos dicen que fue creado con la aplicación Draw de OpenOffice 3.4.1 el 6 de Diciembre de 2013, pero no tienen nada en el campo de autor. En él, se dice que si el ventilador no va, se verifique el transistor Q133. Q133 es un transistor SMD minúsculo, por lo que empecé a rezar a Santa Tecla para que lo roto fuera el ventilador, y no Q133.

Total, que cogí un ejemplar del taller y me miré los ventiladores. Los fabrica Chiefly Choice, su modelo CC 4028B12M. En el momento de escribir este artículo, aquí está su hoja de características. En resumen, es un ventilador de rodamientos de bolas, de 40x40x28 mm; a cambio de 190 mA a 12V, gira a 7000 rpm, moviendo casi 13 CFM (368 l/m), emitiendo un ruido de 33 dBA. O eso dice el fabricante.

En Digi-Key encontré casi 100 posibles sustitutos, muchos de ellos con ventaja. Y ya tenía el dedo en la lista de la compra, cuando el router dijo que el otro ventilador se había parado.

Dos ventiladores de los dos que tiene el chisme parados dan para acojonar al más pintado, porque ya sabemos lo que sigue a continuación: La temperatura empieza a subir rápidamente, y el trasto empieza a rearrancar, lo cual lo enfría un poco, pero en seguida se vuelve a calentar y así se queda, en un bucle sin fin de autodestrucción.

Pero sucedía algo extraño. La temperatura no subía. El trasto seguía clavado en sus 50 grados en placa (60 en el procesador) y diciendo que tenía todos sus ventiladores parados.

Más moscas que las que hay en un laboratorio de teleportación, nos acercamos al centro de datos a meter una brida por la parte trasera del chisme, y… ¡Ñiooooook! Aquello estaba girando, como siempre desde que se enchufó la última vez y se empezó a calentar.

Parece improbable que los dos sensores hayan fallado a la vez, por lo que me inclino a pensar en un fallo de RouterOS. Que he buscado, pero no encontrado; así que lo actualizaremos y ya veremos lo que nos depara el futuro.

Para la posteridad, aquí queda este testimonio de que (a) los CCR1036, al menos una vez, indicaron que estaban sin ventilación no siendo cierto; y (b) las características y referencia de los ventiladores, y posibles sustitutos.

BFD: Mola, a no ser que a alguien se le ocurra que mola demasiado

BFD (RFC 5880 y ss) es un protocolo independiente del enlace para detectar rápidamente fallos en los mismos. La teoría de funcionamiento es similar a la de un «hello» como los que se usan en OSPF, BGP, etc: Ambos lados esperan recibir periódicamente paquetes BFD del otro y, de no recibirlos, suponen fallecido el enlace y hacen lo que sea que resulte apropiado.

Además del protocolo base, RFC 5881 define BFD sobre IPv4 e IPv6, y RFC 5882 define algunos casos de uso y detalles para implementarlo.

La cosa no está nada mal pensada, excepto por el hecho de que no está definido en ninguna parte si BFD, en los equipos e interfaces que lo pueden llevar, debe estar activado salvo configuración en contra, o no.

Cisco, en su prudente sabiduría, implementa BFD. Si se quiere utilizar, hay que activarlo explícitamente. Algo muy de agradecer, a diferencia de la florida historia del mal parido «Smart Install». Que de smart, la verdad, tiene bien poco.

Mikrotik, por su parte, quizá pensando que esto de BFD mola, lo activa por defecto… Pero ojo, lo hace en los interfaces en que se configura OSPF. Aguanta y tira. O sea, que uno todo confiado añade un interface para hablar OSPF con un Cisco, y comprueba sorprendido cómo la adyacencia se cae y reestablece cada pocos minutos. Carallo, ¿y eso?

Pues BFD. Como el Mikrotik lo activa por defecto en los puertos que hablan OSPF, asume que el otro lado también va a tenerlo activado. Ah, que el otro lado es un Cisco y no… Pues nada, cada minuto el BFD decide que el enlace se ha caído, y por tanto lo sensato es volver a negociar.

BFD está bien, pero en un enlace Ethernet a giga o superior, con todas sus garantías, no parece que añada mucho y no deja de ser un servicio que puede tener problemas. Así que, en general, opto por

/routing/ospf/interface set use-bfd=no numbers=x

Y como se decía antes: Muerto el perro, se acabó la rabia.

Mikrotik y el puerto 2000

A veces, uno tiene la sensación de ser el último en enterarse.
Así me ha sucedido con el peculiar uso, por parte de Mikrotik, del puerto 2000 (que IANA asignó al protocolo SCCP de Cisco en el ya lejano año 2003).
Ellos lo usan para una herramienta llamada bandwidth-server, cuya utilidad en este mundo es probar el ancho de banda de una red conectada a un Mikrotik. Y lo mejor de todo: Está disponible tanto por TCP, como por UDP.
¿Soy el último en pensar que esto es una mala idea, dicho con toda la diplomacia de que soy capaz?
En fin. A lo que voy:
/tool bandwidth-server set enabled=no
Y se acabó el problema. Problema que no debería existir, para empezar a hablar.
Así que voy a añadir esta línea a mi receta de Ansible para Mikrotiks, junto con deshabilitar la pila de servicios que vienen por defecto habilitados.

phpipam: Mola mucho

Hace muchas, muchas lunas, tenía toda la red documentada con un MediaWiki. Incluso hice una ñapilla para recoger las descripciones de los puertos de los switches y generar con ellas una tabla automáticamente; la mandé a la lista de ExNIC hace ocho años:

Aquí os dejo una pequeña barbudez que he parido. Se trata de una extensión para MediaWiki que saca una tabla de interfaces de un trasto de Cisco; está pensado para switches. Disculpad los comentarios en espanglis y demás, resultado de copiar y pegar ejemplos de acá y allá.

Para hacerlo funcionar, hay que:

1. Ponerlo en un sitio adecuado (típicamente, extensions/tablainterfaces/tablainterfaces.php)
2. Añadirlo como extensión (añadir a LocalSettings.php, normalmente al final:

require_once «$IP/extensions/tablainterfaces/tablainterfaces.php»;

3. Meter en el código de la página que sea la llamada

{{#tablainterfaces:nombredeltrasto | community }}

(obviamente, nombredeltrasto puede ser un nombre o dirección IP, y es recomendable una community con solamente permiso de lectura).

Se admiten sugerencias.

Cuidado con los saltos de línea que introduce el editor de correo. Salud.

<?php

# Funcion de enganchar
$wgExtensionFunctions[] = ‘Iniciar_Tabla_Interfaces’;
# Add a hook to initialise the magic word
$wgHooks[‘LanguageGetMagic’][]       = ‘ElParseador_Magico’;

function Iniciar_Tabla_Interfaces() {
global $wgParser;
# Enlazar la palabra ‘tablainterfaces’ con nuestra funcion
$wgParser->setFunctionHook( ‘tablainterfaces’, ‘EscupirTablaInterfaces’ );
}

function ElParseador_Magico(&$magicWords, $langCode ) {
# Add the magic word
# The first array element is case sensitive, in this case it is not case sensitive
# All remaining elements are synonyms for our parser function
$magicWords[‘tablainterfaces’] = array( 0, ‘tablainterfaces’ );
# unless we return true, other parser functions extensions won’t get loaded.
return true;
}

function EscupirTablaInterfaces(&$parser, $dispositivo = », $community = » ) {
# The input parameters are wikitext with templates expanded
# The output should be wikitext too
# Codigo SNMP inspirado por jmartinson(AT_nospam)info234.com en php.net

// Solamente valores. Sin esto, devuelve el tipo tambien, p.e.: INTEGER: 1
snmp_set_quick_print(TRUE);

// For sequence types, return just the numbers, not the string and numbers.
// snmp_set_enum_print(TRUE);

// Don’t let the SNMP library get cute with value interpretation.  This makes
// MAC addresses return the 6 binary bytes, timeticks to return just the integer
// value, and some other things.
// snmp_set_valueretrieval(SNMP_VALUE_PLAIN);

$ifIndex = snmp2_walk(«$dispositivo»,»$community»,»interfaces.ifTable.ifEntry.ifIndex»);
$ifDescr = snmp2_walk(«$dispositivo»,»$community»,»interfaces.ifTable.ifEntry.ifDescr»);
$ifAdminStatus = snmp2_walk(«$dispositivo»,»$community»,»interfaces.ifTable.ifEntry.ifAdminStatus»);
$ifOperStatus = snmp2_walk(«$dispositivo»,»$community»,»interfaces.ifTable.ifEntry.ifOperStatus»);

$tabla =  ‘{| border=»0″‘.»\n»;
$tabla .= » |+ Tabla de interfaces de $dispositivo\n»;
$tabla .= » ! Puerto !! Descripci&oacute;n !! Estado oper. !!
Estado adm.\n»;
$tabla .= » |-\n»;

for ($i=0; $i<count($ifIndex); $i++) {
$tabla .= » | $ifDescr[$i]\n»;
$tabla .= » | «.snmp2_get(«$dispositivo»,»$community»,»IF-MIB::ifAlias.».$ifIndex[$i]).»\n»;

$tabla .= » | $ifOperStatus[$i]\n»;
$tabla .= » | $ifAdminStatus[$i]\n»;
$tabla .= » |-\n»;
}

$tabla .= » |}\n»;

return $tabla;
}
?>

El tiempo no pasa en balde, y aquella ñapilla que iba bien para tres o cuatro armarios con un puñado de switches en total, ya no llega. No solo por su inexistente modelo de seguridad; es que no creo que nadie la haya probado en Mediawikis más modernos que la versión de hace ocho años.

Afortunadamente, existe Eslovenia. La «Suiza del Este» ha dado su cuota de gente interesante, pero de particular interés hoy es un tipo llamado Miha Petkovsek.

El hijo de su ingenio, phpipam, es justo lo que su nombre da a entender: Una aplicación en php, sencillita pero pulcramente escrita, que permite llevar un inventario de las direcciones IP. En versiones recientes, también cuenta con un sencillo, casi rudimentario, pero útil, inventario de equipos; incluyendo coordenadas tales como ubicación geográfica, armario y U. ¿A que mola?

Phpipam tiene, por supuesto, su API REST que permite engancharlo (a base de wget si es menester) con los escriptillos y ñapillas diversas que adornan cualquier NOC que en la vida es.

La instalación no puede ser más sencilla; usa una base de datos MySQL, como la mayor parte de este tipo de aplicaciones. Se colocan los ficheros en su sitio, se configura el acceso a la base de datos, y a correr.

Mover un hipervisor de un vCenter a otro

Aprovechando la necesidad de reconstruír un vCenter debido a una muy extraña incidencia en un por demás fiable servidor Dell, decidí bajar el vCenter empaquetado que ofrece vmware.

Esto no es otra cosa que vCenter en Linux, concretamente una SuSE, con el software necesario para comportarse como un vCenter, empaquetado como una máquina virtual lista para desplegar.

He de decir que, aunque es un poco alienígena (¿qué ha hecho vmware que no lo sea?), funciona bastante bien en general. Y librarse de la licencia de Windows, y del Windows propiamente dicho, sienta bastante bien; no lo vamos a negar.

Ahora bien, hay que mover los hipervisores de un vCenter a otro. Y el switch distribuído está definido a nivel de vCenter, por lo que al cambiar de vCenter, las máquinas virtuales dejan de tener información sobre a dónde están conectados sus puertos. De momento funciona, pero no se puede tocar ni un puerto de una sola máquina virtual. ¿Qué vamos a hacer?

Migrar los puertos al switch distribuído del vCenter nuevo, claro.

Hay una opción maravillosa, al añadir un hipervisor al inventario de redes (Inventory->Networking) que casi no se ve: Migrate virtual machine networking.

Con esto, podemos elegir (tediosamente, puerto por puerto) a dónde conectar cada uno de los puertos de red de cada una de las máquinas virtuales.

Por supuesto, antes de desconectar el hipervisor del vCenter antiguo, hay que tener claro:

  1. Qué puerto(s) físico(s) del hipervisor es/son el/los asignado(s) al switch distribuído, para marcarlos al dar de alta al hipervisor en el inventario de redes.
  2. A dónde va cada puerto de cada máquina virtual.

Lo primero es trivial de mirar en la configuración; para lo segundo, me he hecho este pequeño guioncillo de PowerShell:

# Usuario y vCenter

$vcServidor = ‘vcenter.micasa'
$vcUsuario = ‘miusuario'
$vcClave = ‘miclave'

$hv=‘mihipervisor'
$historico = "C:\Users\yomismo\$(Get-Date -uformat "%Y%m%d-%H%M%S").sucesos"
Start-Transcript -Path $historico

Connect-VIServer $vcServidor -User $vcUsuario -Password $vcClave
$MVs = get-VMHost -name $hv | get-vm | sort name
Foreach($MV in $MVs) {
   $Adaptador=get-vm $MV | get-NetworkAdapter
   Write-Host ($MV.Name+" "+$Adaptador.NetworkName)
}

Armados con este conocimiento, y la paciencia de marcar a mano a cada interface en su red, podemos hacer el movimiento casi en menos que lo que se tarda en contarlo.

Por supuesto, es enteramente posible guardarnos la configuración de las máquinas virtuales y luego colocarlas con el mismo guioncillo. Pero entonces, ¿dónde estaría nuestro ojo inquisidor para detectar anomalías, ya de paso?

L2TP entre un router Cisco y uno Mikrotik

Supongamos que tenemos routers Cisco en casa de clientes funcionando desde tiempo inmemorial, estupendamente, y que no se quieren cambiar.

Supongamos además que, por el motivo que sea, necesitamos una VPN entre uno de esos routers Cisco y un Mikrotik que tenemos funcionando en otro sitio, como por ejemplo en un centro de datos.

Supongamos que nos ponemos a buscar documentación sobre el asunto… Y el resultado puede ser más descorazonador, pero por poco. Para saber qué versión de L2TP habla el Mikrotik, hay que remitirse al RFC (en resumen: La 2). Muchos IOS, no tienen una implantación completa de L2TP como la que he usado; si no existe pseudowire-class, lo mejor es ir directamente a otro IOS. Por ejemplo, en los 2801 que corren un venerable pero estabilísimo 12.4T, no hay en la IP Voice, pero sí en la IP Base. Los caminos del señor (el señor que empaqueta las versiones de IOS, quiero decir) son inescrutables.

Por resumir una horita de pelea: Esta configuración que adjunto, funciona. Ciertamente admite mejoras: Poner algo de encriptación, para empezar. Y seguramente sobre alguna cosilla, como por ejemplo la doble clave el en caso del Cisco. Pero tal como me ha quedado, lo cuento. Y cuando la mejore en un futuro, prometo intentar vencer la pertinaz procrastinación y actualizar el artículo.

Como ejercicio para el lector, dejo adivinar qué parte va en el Cisco, y qué parte en el Mikrotik.

El cliente:

l2tp-class Voz
 hostname l2tp-cliente
 password laclavequesea
!
pseudowire-class PseudoHilillo
 encapsulation l2tpv2
 protocol l2tpv2 EncapsulacionL2TP
 ip local interface Loopback0
!
interface Virtual-PPP1
 ip address negotiated
 ip mtu 1460
 ip tcp adjust-mss 1420
 ppp chap hostname l2tp-mikrotik
 ppp chap password laclavequesea
 pseudowire 10.0.0.1 11 pw-class PseudoHilillo
 !

Y el servidor:

/interface l2tp-server
 add comment=cliente name=l2tp-cliente user=l2tp-cliente

/interface l2tp-server server
set enabled=yes max-mru=1460 max-mtu=1460

/ppp secret
 add local-address=10.0.0.1 name=l2tp-cliente password=laclavequesea profile=l2tp-tunnel remote-address=10.0.0.2

 

El flujo de aire en los equipos de red

Es una vieja pelea, de esas que acaban por diluírse en el tiempo, poco a poco, con cambios que se van sucediendo y que acaban por hacer el problema irrelevante.

Los servidores, por una herencia que se remonta al diseño de los PCs originales, absorben aire frío por la parte delantera (donde están normalmente los botones, los dispositivos de almacenamiento, y las lucecitas) y los echan caliente por la trasera (donde están generalmente los conectores, enchufe y cerca de donde se sitúan las fuentes de alimentación).

Los switches de red, por su parte, empezaron por ventilarse de un lado al otro. ¿Por qué? Fácil: Es por donde había hueco. 48 puertos RJ-45 ocupan prácticamente todo el frontal de 1U en un armario de 19″. ¿Y los routers? Pues como Cisco decidió en su día: Pusieron en el frontal los conectores de red, en la trasera el de alimentación… Y empezaron a bufar hacia el lado contrario que los servidores.

Cuando la densidad fue creciendo en los centros de datos, la cosa empezó a ser un problema. Todo el mundo copió a los fabricantes pioneros como Cisco, y el resultado es que a 2016, los equipos de Mikrotik hacen lo que hacía Cisco en los 90: Coger aire del frontal, donde está su pantallita, sus luces y sus conectores, y echarlo hacia «atrás», que es donde está la fuente y el conector de alimentación.

Y con ello, los routers, definitivamente, quedan sólidamente establecidos con flujos de aire exactamente al revés que los servidores: Del lado donde están los conectores, al otro. Mientras que los servidores, fieles a su larga tradición, siguen enviando el aire del «otro» lado, al de los conectores.

En un centro de datos clásico, donde lo que hay es aire frío a cascoporro, cada equipo está montado como cayó, y los flujos de aire no están definidos, eso no es un problema. Pero, ¿qué ocurre en un centro de datos moderno, con separación de pasillo frío y caliente? Pues muy sencillo. Como de lo que más hay es servidores, se puede elegir entre tres alternativas para los equipos de red:

  1. Ponerlos con los conectores al mismo lado que los servidores, y que se frían por estar «respirando» aire caliente;
  2. Ponerlos con un flujo de aire correcto y pasar el resto de la vida moviendo cables de un lado a otro del armario;
  3. Arreglar el bendito problema de una vez, invirtiendo el flujo de aire para hacerlo igual que el de los servidores.

Así que, sin discurrir mucho más, vamos a examinar la alternativa 3.

Empezaremos por hacer notar que algunos fabricantes como Cisco o Juniper, en su infinita sabiduría, hace poco empezaron a fabricar switches (algunos, no todos) que se pueden pedir con los flujos de aire en un sentido o en otro, o incluso dar la vuelta a voluntad. Esto es perfecto para un entorno de centro de datos, sobre todo si hablamos de switches con 48 puertos y por tanto 48 cables que no hay que pasar de un lado al otro del armario y, lo que es más engorroso, mantenerlos.

Sin embargo, si vamos a ver los populares routers de Mikrotik, veremos que, ocupados en detalles sin importancia como crear equipos de una relación precio/potencia de otro mundo, siguen haciendo lo que Cisco en los años 90: Mover el aire al revés que los servidores.

Arreglemos, pues, ese problema.

En los CCR1036, la cosa es fácil. Solo tienen dos ventiladores, exactamente delante del disipador del procesador. Dos tornillos por cada uno, se les da la vuelta y problema resuelto.IMG_8714

En los CCR1072, la cosa es ligeramente más complicada. Llevan seis ventiladores: Cuatro delante del disipador del procesador (que se invierten de manera análoga a como se hace en los 1036) y uno en cada una de las dos fuentes de alimentación. En su infinita sabiduría, Mikrotik ha decidido que los tornillos de la carcasa de la fuente de alimentación sean T-5 (o por ahí), es decir, tirando a rarillos. Nada que no pueda resolver un juego de destornilladores «de precisión», que el chino de la esquina suministrará sin problema ninguno. Hay que desmontar completamente la fuente, sacando la PCB fuera, para acceder todos los tornillos. Pero hecho esto, y rutado el cable del ventilador por un lateral, se acabaron los problemas.

Por cierto, que todos los tornillos dentro de la fuente son los habituales Phillips del número 2. Y nos quejamos cuando Apple hizo aquella jugadita del «pentatorx»…IMG_8716

En el momento de escribir esto, he efectuado la operación en varios 1036 y un par de 1072. Como estos son los más grandes, parecen más interesantes. Pues bien, con el flujo de aire corregido, y cursando 1 Gbps de tráfico, la CPU se mantiene en unos tranquilizadores 50C y 54C; y eso, teniendo justo debajo un par de Catalyst con el flujo de aire al revés.