Cisco 7940G y Asterisk - Parte 2

Continuando con la entrada anterior, en esta ocasión les mostrare como autoconfigurar los teléfonos IP utilizando ficheros cnf y el servidor tftp.

Los teléfonos 7940G, al arrancar luego de descargar las imágenes de software a utilizar (en caso de no tenerlas aun), también descargan una serie de archivos .cnf, estos archivos según su nombre y estructura le indican al teléfono como configurarse, que extensión utilizar, nombre a mostrar en pantalla, aplicaciones (escritas en XML) que el teléfono puede utilizar, etc. 

SIPDefault.cnf

Es el primero de estos archivos, este archivo es común para todos los teléfonos IP, se utiliza para configurar las opciones comunes de todos los teléfonos (ejemplo, hora, fecha, planes de discado, etc.). 

ejemplo de contenido:

 logo_url: "URL del logo a mostrar en la pantalla"  
 directory_url: "URL de la aplicacion de directorio"  
 dial_template: "archivo del plan de discado"  
 date_format: "D/M/Y"  
 sntp_server: "FQDN o IP de servidor sntp"  
 sntp_mode: "unicast"  
 time_format_24hr: "0"  
 time_zone: "EST"  
 dst_offset: "-00:30"  
 dst_start_month: "August"  

Los dos primeros items se utilizan para asignar el logo y aplicación de directorio al teléfono, luego hablare de esto, solo entiendan por ahora que el teléfono descarga via HTTP tanto el logo (en formato bmp) como la aplicación y esta ultima debe estar escrita en XML.

el dial_template indica el nombre del archivo que contiene el plan de discado por el cual se regirá el teléfono, mas abajo encontraran un ejemplo de este plan de discado, todas las demás opciones están puestas de esa forma para colocar el teléfono en la hora estándar de Venezuela que es UTC -4:30, de aquí lo único que deben de cambiar es el FQDN o IP del servidor SNTP (por Internet hay muchas, y si utilizan algún router con esta capacidad pueden utilizarlo a el también como servidor de hora).

Plan de discado 

El nombre de este archivo es indiferente (debe contener la extension xml al final), solo deben tener en cuenta que deben referenciarlo en el parámetro dial_template y lógicamente debe estar en el mismo directorio que todos los archivos de configuración (que al final debe ser el directorio al que se tiene acceso por tftp), al igual que en Asterisk donde existe un plan de discado que indica que hacer según el numero marcado, estos telefonos también pueden tener uno, este plan de discado permite manipular los dígitos marcados, asignarle tonos, invalidar ciertos números, etc...

 <DIALTEMPLATE>  
 <TEMPLATE MATCH="..."      TIMEOUT="2"/>  
     <TEMPLATE MATCH="9*"      TIMEOUT="2"/>  
     <TEMPLATE MATCH="\**"      TIMEOUT="2"/>  
     <TEMPLATE MATCH="04........."  REWRITE="904%1" TIMEOUT="0"/>  
     <TEMPLATE MATCH="02........."  REWRITE="902%1" TIMEOUT="0"/>  
     <TEMPLATE MATCH="2......"    REWRITE="2%1" TIMEOUT="0"/>  
 </DIALTEMPLATE>  

Este plan de discado se basa en el hecho de que en la empresa para realizar llamadas externas se marca primero 9, adicionalmente hay unas reglas de reescritura que utilizo para la integración con el directorio, si quieren pueden utilizar este mismo, provisto que donde vayan a implementar el telefono las extensiones internas tengan 3 dígitos y las llamadas externas comiencen siempre con un 9.

Archivos de configuración por teléfono 

Estos archivos permiten configurar individualmente cada teléfono, asignar una extensión, nombre de usuario, etc. Estos archivos tienen el formato SIP.cnf donde es la dirección mac en mayúsculas y sin separadores (ejemplo, sin ":", "." o "-") del teléfono que se debe configurar, por ejemplo asumiendo que la dirección mac del teléfono es  ca:da:11:22:33:44 el archivo de llamaria SIPCADA11223344.cnf

 proxy1_address: "FQDN o IP del proxy (Asterisk)"  
 line1_name: "nombre de la extensión"  
 line1_shortname: "Nombre a mostrar en la pantalla del teléfono"  
 line1_displayname: "Caller ID"  
 line1_authname: "usuario para autenticar"  
 line1_password: "contraseña"  
 nat_enable: "0"  
 proxy_register: "1"  

Todos los items se explican por si mismo, excepto quiza line1_authname, aqui deben colocar el nombre con el que registraron la extensión para autenticarla, es lo que se encuentra entre corchetes [] cuando definen la extensión en el SIP.conf. Adicionalmente, nat_enable en 0 indica que los teléfonos no trabajaran utilizando NAT (chequeen esto si quieren saber mas), y proxy_register en 1 indica que el teléfono debe registrarse con el proxy utilizando los parámetros antes descritos para poder realizar o recibir llamadas.

Si quieren conocer mas sobre los parametros de configuracion de los telefonos 7940G con SIP, chequeen el siguiente enlace:

Guía de administración SIP Cisco

Parte 3 de la guia

Cisco 7940G y Asterisk - Parte 1

Recientemente me toco reformar el sistema telefónico de la compañía para la que trabajo, en una de las sedes se tiene implementado un "todo-en-uno" de Cisco (UC-520), este aparato incluye central telefónica, router, switch y gateway vpn,

Si bien en esa sede todo funciona correctamente con el UC-520, para la nueva sede se requería de una infraestructura mas expandible y que pudiese albergar mas usuarios de los que el UC-520 permite, adicionalmente aquí había una limitante a nivel monetaria, adquirir alguna solución telefónica de Cisco implicaba un desembolso considerable de dinero, así que me fui por la opción libre, Asterisk,

Asterisk trabaja principalmente con el protocolo SIP, así que a parte del servidor donde se instalaría y las tarjetas de interconexion PSTN (para poder ofrecer conectividad a redes telefónicas  externas), se necesita también de teléfonos IP compatibles con este estándar. Resulta que cuando la empresa adquirió el UC-520, también compro una gran cantidad de teléfonos IP Cisco 7940G, muchos mas de los que eran utilizados para ese entonces.

Para los que no lo sepan, estos teléfonos de fabrica trabajan es con un protocolo propietario de Cisco llamado SCCP, así que no me servían para trabajar con Asterisk, sin embargo investigando un poco encontré que Cisco hace unos cuantos años libero imagenes del software del teléfono compatibles con el estándar SIP, esta entrada es principalmente para indicarles como transformar los 7940G con la imagen SCCP a teléfonos compatibles con SIP, en proximas entradas les mostrare como configurarlos y adicionalmente integrarlos en un directorio telefónico interno centralizado.

Proceso de cambio de firmware

Vamos a necesitar:

1.- Obviamente el teléfono Cisco 7940G
2.- El servicio DHCP y TFTP
3.- El pack de imágenes de software SIP, van a necesitar los archivos (pueden descargarlos desde aqui):

      P003-8-12-00.bin
      P003-8-12-00.sbn
      P0S3-8-12-00.loads
      P0S3-8-12-00.sb2
      OS79XX.TXT
      cmterm-7940-7960-8.2.00-sip.cop

4.- Un archivo que llamaran "XMLDefault.cnf.xml" (notese que tiene 2 extensiones) y donde copian y pegan lo siguiente:

 <Default>  
 <callManagerGroup>  
 <members>  
 <member priority="0">  
 <callManager>  
 <ports>  
 <ethernetPhonePort>2000</ethernetPhonePort>  
 <mgcpPorts>  
 <listen>2427</listen>  
 <keepAlive>2428</keepAlive>  
 </mgcpPorts>  
 </ports>  
 <processNodeName></processNodeName>  
 </callManager>  
 </member>  
 </members>  
 </callManagerGroup>  
 <loadInformation8 model="IP Phone 7940">P0S3-8-12-00</loadInformation8>  
 <loadInformation7 model="IP Phone 7960">P003-07-1-00</loadInformation7>  
 <authenticationURL></authenticationURL>  
 <directoryURL></directoryURL>  
 <idleURL></idleURL>  
 <informationURL></informationURL>  
 <messagesURL></messagesURL>  
 <servicesURL></servicesURL>  
 </Default>  

Configuración servicio TFTP

En mi caso, el servicio TFTP radica en un servidor Linux corriendo CentOS, si tienen esta distribución instalada para poder activar el servicio TFTP básicamente editamos el archivo tftp, ubicado en /etc/xinetd.d/ para que nos quede así:

 service tftp  
 {  
     disable = no  
     socket_type       = dgram  
     protocol        = udp  
     wait          = yes  
     user          = user  
     server         = /usr/sbin/in.tftpd  
     server_args       = -c -s /tftp-directory  
     per_source       = 11  
     cps           = 100 2  
     flags          = IPv4  
 }  

Donde "/tftp-directory" es la ruta del directorio que piensan utilizar para almacenar los archivos que serán descargados por el teléfono mediante tftp (guarden aqui los archivos que les especifique arriba) y "user" el usuario como quieren que se ejecute el servicio. Luego de esto sencillamente escribimos en la consola "service xinetd restart".

Configuración servicio DHCP

El servicio DHCP corre actualmente en un servidor con Windows Server 2012r2, así que también aproveche este para poder realizar este trabajo, deben es asegurarse de crear un scope (ambito) para los teléfonos IP (con un rango de IP validos, gateway, dns, etc) y dentro de este scope se necesita agregar adicionalmente la opción 150, la cual por defecto no se incluye en el servicio DHCP asi que se debe crear, para crear esta opción realizamos lo siguiente:

1.- Nos vamos al administrador del servicio y presionamos sobre "IPv4" con el botón derecho del mouse,
2.- En el menu desplegable presionamos sobre "Configurar Opciones Predeterminadas..."
3.- En el cuadro que nos aparece presionamos "Agregar".
4.- Nos aparece otro cuadro donde debemos llenar los parámetros de la opción, aquí lo importante es que el tipo de dato sea "Dirección IP" y el código "150".

Asegúrense de que cuando configuren la opción en el ambito, apunte directamente al servidor donde funciona el servicio TFTP (en mi caso en el server que corre CentOS). 

Nota:

Estos pasos son como yo termine realizado el trabajo, sin embargo si no quieren hacerlo tal cual,, lo único que necesitan es tener el servicio TFTP y DHCP funcionando, el servicio TFTP debe tener acceso a los archivos que arriba describo y el servicio DHCP debe estar configurado para adicional a los parámetros básicos (ip, mascara, gateway, etc.) incluya la opcion 150 que apunte al servidor donde corre el servicio TFTP, hay una aplicacion para windows que incluye ambos servicios se llama TFTPD32. En mi caso lo realice de esta forma porque asi puedo sencillamente conectar un telefono a la red y ya se que todo esta preparado para que se actualice a SIP y descargue la configuracion de la linea a utilizar (mas adelante hablo sobre esto). 

Lógicamente deben asegurarse que el teléfono descargue su configuración del server DHCP, ya sea colocando el teléfono dentro del mismo segmento L2 que el servidor o utilizando un DHCP Relay. Recuerden que estos telefonos al ser Cisco, se pueden comunicar con equipos Cisco mediante CDP y obviamente son compatibles con la asignación de VLAN de voz mediante el comando "switchport voice vlan XXX".

Si han hecho todo bien, cuando conecten el teléfono a la red y lo enciendan, este comenzara a descargar los archivos del servidor TFTP luego de configurar su IP, si funciono, al final verán que el teléfono en la esquina superior derecha dice "UNPROVISIONED SIP", si no dice esto, algo hicieron mal, verifiquen todo y comiencen de nuevo.

Actualización: si por alguna razón, el teléfono se niega a descargar las imágenes del software para trabajar con SIP y en pantalla les coloca "SEP.xml.cnf file not found", lo que tienen que hacer es crear ese archivo y colocarlo en la raiz del servidor tftp, el contenido de este archivo debe ser el mismo que coloco arriba para el XMLDefault.xml.cnf.

Continua en: Parte - 2

DHCP y NAT

   Todos conocemos de cierta forma el funcionamiento de DHCP y de las traducciones de dirección de red (NAT). NAT es ampliamente utilizado hoy día para tratar de reducir el ritmo en el cual se agotan las direcciones IP enrutables públicamente (en la versión 4 del protocolo IP), es decir, las direcciones IP utilizadas en Internet, aunque NAT no solo se utiliza para lo anterior, también puede ser aplicado en estos casos:

1. Migración de servidores, dado que es mas fácil y rápido realizar un NAT a los paquetes cuando se migra un servidor de un segmento de red a otro que tener que decirle manualmente a cada estación de trabajo la nueva dirección IP de este, y aun si utilizamos DNS, dependemos enteramente del TTL, lo cual evita que la transición sea transparente y rápida si no se sincroniza este parámetro, por ello se suele hacer uso de NAT para estos casos.
2. Seguridad, a veces sencillamente no se desea que se conozca el o los segmento(s) de red detrás del router que realiza NAT. 

   DHCP por otro lado, evita que tengamos que configurar manualmente cada estación de trabajo, automatiza enormemente la asignación de direcciones de red y parámetros asociadas a estas, también habilita la autoconfiguración de servicios (como es el caso de los teléfonos IP). Normalmente nos encontramos con 2 casos de implementacion de servicio DHCP.

Caso nº 1

 El servidor DHCP, que puede ser tanto un servidor como un router, se encuentra dentro del mismo segmento de red que los equipos a los que va a servir, como se muestra a continuación: 

  En el caso anterior, no hay problemas, todo funciona correctamente con una configuración mínima. 

Caso nº 2

   El servidor DHCP no se encuentra dentro del mismo segmento de red que la red a la que sirve: 

   En este caso se soluciona haciendo uso de un DHCP-Relay Agent, el cual es un intermediario, que se comunica de parte del cliente que hace la solicitud con el servidor DHCP por medio de mensajes UNICAST, recordemos que DHCP funciona normalmente es con mensajes Broadcast. Esto tampoco tiene mayor inconveniente mas allá de configurar el relay que puede ser el mismo router que sirve de gateway a la LAN que solicita el servicio. 

Caso nº 3

   Básicamente casi igual al anterior, pero, antes del enlace con el DHCP Server se realiza un NAT. En este caso, notaremos que por mas que configuremos el Relay, los dispositivos que solicitan el servicio DHCP no obtienen respuesta, todo parece estar bien, se tiene conectividad con el DHCP Server, verificado mediante ICMP con algún dispositivo de la LAN que solicita el servicio configurado manualmente. Entonces, ¿cual es el problema?

   Recordemos lo siguiente, NAT traduce direcciones en el caso de un Source-NAT que suele ser lo habitual, se traduce la IP de origen a otra, tenemos entonces el siguiente caso:

1. 192.168.0.1 se quiere comunicar con 10.10.10.1.
2. El host A, quien es el que posee la dirección 192.168.0.1, esta detrás de un NAT, esto implica que cuando quiere comunicarse con 10.10.10.1, lo que el host B (el propietario de 10.10.10.1) "ve" como dirección de origen no es la IP del host A, sino la IP que fue asignada producto de la traducción. 
3. Hasta aquí todo bien, de no ser por como funciona DHCP por medio de un Relay tendríamos conectividad.

   Cuando se hace uso de un DHCP-Relay, este, dentro del mensaje DHCP envía un parámetro llamado GIADDR, este parámetro es la dirección IP de la interfaz que intercepto el paquete DHCP, el proceso es el siguiente:

1. Host A, quiere configurarse con DHCP, el segmento de red es 192.168.0.0/24, para esto, envía un mensaje DHCP-Discover en forma de broadcast, tal cual el protocolo lo estipula. 
2. Dentro de ese segmento, se encuentra el relay, cuya dirección IP es 192.168.0.1, este intercepta el broadcast y envía el mensaje como unicast a la dirección del servidor DHCP, incluyendo adicionalmente en el campo GIADDR la dirección IP 192.168.0.1/24 la cual es la dirección de la interfaz que intercepto el primer broadcast, luego en la cabecera IP incluye como dirección de origen, la dirección 192.168.0.1. 
3. Durante el trayecto hasta el servidor DHCP, ocurre un NAT, ahora la dirección IP de origen del mensaje anterior no es 192.168.0.1, sino la asignada por el NAT (diremos que es 201.202.203.1 en este caso). 
4. Cuando el servidor DHCP recibe el mensaje, se fija en los parámetros internos de este, en especifico el GIADDR dado que este parámetro es el que se toma como referencia para elegir el pool de direcciones IP de donde se asignara la dirección al host, recordemos que en este caso es 192.168.0.1/24.
5. Y aquí es donde viene el problema, el servidor DHCP no se va a fijar en la dirección IP de origen de la cabecera IP para responder el mensaje, sino que directamente utiliza la dirección IP incluida en GIADDR para responder, si, el o los routers que intervienen en el camino desde el server DHCP al relay, no conocen la forma de llegar a la red que se estipula en GIADDR, lo cual suele ser lo habitual si se utiliza NAT, el paquete jamas llegara de vuelta y por lo tanto los equipos jamas se podrán autoconfigurar. 

  Para solucionar esto se pueden hacer unas cuantas cosas:

• Aplicar enrutamiento basado en políticas y túneles IP/IP (GRE), de esta forma cuando detectemos el trafico generado por DHCP-Relay, que se maneja por protocolo UDP puertos 67 y 68, obligamos al router a utilizar como next-hop el tunel IP/IP, este encapsulara el paquete original en otro paquete IP y no realizara NAT, se debe realizar esto por norma general en el router que realiza el NAT.
• Utilizar túneles IPSec
• Utilizar una combinación de lo anterior, ejemplo, GREoIPSec.
• Crear rutas especificas a las redes que solicitan el DHCP, algo inútil en el caso de que la red intermediaria sea Internet y que adicionalmente elimina el propósito de NAT si se utiliza como mecanismo de seguridad. 

Usando Nagios para monitorear mediante SNMP

  Siguiendo con el tema anterior, una vez tenemos instalado el Nagios nos damos cuenta que por si solo no hace nada, debemos configurarlo y esta guía esta precisamente para ello. Antes de comenzar a agregar servicios para monitoreo, vamos a instalar un plugin llamado PNP4NAGIOS, este plugin nos permite tener a la mano gráficos de la data que produce Nagios, cabe acotar que este plugin no genera datos salvo que el check command (mas adelante hablaremos de esto) almacene información persistente de los datos que obtiene. 

 Realizaremos esto por etapas, la primera etapa es instalar el plugin PNP4NAGIOS y configurarlo, después descargaremos otro plugin llamado check_iftraffic64, el cual nos permite visualizar el consumo de ancho de banda de cada interfaz y trabaja muy bien con PNP4NAGIOS para generar gráficos en tiempo real de trafico de red. Luego les explicare de forma general como funciona Nagios y PNP4NAGIOS y procederemos al ejemplo (en este caso, vamos a monitorear un router TP-LINK flasheado con DD-WRT).

Instalando PNP4NAGIOS

Nota: Nuevamente asumiré que están en la consola de comandos de CentOS

1.- Descarga de PNP4NAGIOS

1.a- Nos vamos al directorio donde almacenamos los SRC de Nagios:

cd /usr/local/src/nagios/

1.b- Ejecutamos el siguiente comando:

     

wget http://sourceforge.net/projects/pnp4nagios/files/latest/download

2.- Instalando las dependencias de PNP4NAGIOS y check_iftraffic64

2.a- Ejecutamos el siguiente comando para instalar todas las dependencias de PNP4NAGIOS:

yum install perl rrdtool rrdtool-perl php-gd

2.b- Ejecutamos los siguientes comandos en orden:

perl -MCPAN -e shell 

tras lo cual la linea de comandos cambiara a: cpan[1]>

Dentro de esta nueva linea de comandos ejecutamos:

install Net::SNMP

esperamos a que termine de procesar y se devuelva a cpan[1]>

Ejecutamos ahora

install Net::DNS

Nota: si tienen algún problema (se queda pegada la consola después de ejecutar alguno de los "install"), vayan a /usr/share/perl/CPAN5 y dentro de esta carpeta editen el archivo Config.pm, busquen la linea que dice 'cache_metadata' => q[1] y cambien ese 1, por un 0. 

3.- Instalando PNP4NAGIOS y check_iftraffic64

3.a Descomprimimos el archivo de PNP4NAGIOS, seguimos en la carpeta donde lo descargamos así que nos toca ejecutar:

tar zxvf pnp4nagios-0.6.21.tar.gz

ahora nos pasamos al directorio donde se descomprimió

cd pnp4nagios-0.6.21

3.b Ejecutamos los siguientes comandos en orden para instalar PNP4NAGIOS:

./configure

make

make fullinstall

service httpd restart

3.c Verificamos que todo haya ido bien, para ello utilizando un navegador vamos a la pagina web http://IP-Servidor/pnp4nagios Si todo ha ido bien no veremos ningún error en esta pagina (todos los indicadores están en verde), de no ser este el caso, volver a revisar los pasos anteriores, de ser el caso entonces ejecutar:

mv /usr/local/pnp4nagios/share/install.php /usr/local/pnp4nagios/share/install.php.back

Como referencia aquí les dejo la pagina web como deberían de apreciarla:

3.d Instalamos ahora el plugin check_iftraffic64:

Nos vamos al directorio donde se almacenan los plugins

cd /usr/local/nagios/libexec/

Descargamos el check_iftraffic64.pl

wget http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=4019&cf_id=24

Cambiamos el dueño del plugin

chown nagios:nagios check_iftraffic64.pl

Cambiamos los permisos de ejecucion del plugin

chmod +x check_iftraffic64.pl

   Con lo anterior terminamos con la instalación ahora vamos a explicar un poco como funciona Nagios, como lo tenemos que configurar y comenzaremos a utilizar esto para monitorear un router TP-LINK, lo aquí explicado sirve para cualquier dispositivo que trabaje con SNMP. 

¿Qué es SNMP?

   SNMP es un protocolo que se utiliza para monitorear dispositivos por medio de la red, este protocolo permite que un servicio como Nagios, recopile información de distintos aparatos (routers, switches, firewalls, teléfonos, computadoras, radios, etc.) en tiempo real y la catalogue/muestre al personal encargado del mantenimiento de dichos aparatos, también es posible que el Nagios tome acciones preventivas basándose en parámetros previamente configurados, por ejemplo, enviar un mensaje de texto al Ingeniero encargado de la red avisandole que según los datos recopilados el router esta a punto de colapsar (por poner un ejemplo), o le muestre gráficos de estadísticas de funcionamiento. 

  Entre las cosas que podemos monitorear mediante SNMP se encuentran:

• Estado de interfaces
• Consumo de ancho de banda
• Frecuencias de operación de un radio
• Consumo de amperaje y estado de batería de un UPS
• Numero de llamadas concurrentes en un teléfono
• Aplicaciones en ejecución en un servidor
• Perdida de paquetes
• etc

  Como se aprecia SNMP es un protocolo bastante completo, lo primero que se debe realizar es revisar la documentación correspondiente al dispositivo que queremos monitorear y revisar que permita ser monitoreado mediante SNMP, si tiene una interfaz de red es muy probable que si lo permita. 

El community String y los OIDs

    

   SNMP ya va por 3 versiones, en este caso solo hablaremos de la version 2, esta versión incluye algo que se denomina Community String, es como una contraseña, se le configura al equipo que se desea monitorear y luego, si se desea obtener información de este, el dispositivo que la solicita (ejemplo un servidor corriendo Nagios), debe utilizar esa misma "contraseña" para obtener la data, de lo contrario se le niega. 

   Los OIDs, son Identificadores de Objetos, OID significa, Object Identifier, un objeto en SNMP puede ser un servicio, una interfaz, el estado de una batería, etc. Luego de activar SNMP en el equipo que queremos monitorear y colocarle un community string, tocara hacer un "snmp walk" que no es otra cosa mas que hacer un listado de todos los OIDs que ese dispositivo en particular posee. Leer una lista de OIDs de un dispositivo recién empezando puede ser extremadamente confuso, lo importante es ir con calma y utilizando la lógica, los nombres si bien son abstractos, suelen tener un sentido lógico como veremos mas adelante. 

Instalación de Nagios Core y sus Plugins

Nagios es a día de hoy un software extremadamente poderoso y útil para monitorear equipos y servicios, ya sean routers, switches, firewalls, teléfonos, etc. Inclusive se puede monitorear servicios en ejecución en un equipo. 

Nagios trabaja principalmente con el protocolo SNMP, si quieren saber un poco mas sobre Nagios sugiero leer la documentación en su pagina web: http://www.nagios.org/

Este post es únicamente para ayudar a instalar el software como tal en 8 sencillos pasos, en la distribución CentOS. 

Nagios viene en varios sabores, sin embargo el que nos interesa es el gratuito (Nagios-Core), ¿cual es la diferencia con los pagos? Pues sencillamente que el gratuito no tiene los denominados "Wizards de instalación" que hacen la vida tan fácil para cualquiera que no sepa de Linux o no este interesado en leer la documentación. Al final de este post encontraran un enlace para descargar un script que utilizo para instalar Nagios en sistemas nuevos, antes de ejecutarlo, lean lo que dice en el código fuente. 

Para esta instalación asumiremos que están en una consola, crearemos una carpeta donde almacenaremos todo lo necesario para instalar Nagios y procederemos desde ahí. Primero nos loggeamos como admin si es que ya no lo somos con el comando su

1.- Creación de la carpeta donde almacenaremos el SRC de Nagios

   Vamos a utilizar el directorio /usr/local/src/, dentro de este directorio creamos una carpeta que se llame nagios: mkdir /usr/local/src/nagios

    

     Ahora nos metemos en dicha carpeta con cd /usr/local/src/nagios/

2.- Descarga de dependencias

    Tendremos que descarga unos cuantos paquetes antes de poder proceder, ejecutamos el siguiente comando para descargar todas las dependencias:

yum install -y make httpd perl php gcc glibc glibc-common gd gd-devel net-snmp-utils wget gcc-c++

    Esto se tardara algo de tiempo dependiendo de la velocidad de la conexión que tengan. 

3.- Descarga de los SRC

   Vamos a necesitar dos cosas para instalar Nagios y tenerlo funcional en nuestro sistema, en primera instancia necesitamos el núcleo de Nagios (Nagios-Core), el cual actualmente esta en su versión 4.0.0, para descargarlo ejecutamos desde la consola:

    wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-4.0.0.tar.gz

   También podemos chequear desde la pagina web de nagios si existe otra versión mas reciente, en cuyo caso cambiamos el numero de la versión del comando anterior (donde esta 4.0.0) por los encontrados en esta pagina: http://www.nagios.org/download/core/thanks?t=1381522100

   Luego de tener eso, tenemos que descargar los plugins o de lo contrario no podremos hacer nada con Nagios, los plugins, actualmente la versión 1.5, podemos descargarlos utilizando:

    wget https://www.nagios-plugins.org/download/nagios-plugins-1.5.tar.gz 

   Al igual que el caso anterior podemos revisar si existe una version mas reciente de los plugins desde la pagina web: http://www.nagios.org/download/plugins en cuyo caso substituimos el "1.5" por la versión que aparezca ahí. 

4.- Descompresion de los SRC

   Los archivos SRC vienen comprimidos, por ende debemos primero descomprimirlos, para ello utilizamos los siguientes comandos:

    tar zxvf nagios-4.0.0.tar.gz

    tar zxvf nagios-plugins-1.5.tar.gz

   Recordando que si descargamos otra versión, debemos substituir 4.0.0 y 1.5 por las versiones utilizadas.

   Veremos un montón de información en la pantalla, cuando termine podremos observar en el directorio (ejecutando ls) dos carpetas adicionales:

nagios: directorio donde esta el código fuente del Nagios-Core

nagios-plugins-1.5: directorio donde esta el código fuente de los plugins

5.- Creación del usuario y grupo para la ejecución de Nagios

   Tenemos que crear el usuario nagios:

       useradd nagios

   y el grupo nagcmd

      groupadd nagcmd

   Ahora introducimos los usuarios apache y nagios al grupo nagcmd:

      usermod -aG nagcmd nagios

      usermod -aG nagcmd apache

6.- Compilando Nagios-Core y Nagios-Plugins

6.a Nagios-Core

   Nos metemos en el directorio de nagios: cd nagios

   Tenemos que ejecutar el configure, y luego make para instalar, los comandos en orden son:

      ./configure --with-command-group=nagcmd 

      make all 

      make install 

      make install-init 

      make install-config 

      make install-commandmode 

      make install-webconf

    Luego nos salimos de ese directorio (cd ..)

6.b Nagios-plugins

   Nos metemos en el directorio de nagios-plugins: cd nagios-plugins-1.5

   Y ahora ejecutamos el configure al igual que el caso anterior, después make:

       ./configure --with-nagios-user=nagios --with-nagios-group=nagios

       make 

       make install

7.- Creación de cuenta de administración WEB

   Necesitamos esta cuenta para poder acceder a la interfaz Web de nagios, para crearla ejecutamos:

    htpasswd -bc /usr/local/nagios/etc/htpasswd.users nombreUsuario Contraseña

   Donde nombreUsuario y Contraseña, son el nombre de la cuenta y la contraseña de esta respectivamente. Luego de esto para que los cambios tengan efecto reiniciamos el servicio httpd:

    service httpd restart

8.- Añadir permisos de SELinux

   Si nos saltamos este paso, podremos ingresar a la interfaz web de nagios, pero todas las pestañas nos arrojaran un "Error Interno". Ejecutamos:

    chcon -R -t httpd_sys_content_t /usr/local/nagios

   Si todo esto ha ido bien basta con iniciar nagios con service nagios start y luego acceder a la interfaz web por medio de un navegador, desde la maquina que corre nagios por medio de http://localhost/nagios o desde una maquina externa por medio de http://IPserverNagios/nagios Si existe algun error al intentar acceder desde otro equipo, desactiven el servicio iptables: service iptables stop, o mejor aun añadan una regla para permitir el trafico web hasta el servidor:

   iptables -I INPUT 5 -s 0/0 -p tcp --dport 80 -j ACCEPT

   Por defecto CentOS bloquea todo el trafico que no establezca primeramente el servidor con el cliente, así que es buena idea añadir la regla anterior. 

Script para la instalación automática

   Como les comente arriba este script lo utilizo yo para instalar el Nagios de forma automática, no me hago responsable por su uso, les sugiero leer lo que dice el código fuente. Para ejecutarlo, descarguenlo y luego ejecuten desde una consola: chmod +x script-nagios.sh ya estando ubicados en el directorio donde lo descargaron, luego de esto ejecuten:
./script-nagios.sh versionDelCore versionPlugins

   En este caso versionDelCore es 4.0.0 y versionPlugins es 1.5

Enlace de descarga: http://www.mediafire.com/download/sgsw57wvshdse6n/script-nagios.sh 

Al final de todo esto deberían ver lo siguiente al acceder desde un navegador:

En otro post les hablare sobre como podemos empezar a monitorear equipos y servicios. 

DSL o Digital Subscriber Line

Todos conocemos el teléfono, la gran mayoría de nosotros tiene uno en su casa y es que este gran invento revoluciono las telecomunicaciones hace ya mas de 100 años. El principio de funcionamiento del teléfono es tan antiguo y sencillo que no ha cambiado mucho en todo este tiempo.

 Ya hace unos cuantos años cuando la era de la información digital comenzó a formarse con los orígenes del internet se decidió darle uso al teléfono como puente de conexión entre las aun jóvenes redes del mundo y los hogares, ¿la razón? la PSTN o Public Switched Telephone Network estaba (y aun esta) altamente masificada. Quizá algunos recuerden los modems de discado los cuales alcanzaban velocidades de hasta 56 kbps y requerían que la linea telefónica estuviese ocupada durante la duración de la conexión (es decir o navegabas por internet o utilizabas el teléfono) . 

 Las conexiones Dial-Up o de discado tenían como desventajas:

1. Bajo ancho de banda: como mencione previamente hasta 56 kbps (o hasta 300 kbps si se comprime la data a enviar y/o recibir), quizá en su momento fuera mas que suficiente pero a medida que la era digital fue avanzando los requerimientos de ancho de banda fueron creciendo, ya no solo se tenia necesidad de transmisión de datos en texto plano, sino que también se quería transmitir voz y vídeo.
2. Tiempos de conexión: dado que en dial-up lo que en realidad se hace es llamar o recibir una llamada, se requiere de un tiempo relativamente alto (unos cuantos segundos) para establecer una conexión.
3. Imposibilidad de recibir o realizar llamadas: mientras se estuviese utilizando la conexión a internet era imposible utilizar el teléfono para recibir o realizar llamadas, de hecho existe un sonido que quizá hayan escuchado antes en el entorno de las telecomunicaciones pero no conozcan su origen y es el sonido de una conexión dial up. 

Sonido de una conexión dial up

  En el vídeo pueden observar la representación temporal de las ondas transmitidas por el par de cobre, en primera instancia los tonos DTMF y en segunda instancia la onda de conexión.

 La principal ventaja de dial-up es que no requiere de ningún otro equipamiento mas allá de una linea telefónica y un módem de discado, ademas, a nivel de infraestructura interna la PSTN basta, no hay que disponer de equipos adicionales, así que con solo tener el módem y la linea telefónica se tiene de conexión a internet. 

  Pueden preguntar lo siguiente: con ADSL tengo internet teniendo solo una linea telefónica y un módem, ¿cual es la diferencia? Para responder esto aclaremos primero algunas cosas.

Digital Subscriber Line

  DSL es un set de tecnologías que nacen por la necesidad de tener mayor velocidad de transmisión y recepción de datos, en los inicios de las conexiones discadas las velocidades obtenidas por estas eran mas que suficiente, pero la tecnología ha avanzado a pasos agigantados así que fue necesario obtener velocidades mayores utilizando la misma infraestructura de la PSTN, la razón de esto sigue siendo la misma, si utilizaban la PSTN llegaban potencialmente a mas clientes ademas seria mucho mas rápido de implementar.

  Tomemos como base el hecho siguiente, la voz humana tiene un rango de frecuencias de aproximadamente 300 Hz a 3,2 KHz, esto significa que si redondeamos esa cifra hacia arriba, de 4 KHz para arriba no existe información útil transmitida en el par de cobre, esta es la base de las tecnologías DSL utilizar frecuencias superiores a 4 KHz para transmitir información digital, con lo cual podemos tener servicio telefónico tradicional o POTS (Plain Old Telephony Service) e internet al mismo tiempo. 

 DSL es por naturaleza mucho mas rápido que dial-up por el aprovechamiento efectivo y eficiente del espectro de frecuencias que pueden circular por el par de cobre, esta distribucion depende de la tecnologia DSL utilizada, en este caso hablaremos de ADSL.

Assymetric Digital Subscriber Line

   Este es el tipo de conexión DSL que normalmente contratamos, la palabra "asimétrica" viene por el hecho de que las frecuencias se asignan dando prioridad al canal de bajada (downstream) porque se asume que una persona normalmente lo que desea y utilizara mas sera la velocidad de descarga. Por esta razón se ven velocidades tan dispares de subida y bajada cuando se contrata la conexión (ejemplo 1.5 mbps de bajada y 600 kbps de subida). 

Distribución del espectro de frecuencias en ADSL

  El problema con ADSL al igual que todas las demás tecnologías DSL es que requiere de equipos adicionales en la infraestructura interna de la PSTN para poder proveer el servicio, ademas que tiene limitaciones de velocidad basadas en la distancia con lo cual no puede ser ofrecida en todos los lugares.

Esquema de un sistema por DSL

  En la imagen anterior pueden apreciar el esquema de una conexión DSL aclaremos algunos conceptos:

Modem: la palabra Modem proviene de Modulator/Demodulator o modulador/demodulador, los modems DSL utilizan OFDM para repartir eficientemente el espectro de frecuencias y luego modulan los datos utilizando QAM (usualmente). Las limitaciones de velocidad provienen por el hecho de que en cualquier medio de transmisión a mayor la distancia y la frecuencia de transmisión mayor las perdidas por atenuación de la señal, para contrarrestar esto se utilizan sets de frecuencias de transmisión que varían acorde a la distancia que se tenga hasta el DSLAM con la consecuente perdida de ancho de banda (velocidad en bps) de transmisión (por ejemplo se utiliza desde 28 KHz a 400 KHz en lugar de utilizar todo el rango desde 25,875 KHz hasta 1104 KHz). 

Filtro DSL (xDSL filter): esto no es mas que un filtro pasa-alto, solo deja pasar las componentes frecuenciales que se utilizan para transmitir datos (Frecuencia de corte ubicada en 25,875 KHz), adicionalmente los filtros que instalan en sus casas tienen una salida que va al teléfono, el filtro de la salida que va al teléfono es un pasa-bajo con una frecuencia de corte ubicada en aproximadamente 4 KHz. Esto se hace para evitar interferencias. 

DSLAM: es el aparato responsable de recoger todas las conexiones DSL que existen dentro de su área y enviarlas por medio de un enlace troncal de alta velocidad a la red interna del ISP que tengan contratado. 

Actualmente se esta trabajando para que ADSL llegue a velocidades de hasta 56 Mbps de bajada, y considerando que usualmente lo mínimo que se oferta en estas conexiones es 1 Mbps de bajada ya pueden apreciar la enorme diferencia respecto a dial-up, por cierto, DSL no necesita realizar discados por conexión con lo cual esta se puede mantener activa 24/7 e inicializarse rapidamente. 

Existen otras tecnologías DSL que mejoran la velocidad una de estas siendo SHDSL, la diferencia con ADSL es que utiliza todo el ancho de banda del canal telefónico (incluido el de voz) para transmitir y recibir (con lo cual no pueden utilizar la linea para realizar llamadas), por ello alcanza velocidades (simétricas) mayores a ADSL, normalmente es utilizado en ambientes empresariales. 

Decibelio (dB)

Cuando revisan el datasheet de un amplificador normalmente verán que la información de amplificación se muestra es en dB (decibel), también cuando se muestran datos como nivel de señal en un dispositivo receptor verán una unidad parecida al dB con una letra al final que denota a que unidad de referencia hablamos. 

En ingeniería tratamos con cantidades muy grandes o muy pequeñas, con el fin de simplificar la expresión de estas cantidades se ha decidido utilizar como estándar el decibelio como unidad de expresión de estas, el decibelio nos permite fácilmente expresar cantidades muy grandes como por ejemplo 10.000.000 o muy pequeña como por ejemplo 0,0000005 en números mucho mas manejables, en los casos anteriores el equivalente en decibel seria 70 dB  y -63 dB respectivamente. 

Tipos de decibel 

1.- Primeramente tenemos las unidades relativas, en función a ganancia de potencia o ganancia de voltaje:

Ganancia en dB = 10*log10(Pout/Pin)

Ganancia de Voltaje en dB = 20*log10(Vout/Vin)

Nota: observen que es logaritmo base 10

2.- Luego tenemos las unidades absolutas estas son referenciadas a una cantidad especifica:

Potencia en referencia a 1 mW en dBm = 10*log10(Pout/1mW)

Potencia en referencia a 1 W en dBw = 10*log10(Pout/1W)

Nivel de señal referenciada a 1 V en dBv = 20*log10(Vout/1V)

Para utilizar esto es sencillo, por ejemplo queremos expresar en dBm que estamos transmitiendo 1 mW, utilizando la formula tenemos que 1mW/1mW = 1 (increíble pero cierto). Y el logaritmo de 1 (en cualquier base) es igual a 0, entonces decir que estamos transmitiendo 0 dBm es lo mismo que decir que estamos transmitiendo 1 mW. En el caso de las unidades relativas observen lo siguiente:

Coeficiente del logaritmo	Valores obtenidos en dB	¿Qué representa?
1	0	Ganancia unitaria
Menor a 1	Valores negativos	Perdidas
Mayor a 1	Valores positivos	Ganancias

Nota 2 : el coeficiente es el resultado de la división Pout/Pin o Vout/Vin

Mas ejemplos:

20 V = 26 dBv

30 uW = 17,78 dBm

100 mW = 20 dBm

10 W = 40 dBm = 10 dBw

Operaciones con decibelios 

Existe otra gran razón por la que se expresen las ganancias en dB y las cantidades absolutas en función a una referencia. Y es que cuando trabajamos con logaritmos se puede simplificar mucho las operaciones matemáticas al hacer el calculo de nivel de señal final obtenida utilizando como premisa lo siguiente:

log(A*B) = log(A) + log(B)

log(A/B) = log(A) - log(B)

Teniendo en cuenta adicional que NO se puede transformar una unidad absoluta a una unidad relativa es decir dBm no se puede transformar en dB. Pero si se pueden aplicar las operaciones anteriores entre ellos, adicionalmente no se pueden sumar ni restar valores de unidades absolutas es decir dBm + dBm o dBm - dBm no es algo valido, sin embargo dB + dB o dB - dB si es valido, piensen un poco y entenderán por que. 

Ejemplo

Tenemos un transmisor que envía 10 dBm de señal a un receptor, sabemos que las perdidas por la distancia del enlace es -7 dB adicionalmente poseemos un regenerador de señal que eleva esta 4 dB, nuestro receptor necesita mínimo 4 dBm de señal para poder funcionar correctamente. Determine si al receptor le llega el nivel de señal necesario. 

Solución:

    Nivel de señal recibido = Nivel de entrada + Perdidas + Ganancias 

    Nivel de señal recibido = 10 dBm + (-7 dB) + 4 dB

    Nivel de señal recibido = 7 dBm = aproximadamente 5 mW

Por lo tanto llegamos a la conclusión de que si tenemos el nivel de señal requerido, podemos verificar esto haciéndolo "a la antiguita":

   10 dBm = 10 mW

   -7 dB = 0,19953 (es adimensional y representa perdidas)

   4 dB = 2,511 (también es adimensional y es una ganancia)

  Nivel de señal recibido = Nivel de entrada*Perdidas(si están en decimal, si es fracción se divide)*Ganancias

     Nivel de señal recibido = 10 mW * 0,19953 * 2,511

     Nivel de señal recibido = aproximadamente 5 mW

    

Ganancia de Antenas 

En las antenas se expresa la ganancia en dBi y dBd

dBi: Ganancia de la antena utilizando como referencia una antena isotropica, esto es, una antena que irradia uniformemente en todas las direcciones.

dBd: Ganancia de una antena respecto a un dipolo de referencia, se relaciona con dBi de la siguiente forma, dBd = dBi - 2,15. 

Si quieren mas información sobre las ganancias de la antena y como afectan potencia radiada les sugiero investiguen sobre el ERP o Effective Radiated Power y el TPO, Transmitter Power Output.