Networking

Comunicaciones DCOM

Comunicaciones DCOM

fernando

El protocolo DCOM (Modelo de Objetos Componentes Distribuidos) permite comunicación directa entre programas, anteriormente conocido como «Red OLE», un precedente a lo que hoy conoceríamos como servicios web. Con software legacy todavía encontramos este tipo de comunicación, especialmente en entornos industriales, puede ser algo complicado buscar el origen de la perdida de conexión.

Podemos utilizar DCOMTest de Microsoft en entornos Windows 2000/XP/7/10/2003 para comprobar si tenemos configurado el acceso correctamente. Este pequeño programa de prueba, registrará una clase DCOM ejecutando el archivo de registro en ambos equipos.

Leer más →

Cortes de conexión de puntos wifi con SonicWall

fernando

El protocolo CAPWAP (Control And Provisioning of Wireless Access Points – RFC5415) permite el intercambio de datos de configuración, autenticación y operaciones entre puntos de acceso wifi y el controlador. Debemos asegurar la comunicación UDP en los puertos 5246 y 5247 entre todos los elementos.

Con la utilización de controladores en la nube para la gestión centralizada podemos sufrir desconexiones entre diferentes elementos de la red, además de asegurarnos la calidad de la conexión y la priorización del tráfico de control (QoS) dentro de una red específica (VLAN) en algunos firewall es posible que, de forma predeterminada, el propio equipo cambie el puerto de origen en cada petición / NAT realizada con lo que se producen cortes intermitentes.

Si bien esta función por defecto, favorece una mayor seguridad al no ser tan predecible la asignación dinámica de puertos, puede causar problemas con conexiones tipo CAPWAP, VoIP, P2P..

En firmware SonicOS Enhanced 6.5.4.6-79n y anteriores la configuración se encuentra, algo mal situada, en el menú de VoIP.

Controlar ancho de banda en firewall mediante SNMP

fernando

En el momento de monitorizar equipos de red Zyxel mediante SNMP, al intentar recuperar el tráfico de una interface para Nagios / Icinga / Centreon las consultas por nombre hacen referencia a las internas, no a los nombres personalizados ni a los puertos P1, P2, P3… por lo que empezarán en eth0, eth1… ethX. Para las interfaces virtuales podemos utilizar vlan1, vlan2… vlanX

Añadimos el autoescalado en los gráficos, para la IP del equipo 10.10.0.250, la comunidad «public» por defecto y versión 2c, el comando que se ejecutará periódicamente quedaría:

/usr/lib/centreon/plugins/centreon_zyxel_snmp.pl
	--plugin=network::zyxel::snmp::plugin
	--mode=interfaces
	--hostname=10.10.0.250
	--snmp-version='2c'
	--snmp-community='public' 
	--interface='^eth2$'
	--name
	--add-status
	--add-traffic
	--warning-in-traffic='80'
	--critical-in-traffic='90'
	--warning-out-traffic='80'
	--critical-out-traffic='90'
	--change-perfdata=traffic,,scale(auto)

 

Nota:

En ocasiones aunque aparezca instalado el plugin es necesario ejecutar en modo consola:

yum install centreon-plugin-Network-Zyxel-Snmp

 

SNMP con Nagios / ICINGA

fernando

Lo primero a tener en cuenta es conocer la versión del procolo que utilizaremos para obtener la información v1, v2c, v3, siempre que sea posible la última y limitando que dispositivos tienen acceso a la información SNMP

El plugin check_nwc_health viene bien para una serie de dispositivos habituales:

git clone https://github.com/lausser/check_nwc_health
cd check_nwc_health
git submodule update --init
autoreconf
./configure
make
Leer más →