En este tutorial algunas consideraciones generales y otras específicas para equipos C.P.E
Objetivos
Al finalizar se habrán cubierto los siguientes objetivos:
Presentar los principios de resolución de problemas aplicados a las redes, incluyendo casos modelo,
incidentes y problemas.
Describir el modelo de capas y la resolución de problemas siguiendo el esquema.
Explicar la resolución de problemas en la LAN y remarcar la importancia de la documentación.
En esta lección desarrollaremos los siguientes temas:
Principios de la resolución de problemas.
Casos, incidentes y problemas.
El modelo de capas y la resolución de problemas.
Documentación.
Resolución de problemas en la LAN.
Principios de la resolución de problemas
En la tarea habitual del Administrador de una red, la detección, análisis y resolución. De fallos
ocupa la mayor parte de su atención.
Las redes de datos son una herramienta esencial para el desarrollo de la operación de la gran
mayoría de las empresas actuales. En este sentido los usuarios tienen un requerimiento del 100% de
disponibilidad de los recursos de la red.
Esta disponibilidad del 100% es un umbral u objetivo, pero la realidad de las redes informáticas
determina que toda estructura está destinada a sufrir más tarde o más temprano diferentes tipos de
fallos. En este sentido es esencial la tarea del Administrador de la red realizando mantenimiento
preventivo y monitoreando el desempeño de la red a poder determinar de manera proactiva posibles
requerimientos de cambio o expansión de la red existente.
Sin embargo, más allá de las tareas ordinarias de administración, monitoreo y mantenimiento,
permanentemente se debe responder a la solicitud de usuarios que están detectando o sufriendo
diferentes fallos en la red. Al momento de detectar un fallo es preciso entonces tener presentes
algunos principios básicos de esta tarea:
• Es necesario tener una descripción clara de la situación: cuál es el fallo, a qué sector o
sectores de la red afecta, en qué momento se manifestó. Documentar el reclamo es fundamental para
luego poder orientar la tarea de análisis.
• La elaboración de la respuesta debe ser fruto de una aproximación sistemática y ordenada al
problema planteado. Las respuestas no sistemáticas, en general,
contribuye a prolongar el problema, dilatar su solución, y en muchos casos a
complicar.
• Es necesario mantener documentación actualizada de modo permanente. No sólo se debe documentar
la red en su diseño. También se debe documentar la red en su desenvolvimiento y operación. El
monitoreo permanente es una herramienta esencial al momento de tener que analizar las causas de un
posible problema.
La documentación de los reclamos de los usuarios es parte integral de la documentación de la red y
el punto de partida de la atención de estas
situaciones.
Casos, incidentes y problemas
En la problemática de resolución de problemas, debemos distinguir distintos tipos de sucesos.
No todos los problemas que debe atender el Administrador tienen la misma problemática, consecuencias y gravedad. Es por esto preciso diferenciar algunas categorías básicas:
•Caso.Se da la denominación de caso a un incidente de la red que implica de modoinmediato al Administrador en sus tareas habituales y que escapa a sucapacidad de resolución. Por lo general los casos se documentan y se reportana una instancia técnica superior (interna o externa a la organización) para suanálisis y resolución.Denominamos caso, por ejemplo, al hecho de que en una red concreta undeterminado protocolo de enrutamiento no se comporta del modo esperado.Verificada la configuración y debidamente documentada, el caso se elevaentonces, por ejemplo a Cisco, para su análisis y respuesta.
•Incidente.Un incidente es un problema puntual reportado por un usuario en particular.Los incidentes son ocasionales y generalmente reportados por los usuarios a laAdministración de la red.Téngase en cuenta que si bien el incidente se define a partir de un usuario enparticular, si el mismo es causado por alguna falla de al red, el mismo puedeser reportado por múltiples usuarios de modo concurrente. El análisis de estaconcurrencia es parte del proceso de análisis.Son ejemplos de incidentes, por ejemplo, la dificultad de un usuario particular
para levantar una VPN, o el reporte de un intento de violación de las políticas de seguridad de la red.
•Problema.Con el término problema se identifica a un suceso en la infraestructura de lared que afecta al desempeño de la misma. El problema puede corresponderseono con incidentes reportados de los usuarios, y en algunos casos puede sersuperado sin que el usuario lo perciba.Ejemplos de problemas de la red puede ser la inestabilidad de un enlace WANola salida de servicio de un dispositivo colocado de manera redundante.
El modelo de capas y la resolución de problemas
Es un principio básico tener una aproximación sistemática al evento a resolver.
El modelo OSI nos brinda una plataforma teórica eficiente para realizar esta aproximación.
Las metodologías de resolución de fallos realizan una aproximación al análisis del problema a
partir de diferentes perspectivas sistemáticas. Una muy efectiva y habitual es adoptar la
perspectiva de capas del modelo OSI.
Tomando como base el modelo OSI hay dos métodos principales:
• Top – Down.
Analiza el problema a partir de la capa 7 del modelo OSI y verifica sistemáticamente el adecuado
funcionamiento en cada una de las capas de modo descendente.
Es un método habitualmente utilizado en el análisis de problemas de redes en el área de sistemas.
• Down – Top.
Comienza el análisis a partir de la capa física del modelo OSI y desde allí asciende en el estudio.
Es el método más utilizado en la resolución de problemas en la infraestructura de la red.
Se comienza por verificar el perfecto funcionamiento y conectividad de la capa física, con el
objeto de corroborar que exista una correcta conexión física entre los extremos a comunicar.
Verificada la conectividad se pasa al análisis de la capa de enlace de datos, analizando particularmente
la operación y estado de los protocolos de capa de enlace de datos (Ethernet, 802.1Q, PPP, HDLC,Frame Relay, etc.)
Asegurada la capa de enlace de datos es preciso verificar la capa de red para descartar problemas
de direccionamiento, negociación de protocolos etc.
Ejemplo: “Se cayó la red”
Ante el reporte de falta de conectividad con un sitio remoto, es preciso adoptar un proceso
sistemático de diagnóstico:
1. Documente adecuadamente el reclamo del usuario que da inicio al procedimiento.
2. Ejecutar un ping desde una terminal ubicada en la LAN a una terminal ubicada en la red remota. Si la respuesta es exitosa, el incidente no ha existido o se ha superado. Si la respuesta es negativa es importante verificar la misma, distintos problemas causan diferentes respuestas (destino inalcanzable, time out, etc.).
3. Ante una respuesta remota comience un relevamiento progresivo de los enlaces utilizando el mismo comando ping. Primero verifique el acceso al default Gateway. Si tiene acceso al default gateway verifique acceso al extremo local del enlace WAN. Si no tiene acceso al extremo local del enlace, deberá trasladar su consola al dispositivo al que está conectado ese enlace para continuar.
4. Instalado ya en el dispositivo en el que se detecta el problema, comience la verificación de modo sistemático utilizando una aproximación por capas: verifique la conectividad física.
5. Si el enlace físico se encuentra activo, verifique la capa de enlace de datos.
6. Si capa física y capa de enlace de datos están operando bien, lo probable es que se trate de un problema de capa de red. A partir de acá deberá revisar los diferentes aspectos relacionados al tipo de enlace e implementación a fin de verificar el verdadero origen del problema.
7. Documente el diagnóstico realizado y la solución adoptada.
Documentación
Un punto fundamental en una buena Administración es la documentación de la red.
Una buena administración de la red requiere una documentación completa y actualizada de la misma.
Sin una buena documentación no hay buena administración.
Entre la documentación necesaria a tener en cuenta para un adecuado seguimiento de la red y soporte
a las tareas de resolución de fallos, se debe considerar:
- Inventario de hardware.
Es importantísimo contar con un inventario completo del hardware de la red que incluya todos los
dispositivos aún los más elementales. En el inventario se debiera incluir: tipo de dispositivo,
marca y modelo, número de serie, sistema operativo, versión del SO, direcciones MAC (cuando
corresponda), ubicación, etc. - Mapa del cableado de la red.
Es fundamental contar con un plano de las instalaciones en el que esté detallado con precisión el
tendido de cables. Este mapa de cableado debe incluir el detalle que corresponda a la
identificación de cada tramo de cable y cada boca de conexión instalada.
Un supuesto básico es que la identificación documentada en el mapa de cableado debe coincidir con
el etiquetado de los cables. - Mapa de los racks de dispositivos.
En el mapa de cableado se debe detallar la ubicación de cada rack para la instalación de los
dispositivos. Un complemento de ese mapa es el croquis de cada rack detallando la ubicación precisa
de cada dispositivo. Esta documentación es fundamental al momento de tener que ubicar un dispositivo en especial. - Mapa de direccionamiento IP.
Se trata de un esquema lógico en el que se documenta cada una de las redes o subredes lógicas y el
modo en que están conectadas entre sí. - Inventario de direccionamiento IP.
Un documento importante es una base de datos que permita documentar fácilmente la información de
direccionamiento correspondiente a cada puerto de la red. En este inventario o base de datos
debiera constar: nombre del dispositivo, ubicación, interfaz, dirección MAC, dirección IP, forma de
asignación de esa dirección. - Inventario de configuraciones.
El inventario de configuraciones es una base de datos que referencia la ubicación del archivo de
respaldo de la configuración de cada dispositivo de la red. Este respaldo de configuraciones debe
incluir todos los dispositivos de la infraestructura de la red, y los servidores.
En el caso de dispositivos Cisco, es conveniente contar con una copia de respaldo de la
configuración y una copia en formato texto. - Servidor de respaldo.
Un servidor FTP o TFTP para el almacenamiento de las copias de respaldo de los archivos de
configuración y las imágenes de sistemas operativos. Es fundamental que este servidor se mantenga
ordenado y actualizado. - Log de eventos.
Los servidores de Syslog permiten almacenar las notificaciones de eventos de servidores y
dispositivos. Estos archivos son fundamentales al momento de tener que analizar incidentes
concurrentes en la red, incidentes de seguridad, etc. - Registro de novedades.
Un registro o base de datos ordenada de los reportes de incidentes recibidos por la administración
de la red es el principio del proceso de diagnóstico de un incidente y una herramienta fundamental
al momento de analizar la evolución de la red.
Independientemente de los elementos enumerados hasta aquí, hay muchos otros que pueden ser de
utilidad o necesarios dependiendo de las características o dimensiones de la red. Entre estos, por
ejemplo es importante contar con una línea de base de la operación de la red para poder hacer un
diagnóstico más ajustado y poder evaluar proactivamente los requerimientos de actualización
periódica.
Es fundamental que la información no quede confiada exclusivamente a la memoria del Administrador.
Información perdida o errónea significa horas de trabajo al momento de tener que solucionar un
problema o rediseñar la red. La documentación precisa y actualizada facilita la tarea y favorece el
trabajo en equipo.
Resolución de problemas en la LAN
Una red LAN Ethernet tiene elementos propios a tener en cuenta al momento de afrontar la resolución
de un incidente.
Al momento de afrontar la resolución de incidentes en la red LAN, es importante tener presente
algunos elementos básicos:
- Verifique que se trata de un problema en la red local, no en la red remota.
- Verifique si afecta a la conectividad general (¿se puede hacer ping?) o a una aplicación o
conjunto de aplicaciones.
Si afecta la conectividad general, debemos buscar primariamente un problema en las 3 primeras capas
del modelo OSI.
Si afecta solo a una aplicación o conjunto de aplicaciones, comience por revisar las políticas de
filtrado de tráfico, definición de usuarios en servidores Proxy, etc. - Verifique si el inconveniente afecta a toda la red o solamente a una o un grupo de VLANs.
Si afecta a toda la red, conviene comenzar la revisión a partir del núcleo.
Si afecta a un grupo de VLANs, verifique si se trata de subredes que se agregan en un punto, si es
así, es probable que el problema esté en la capa de distribución.
Si afecta a una VLAN, lo más probable es que el problema se encuentre en la capa de acceso. - Determinado el punto de la red en el que se encuentra el problema, comience la verificación de
conectividad a partir de la capa física, hacia arriba:
-Verifique que los dispositivos de infraestructura se encuentren encendidos, no hayan sido
reiniciados accidentalmente y estén operando de modo adecuado.
– Verifique el cableado: ajuste de los cables, LEDs indicadores del estado de puertos, si es
posible, verificar el estado de la interfaz a través de algún recurso de monitoreo (software de
monitoreo, CLI, etc.).
– Cuando hay VLANs verifique que las terminales con problemas se encuentran conectadas a los
puertos correctos.
– Verifique la operación de los protocolos de capa de enlace. En una red LAN Ethernet puede traer
inconvenientes una incorrecta configuración respecto de velocidad y estado de dúplex de los
puertos.
En enlaces troncales puede haber falta de conectividad por falta de coincidencia en la
encapsulación configurada.
– Si capa de enlace de datos se encuentra operativa lo más probable es que se trate de un problema
de capa de red. Verifique la asignación de direcciones IP, máscaras de subred y default gateway.
Sea ordenado en el proceso de diagnóstico y no introduzca cambios en la red hasta que tenga un
diagnóstico claro. No sólo es importante solucionar el inconveniente sino también saber qué es lo
que lo provocó.
No comience suponiendo que el problema es provocado por el elemento más sofisticado, p.e. un filtro
de tráfico mal configurado. Sea ordenado en el diagnóstico y verifique paso por paso, muchas veces
las fallas se deben a problemas tan simples como un cable de alimentación eléctrica que está
haciendo falso contacto o un equipo reiniciado por error.
Resolución de problemas (sobre C.P.E de UBNT)
Reiteración de otro post antes publicado, pero que puede sumar a lo anterior a modo de ejemplo
a) No puedo acceder a la configuración de mi equipo inalámbrico.
Es necesario revisar que la IP de la PC haya sido cambiada correctamente en la conexión de área lo
comprobar que los cables de red están bien y que el equipo esté energizado. Si todo lo anterior es
correcto sugiere regresar su equipo a valores de fábrica presionando el botón “reset” físico del
radio o el botón “res del PoE (si aplica).
b) Ya ingresé a la configuración de mi equipo, ¿qué configuro?
Son relativamente pocos los parámetros necesarios a configurar, los cuales se explican en este post
sugiere seguir los pasos mencionados para configurar ambos equipos.
c) Ya realicé las configuraciones requeridas pero no tengo enlace, ¿A qué se debe?
Puede haber varios motivos por los cuales no hay enlace inalámbrico:
-
Los radios pueden no ser de la misma frecuencia (2,4 GHz y 5,7 GHz, por ejemplo).
-
No tienen el mismo SSID (debe ser exactamente igual en ambos).
-
No tienen la misma clave de seguridad inalámbrica (WEP, WPA, WPA2, etc.).
-
No tiene línea de vista.
-
Las alturas de su enlace son insuficientes.
-
Falta de alineación de las antenas.
-
Los cambios o configuraciones no se aplicaron correctamente.
-
Los radios utilizados no son los ideales para la distancia deseada.
En este tipo de casos, se puede destinar más tiempo en revisar paso por paso cada uno de los elementos
mencionados, por lo que se recomienda reprogramar los equipos en laboratorio desde valores de fábrica.
d) Puedo hacer ping a la IP de uno de mis radios pero no me permite ingresar a la configuración
del mismo.
Este tipo de problemas normalmente se asocian a conflictos de IP entre 2 o más dispositivos de la
red, por lo que es necesario realizar la siguiente prueba:
1. Envíe un “ping” ilimitado a la IP del dispositivo deseado. (Ej: ping 192.168.1.20 -t
2. Apague completamente el equipo por uno o dos minutos y evalúe si el ping sigue respondiendo.
3. Si el “ping” sigue respondiendo, entonces hay otro dispositivo con la misma IP del radio, lo
cual está ocasionando el conflicto. Tenga en cuenta que ese dispositivo puede ser su propia PC o
alguna otra PC de la red.
4. En caso contrario, un reinicio a su equipo debe permitirle nuevamente el acceso después de 40
segundos.
Sólo en casos muy especiales aplicaría lo siguiente:
1. Si activó en la pestaña “SERVICES” la función “HTTPS”, para poder ingresar nuevamente al equipo
debe utilizar la siguiente sintaxis: https://192.168.1.20:443 donde 443 es el número de puerto
predeterminado para acceso seguro cifrado, a menos que se haya configurado otro puerto.
2. Si cambió el número de puerto y no recuerda cuál puerto es, deberá regresar su equipo a valores
de fábrica y reconfigurarlo normalmente.
e) Ya está operando mi enlace pero tengo muy poco rendimiento de datos (Mbps), ¿a qué se debe?
Un bajo rendimiento de datos puede deberse a lo siguiente:
1. Se está utilizando un canal muy saturado de señal (noise floor de -88 o -90 dBm).
2. No tiene libre la 1ª zona de fresnel.
3. Falta una alineación más fina en las antenas utilizando la herramienta de alineación del equipo.
Si tiene niveles altos de ruido, se recomienda probar otro canal de transmisión o disminuir el
ancho de canal utilizado por uno más pequeño (de 40 MHz a 20 MHz o 10 MHz).
f) Mi enlace está operando pero me muestra velocidad asíncronas de TX / RX, ¿Qué puedo
verificar?
Esto se puede deber a lo siguiente:
1. No están configurados los parámetros de país y ganancia de la antena (si aplica) correctamente
en ambos equipos, por lo que un radio tiene menor señal al otro, por eso es asíncrona la velocidad
en Mbps.
2. El canal utilizado tiene un piso de ruido (noise floor) muy alto, por lo que los radios están
oscilando mucho entre diferentes velocidades de datos y/o modulaciones, por lo que no hay
estabilidad de datos en TX ni en RX.
3. Si el equipo es de antena externa, puede que la diferencia de señal entre la polarización
vertical y la horizontal sea más de 3 dB, por lo que hay algún problema de conexión entre el radio
y la antena o hay filtración de agua o humedad en el cable coaxial.
g) Adquirí un equipo M2 para brindar acceso de Internet a usuarios pero no me permite conectarme.
Es muy importante que al configurar su equipo M2 como punto de acceso (access point), se desactive
la función “airMAX” en la pestaña “UBNT” y se configure un ancho de canal de 20 MHz en la pestaña
“WIRELESS”, ya que los equipos inalámbricos convencionales (Tablet, Laptop, SmartPhone, etc.)
normalmente operan con anchos de canal de 20 MHz y no son compatibles con la tecnología TDMA de
Ubiquiti.
h) ¿Puedo enlazar un equipo M2 a un equipo M5 o M900?
No, debido a que son de diferentes bandas de operación, por lo tanto, no son compatibles entre sí.
En cambio, puede utilizar modelos diferentes de radios, ya sean M2, M5 o M900 para enlazarse entre
ellos sin ningún problema (Ejemplo: un LOCOM2 con un NSM2, un NBG522 con un NSM5).
i) ¿Qué distancia me da cada equipo Ubiquiti en aplicaciones Punto a Punto?
j) ¿Qué tipo de clave de seguridad inalámbrica es conveniente utilizar en los equipos Ubiquiti?
Todos los equipos Ubiquiti pueden ser utilizados con claves WEP, ya sea en formato ASCII (a-z, A-Z, 0-9 y algunos caracteres especiales) o Hexadecimal (a-f, A-F, 0-9). También es posible utilizar WPA y WPA2, ya sea TKIP o AES, con un mínimo de 8 caracteres. Soportan conexión a servidores RADIUS sin problema.
Fabricante recomienda utilizar claves WPA2-AES para obtener la mejor seguridad posible con el mejor
ancho de banda posible.
k) ¿Cómo puedo brindarle más seguridad a mi enlace inalámbrico?
Hay formas muy variadas para llevar a cabo lo mencionado, a continuación se indican algunas de
ellas:
- Filtrar los dispositivos inalámbricos que se conectan por MAC Address.
- Configurar un SSID mezclando letras minúsculas, mayúsculas, números y algunos
símbolos especiales. - Ocultar el SSID de nuestra red inalámbrica.
- Utilizar claves de seguridad inalámbrica WPA2-AES y de una longitud mínima de 10 caracteres,
mezclando letras minúsculas, mayúsculas y números. - Asignar a los clientes la MAC del AP para que sólo se asocien a éste.
- Si tiene servidor DHCP, limítelo a la cantidad de clientes legítimos del sistema.
- Cambiar el usuario y la contraseña de fábrica de sus radios por una propia para evitar intrusiones al equipo.
Si se aplican todos los puntos anteriores, su red inalámbrica sería muy segura.
l) ¿Cómo puedo regresar mi equipo Ubiquiti a valores de fábrica?
Es necesario presionar el botón de reset del equipo o del PoE por 12 segundos; no más de 12, ya que
de lo contrario, entra en un modo de recuperación el cual es otro procedimiento el que se utiliza
para restablecer. Después de los 12 segundos, el equipo demorará alrededor de 30 a 40 segundos en
restablecerse y reiniciar. tambien desde la interfaz web o desde Shell por putty.
m) Configuré mis equipos para que obtuvieran IP automáticamente por DHCP y ahora no puedo ingresar
a ellos,
¿cómo puedo saber en qué IP quedaron configurados?
Existe un utilitario llamado “Ubiquiti Discovery”, el cual permite identificar a todos los equipos Ubiquiti dentro de la red local, independientemente de la clase de IP. El utilitario mostrará la MAC Address del dispositivo, el alias del mismo, la IP que tiene configurado, la versión de firmware que tiene cada uno, el modelo del equipo, etc.
De esta forma, siempre tendrá la información más importante de sus equipos en la red local.
Puede descargar el utilitario de la siguiente dirección:
https://www.ubnt.com/downloads/discovery/ubnt-discovery-v2.4.1.zip
