Archivos de Categoría: Red

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.

 

Añadiendo una segunda fuente a un Mikrotik CCR 1036

Publicado originalmente en inglés en el foro de Mikrotik.
Tres de las fuentes originales petaron en solo dos semanas, todas ellas con una chepa en C10:
C10 reventado

Por ello, tuve que invertir algún tiempo en el asunto. Los resultados han sido como sigue.

La primera decisión fue fácil. Dado que las fuentes conmutadas de los 69W necesarios (según las especificaciones en http://www.cloudcorerouter.com/) no son muy caras, decidimos cambiarla por una mejor. La elegida fue la experimentada Traco Power TOP 100, aunque probablemente echaré una mirada a su nueva, y más compacta, TPI 100-124A-J más adelante. Ambas suministran 100W.

Una de las cosas más dolorosamente ausentes en los CCR 1036 es fuentes dobles. El problema es que hay poco espacio dentro de la caja, por lo que se precisa una fuente minúscula. Me decidí por la Mean Well EPS-65S. Aunque un pelín por debajo de lo requerido, permite extraer picos de 71,6W durante 10 segundos, lo cual debe ser suficiente: nunguno de nuestros CCR 1036 en producción se lleva más de 55W contínuamente. Y lo importante es que su perfil es bajo, con una altura de solo 24mm desde la base de la placa hasta la parte superior.

Para instalar esta fuente, diseñé e imprimí en 3D una base que se atornilla a la parte izquierda de la placa base del router con los tornillos originales:

second ps support

Este es el archivo original de la base en OpenSCAD.

La fuente se atornilla a esta base con tornillos, arandelas y tuercas M3.

Los conectores de las fuentes están especificados en sus respectivas hojas de características. Desgraciadamente, una usa Molex y la otra JST; ambos son baratos y fáciles de montar.

Cuando empecé a probar, me encontré con que cuando cortaba la alimentación a la Mean Well, el router rearrancaba. Creo que tira un pico de carga y este pico tira la Traco Power, porque estas fuentes no fueron diseñadas para la redundancia. Esto se resuelve insertando un diodo 1N4004 entre la salida +V de la Mean Well y la placa base. En la próxima conversión, añadiré otro diodo a la otra fuente, por si acaso.

Arreglado eso, las pruebas fueron bien. Cualquiera de las dos fuentes puede arrancar el router y mantenerlo andando durante tanto tiempo como he probado hasta ahora. El router no se entera de un corte a una sola de las fuentes.

La Traco Power se calienta un poco, pero no mucho. La Mean Well, probablemente porque su diodo mantiene su voltaje ligeramente por debajo de la otra y por tanto no recibe carga, se mantiene fría.

Un poco más de prueba en el banco, luego algo de pruebas en el centro de datos, y si no sale nada, verán luz verde para producción.

IMG_8702

guifi.net

La iniciativa guifi.net podría llamarse la Internet por el aire, o la InfoVía de nuestros días, pero hecha para la gente y sin las ridículas pretensiones que caracterizaron al engendro de Telefónica.
Consiste el asunto en hacer una red empleando enlaces inalámbricos para usarla en lo que hubiere menester. Cada uno se paga el cacho de infraestructura que pone en su casa (o en su azotea), y poco a poco se va construyendo red.
¿Menesteres? Cualquier cosa que sea útil a los que están enganchados: Compartir acceso a Internet es lo más inmediato, pero a poco que se pone a trabajar el ingenio, salen más ideas: Copias de seguridad remota, compartir archivos, conectar redes… Vamos, para lo que sirve una red.
En guifi.net los enlaces se hacen sin encriptación. No se hacen ilusiones sobre la robustez de las encriptaciones inalámbricas; en su lugar, sugieren que los participantes se busquen la vida para asegurar su tráfico.
Este que escribe, se ha comprado su equipo (una antena de la firma Ubiquity que tiene un coste muy comedido para su calidad y prestaciones) y se ha conectado. A ver qué se puede hacer. Por ahora, buscarle un mástil mejor. Posiblemente, compartir acceso a Internet. Ya veremos. La cosa tiene un aroma 1.0 que mola.