Hola
Existe el deseo de compartir con la comunidad una idea que se implementa en la empresa proveedora para responder rápidamente a los daños en el cable de cobre. Se trata de par trenzado y Ethernet. Por supuesto, no pretendo ser soluciones elegantes, pero el servicio mostró buenos resultados.
Para aquellos que son demasiado flojos para leer. Cómo funciona: supervise la caída de sesiones en el radio, agrupe por interruptores, pruebe la línea, notificación del casco.
No puedo dar el código completo del proyecto por razones corporativas, pero eliminaré el que está debajo de los spoilers para los interesados. Sí, y la implementación para cada proveedor variará. Más bien, el objetivo es compartir una idea que pueda ayudar a alguien.
El equipo de la compañía es 99% D-link, por lo que las MIB de SNMP se enumeran para este proveedor. Algunos de ellos son RFC y deberían ser adecuados para otros fabricantes.
Un poco de historia sobre cómo salió todo.
Todo comenzó en la primavera de 2018. La carga en el grupo de soporte técnico (TP) aumentó. Además de procesar las llamadas de suscriptores, TP también coordinó a los instaladores al conectar nuevos suscriptores, así como al salir para la restauración y depuración de clientes existentes. Era necesario descargar un poco el TP y dar algunas herramientas a los instaladores. Se decidió componer un "bot" de mensajería que aceptara el inicio de sesión / contrato del suscriptor y el instalador podría realizar la depuración mínima directamente en los campos.
No quería insertar toda la funcionalidad en una aplicación, porque de hecho, dicha funcionalidad sería útil también en el navegador en el mismo CRM al procesar una llamada, por lo que se decidió poner los mecanismos de interacción con el equipo de red, facturación, radio en un servicio separado, convertirlo en una API y conectar el bot y CRM a través de la API y eso es todo lo que sea
Ahora un pequeño código y pasa a la esencia de la publicación.
Y entonces, qué puede necesitar un instalador en los campos:
- Prueba de cable por supuesto
- Ver errores de puerto
- Ver el estado del puerto
- Vea si hay direcciones MAC en el puerto. (De repente, el suscriptor conectó el cable al puerto LAN en lugar de a la WAN)
- Suscripción IPTV
- Ver registros de autorización
- Estado de saldo
Interactuaremos con los conmutadores a través de SNMP y, en algunos lugares, a través de telnet.
Usé Bottle como marco web.
Y entonces
Agregamos una hoja con claves API y decoradores para verificación, pero no daremos datos a todos en una fila).
codigo apikeys = ['RANDOM_KEY1', 'RANDOM_KEY2'] api_error = '{"error":"apikey invalid"}' host_down_error = '{"error":"host down"}' def apikey_checker(fn): def wrapper(*args, **kwargs): if not check_apikey(): return api_error return fn(*args, **kwargs) return wrapper def check_apikey(): return 'apikey' in request.query and request.query['apikey'] in apikeys
Bueno, en realidad un par de funciones para interactuar con el equipo.
codigo @route('/port_status/<ip>/<port>') @apikey_checker def get_port_status(ip=' ', port=' '): return snmp.port_status(ip, port) @route('/cable_test/<ip>/<port>') @apikey_checker def get_cable_test(ip, port): return snmp.cable_test(ip, port)
Dentro de snmp tenemos un diccionario con la interpretación de los estados SNMP devueltos del par en el puerto.
Diccionario de estado pair_status = { '0': 'ok', '1': 'open', '2': 'short', '3': 'open-short', '4': 'crosstalk', '5': 'unknown', '6': 'count', '7': 'no-cable', '8': 'other' }
Preparación del diccionario para el resultado de la medición del puerto. Lo copiaremos para no hacer uno nuevo cada vez.
Texto oculto pair_result = { 'pairs': { 1: { 'status': '-', 'length': '-' }, 2: { 'status': '-', 'length': '-' }, 3: { 'status': '-', 'length': '-' }, 4: { 'status': '-', 'length': '-' }, } }
Función
prueba de cable def cable_test(ip, port): if not check_ip(ip):
la función regresará
resultado { "pairs": { "1": { "status": "other", "length": "0" }, "2": { "status": "open", "length": "4" }, "3": { "status": "open", "length": "4" }, "4": { "status": "other", "length": "0" } } }
Más tarde, agregó otra función similar, exclusivamente para el script, recibe una lista de puertos como entrada, y no una, y no verifica el estado del puerto antes de la prueba, esto no es necesario con una caída masiva de enlaces.
Así comenzó a verse el bot
Ahora a la esencia del post.
Antes de la implementación de
depuración del servidor,
se utilizó una tecnología similar a la descrita en la publicación
habr.com/post/188730 . Bucle en el puerto con la escalera SNMP habilitada. Cuando el "avión" cayó en el puerto, un mensaje sobre esto cayó en el monitoreo.
En primer lugar, atornillé el script para que cuando el enlace de seguimiento se cayera, el servidor de depuración fue al conmutador, verificó si el puerto realmente estaba mintiendo, y no solo parpadeó, y los pares en él estaban abiertos o en corto, y luego envié un mensaje a los operadores.
Sin embargo, solo alrededor del 10% de los interruptores tenían tales trampas físicas, y esto resultó ser insuficiente.
Más tarde se le ocurrió un radio de monitor. Y esto permitió aumentar el porcentaje de cobertura de monitoreo hasta el 100%. Y aquí todo ya difiere de la infraestructura del proveedor.
Periódicamente observamos cuántas sesiones de clientes han caído de un interruptor en particular. Esto es fácil de hacer si circuit_id está habilitado en los conmutadores, que tiene la forma
D4: CA: 6D: 0A: 66: C9 ::
192.168.20.86 ::
20Aquí tenemos el MAC del suscriptor, el conmutador IP, el número de puerto del suscriptor. Es decir todo lo que necesitas para depurar.
Agrupamos las sesiones completadas por conmutador IP, si hay más de unas pocas sesiones de este tipo (tenemos un activador establecido en 2 sesiones por minuto), el script se pone en contacto con el servidor de depuración y prueba los puertos de las sesiones descartadas. Si los puertos aún se encuentran y los pares de cables están abiertos o en cortocircuito, y la longitud de al menos dos puertos es la misma (+ - 2 metros), que es exactamente lo que parece el corte del cable a los ojos del conmutador, entonces consideramos la situación sospechosa y enviamos un mensaje al operador.
Por supuesto, habrá falsos positivos cuando la luz de la casa parpadee, o simplemente coincida que los suscriptores apaguen el cable al mismo tiempo y la longitud sea la misma, pero este es el caso, como dicen, cuando es mejor exagerar. Además, puede establecer un límite en la longitud (responder solo a longitudes cortas), el número de caídas simultáneas, etc.
Aquí está el informe real de un evento sospechoso.
Y los resultados de procesar tales mensajes
Hubo un caso cuando el script envió un mensaje similar, y después de un par de segundos el interruptor se desconectó, porque óptica dañada, y si no fuera por la velocidad del software, la situación se habría confundido con un apagón típico en la casa.
En otra ocasión, la compañía de gestión comenzó a reparar el techo sin previo aviso, y VOKhR con ametralladoras voló hacia ellos, un estrés repentino para los cerrajeros.
Entonces, el guión comenzó a mostrar buenos resultados y durante 4 meses de trabajo, VOKhR, la policía y los propios empleados del proveedor completaron con éxito más de 10 casos de vandalismo. Por lo tanto, decidí compartir el concepto de tal monitoreo.
Ahora el script monitorea alrededor de 15,000 conmutadores sin "trampas" físicas y trampas SNMP.
¡Buena suerte a todos en el nuevo año!