Entrar al aula
×

Verificación y prueba de conectividad de una red local

Ya hemos visto las herramientas de software más importantes, los comandos TCP/IP. Ahora debemos determinar el modo, la técnica o el método de aplicación, que estará determinado por las circunstancias de nuestra actuación.

Los profesionales de redes locales se encuentran habitualmente bajo dos circunstancias, la necesidad de verificar una instalación realizada o la de atender un aviso de avería, una anomalía detectada o cualquier tipo de incidencia en una red que ya ha sido instalada y, supuestamente, verificada.

Esto determina los procedimientos sistemáticos que deben emplearse en uno u otro caso. Por un lado, la verificación de una instalación comprende su certificación dentro de la normativa internacional, mediante un dispositivo certificador que comprueba que los parámetros de la red se ajustan a los valores asignados de velocidad y calidad de transmisión del tipo de cable instalado.

Por otro lado debe establecerse una configuración específica de los nodos, mediante dominios o grupos de trabajo, configuraciones IP, recursos compartidos, determinación de cuentas de usuario y privilegios asociados, generalmente bajo un sistema de archivo distribuido.

Sin embargo, las anomalías e incidencias de una red requieren de más fases en sus procesos sistemáticos, ya que se deben recopilar síntomas cuyo estudio nos permita determinar pruebas y verificaciones que ubiquen la anomalía, para, posteriormente, determinar la solución e implantarla, verificando si se ha solucionado, o debe plantearse otra solución.

Procedimientos generales (I/II)

Los procedimientos sistemáticos, los métodos corporativos y las distintas técnicas a aplicar, se documentan a través de diagramas de flujo.

Los diagramas de flujo son la representación gráfica de un proceso mediante una simbología que permite seguir una serie de pasos o fases con bifurcaciones según los valores que toman los distintos parámetros que intervienen en el proceso. Está normalizado en el UML (Unified Modeling Language) Lenguaje Unificado de Modelado, respaldado por la OMG (Object Management Group). Además de usarse en informática y programación, se emplea en otras áreas, como economía, industria, seguridad o psicología.

UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

En la siguiente imagen se muestra un diagrama de flujo sencillo donde se muestra la estructura básica de un proceso de resolución de anomalías genérico, tan genérico que sirve para cualquier suceso de la vida cotidiana.

 

Diagrama de flujo básico

 

Procedimientos generales (II/II)

Los procedimientos generales de resolución de incidencias en redes de área local se clasifican en tres fases, recopilación, ubicación y corrección.

Fases de resolución de incidencias

Recopilación de síntomas

Consiste en la comprobación y documentación de síntomas de red, sistemas operativos y usuarios por parte del administrador de red y la delimitación de las anomalías concretando las áreas afectadas.

Esta documentación se elabora a través de las alertas de los sistemas de red, mensajes de consola, comprobaciones rutinarias automáticas o quejas de los propios usuarios. Debe realizarse bajo los criterios de lógica e intentando reducir el margen de posibilidades.

El científico loco y la araña.

A la hora de determinar la causa de una serie de síntomas, la lógica debe ser el elemento de decisión, pero determinar esa lógica puede resultar más difícil en unos casos que en otros. Para ilustrar la toma de decisiones, con frecuencia se recurre a la parábola o chiste del científico loco con su araña.

El científico tiene amaestrada a la araña, que acude a su llamada. Le extirpa una pata y la llama de nuevo. La araña acude, cojeando. Le arranca otra pata y repite el proceso. La araña, cada vez con más dificultad, acude a la llamada del científico. Finalmente, tras repetir el proceso, le arranca la última de sus patas, la coloca al otro extremo de la mesa, y la llama. La araña no acude.

Conclusión: Las arañas se vuelven sordas si se les extirpan las patas.

Del mismo modo, incorrecto, se podría concluir que las arañas sin patas, pierden obediencia. El error de estas conclusiones resulta evidente desde otro planteamiento, el llamado la navaja de Ockham, principio por el cual, la explicación más sencilla es siempre la más probable.

Ubicación de la anomalía

Debe analizarse el problema bajo la perspectiva de las capas de protocolos, para determinar qué dispositivos pueden ser la causa. En este proceso deben enumerarse las distintas posibilidades de anomalía y pueden realizarse pruebas para descartar posibilidades.

Hasta que no se realiza una identificación del dispositivo, o software que provoca la anomalía, no puede determinarse la causa del problema, pero puede aislarse para reducir el efecto en el resto de dispositivos.

El planteamiento inicial debe contemplar todas las posibilidades imaginables, para, posteriormente, descartar las posibilidades en función de los síntomas descritos y las pruebas realizadas.

Las ubicaciones más habituales de anomalías son:

  1. Fallo de hardware de un dispositivo de conectividad de red.
  2. Error o fallo de conexión en el panel del armario de comunicaciones (rack)
  3. Error o fallo en suministro eléctrico o de toma de tierra.
  4. Error de Cable:
    • Continuidad de cableado, latiguillos. (rotura, deformación, aplastamiento)
    • Categoría inapropiada o trazado incorrecto según cableado estructurado horizontal
    • Conectores RJ45 mal crimpados, rotos (sin pestaña) o con hilos sueltos.
  5. Error de software, (capas 5, 6 y 7 del modelo OSI)
    • Capa 5, sesión: claves de acceso, cuentas y privilegios
    • Capa 6, presentación: Códigos de caracteres, compresores, códec, etc...
    • Capa 7, aplicación: Configuración aplicaciones, protocolos usuario.
  6. Error de configuración de red (tipo IP, máscara, gateway, DNS, etc…)
  7. Uso incorrecto del usuario.(la, llamada, capa 8)
  8. Anomalía externa del ISPInternet Service Provider.(También llamada, por algunos, capa 0)

La mayoría de las anomalías que ocurren en una red de área local, pertenecen a alguno de los grupos descritos. Como decía en el anterior apartado, para evitar la ilógica del científico loco, y cruel con su pobre araña, debemos  recurrir a un principio metodológico, o filosófico, atribuido al monje franciscano Guillermo de Ockham (1280-1349)

La navaja de Ockham

La navaja de Ockham es un principio según el cual, en igualdad de condiciones, la explicación más sencilla suele ser la más probable.

Esto implica que, cuando dos teorías, en igualdad de condiciones, tienen las mismas consecuencias, la teoría más simple tiene más probabilidades de ser correcta que la compleja.

En ciencia, este principio se utiliza como una regla general para guiar a los científicos en el desarrollo de modelos teóricos, más que como un árbitro entre los modelos publicados. En el método científico, la navaja de Ockham no se considera un principio irrefutable, y ciertamente no es un resultado científico. «La explicación más simple y suficiente, es la más probable, mas no necesariamente la verdadera», según el principio de Ockham. En ciertas ocasiones, la opción compleja puede ser la correcta.

Su sentido es que, en condiciones idénticas, sean preferidas las teorías más simples, ya que la experiencia demuestra que, ese criterio, tiene mayor probabilidad de ser cierto. Otra cuestión diferente serán las evidencias que apoyen la teoría. Así pues, de acuerdo con este principio, una teoría más simple, pero de menor evidencia, no debería ser preferida a una teoría más compleja pero con mayores pruebas.

¿Cómo medir la simplicidad?, es una cuestión ambigua. Quizás la propuesta más conocida sea la que sugirió el mismo Ockham. Cuando dos teorías tienen las mismas consecuencias, debe preferirse la teoría que postule la menor cantidad de entidades, la que tenga menos elementos. Otra manera de medir la simplicidad, sin embargo, podría ser por el número de axiomas de la teoría. Cuantos más axiomas o postulados, más complejo y, por lo tanto, más improbable.

La navaja de Ockham se aplica a casos prácticos y específicos, englobándose dentro de los principios fundamentales de la filosofía de la escuela nominalista que opera sobre conceptos individualizados y casos empíricos.

La denominación de navaja de Ockham apareció en el siglo XVI, y con ella se expresaba que mediante ese principio, Ockham «afeitaba, como una navaja, las barbas de Platón», ya que de su aplicación se obtenía una notable simplicidad ontológica, por contraposición a la filosofía platónica que «llenaba» su ontología de entidades físicas, matemáticas e ideas puras.

Ockham, decía, exactamente, «Entia non sunt multiplicanda praeter necessitatem», Los entes no deben multiplicarse sin necesidad.

Con la navaja de Ockam se cortó la serie de estupideces que el ex-hoplita del ejército griego difundiera dos mil años atrás.

Como responsables informáticos, nosotros debemos ser como Ockham, no como Platón.

Corrección del problema

Una vez que se ha ubicado la causa de la anomalía, e identificando el problema, el administrador determinará una solución, procurando realizar el mínimo cambio posible, y teniendo en cuenta si este cambio provocará alguna alteración que repercuta en una nueva anomalía.

Se implantará el cambio documentando cada fase a realizar, y las consecuencias de cada fase. En caso de no solucionar el problema se estudiará la documentación generada para proyectar otro cambio, partiendo de la situación original que generó la anomalía, es decir, deshaciendo el cambio inicial proyectado, salvo que forme parte del nuevo cambio a realizar.

Debe, en último caso, valorarse la información inicial de la anomalía, y repasar las posibilidades planteadas inicialmente para encontrar posibles errores o descuidos, siempre con la navaja de Ockham como herramienta fundamental.

Parodia. Guillermo de Baskerville, de "El nombre de la rosa" representa a Guillermo de Ockham y su "navaja"

 

Métodos de resolución de problemas

El diccionario de la RAE no define claramente la diferencia entre procedimiento y método, cosa a la que ya me tiene acostumbrado, llamándose Real Academia Española, cuando no se ocupa de asuntos del país que toma nombre , sino del idioma, originado donde el Ebro y el camino se Santiago se cruzan, que tiene por nombre Castellano, y hablado, tanto en reinos como en repúblicas, y forjado, día a día, por aquellos que, precisamente, no son académicos.

En nuestro caso, emplearemos el significado con el matiz añadido que le corresponde. Un procedimiento implica un proceso, el cual, a su vez, puede estar compuesto de otros procesos. Un método es la descripción de las técnicas para llevar a cabo un fin determinado.

Por lo tanto un procedimiento implica distintos métodos, pero un método no implica distintos procedimientos.

 Teniendo clara la diferencia entre método y procedimiento, se puede comprender que tengan una distinta clasificación.

Los métodos de resolución de problemas están basados en el modelo de pila de protocolos del modelo OSI, de modo que, la capa que se tome de inicio, determina el método a emplear.

De esta forma hay tres métodos:

Generalmente, el fallo está en la gestión del usuario o en la configuración (o desconfiguración) de la aplicación usada. El caso de los plug-in o complementos del navegador de Internet, es lo más habitual.

Generalmente, si el problema es limitado, conviene el método de descenso de capas, pero si es más complejo o extraño, es más conveniente el ascenso de capas. El método de selección es más conveniente después de haber aplicado otros métodos que nos orientan sobre la ubicación (capa) de la anomalía.

Muchos de los avisos de avería que se registran en los centros de mantenimiento, corresponden a un patrón preestablecido. Dependiendo del grupo en el que clasifica el aviso, el operador seguirá un diagrama de flujo predeterminado para cada grupo, en el que preguntará al usuario o cliente, por distintos aspectos verificables de forma simple, y en función de las respuestas, determinará el tipo de aviso, urgencia o procedimiento establecido para su solución.

En estos casos, el personal técnico de campo, recibe el aviso clasificado por el operador para desplazarse al lugar de la anomalía. Una vez allí, se comprueba que el tipo de anomalía corresponde al esperado, y con mucha frecuencia ocurre que la anomalía está provocada por causas muy diferentes a las deducibles por el testimonio de los usuarios y la documentación recibida. En temas siguientes abordaremos de nuevo estas cuestiones.

Documentación de la Incidencia

Como he mencionado, en muchos casos recibimos esa documentación para iniciar los procesos de resolución, pero en otros casos, dependiendo del tipo de anomalía, puede ser necesario que seamos nosotros quienes documentemos la avería para ser estudiada por otra persona o grupo de personas.

En estos casos la documentación que debemos aportar será la siguiente:

Diagramas de flujo

La documentación asociada a la resolución de un problema debe permitir su consulta de forma rápida. El método más eficaz consiste en la elaboración de diagramas de flujo, como se dijo anteriormente, en los que una nueva incidencia puede suponer la comprobación de un nuevo parámetro a la hora de solucionar anomalías de la red.

Diagrama de  clasificación de anomalía de red

Estos diagramas de flujo permiten establecer procedimientos sistemáticos a la hora de resolver incidencias de todo tipo. Cada red puede tener unas características especiales, un conjunto de sub-redes o determinado tipo de dispositivos de conectividad que hace indispensable que el administrador de red elabore un diagrama de flujo que simbolice los procedimientos de análisis de averías y anomalías.

Microsoft ofrece una gran variedad de herramientas para la elaboración de diagramas de flujo (Word, Power Point, Visio, etc...) pero existe un programa (gracias a Dios y a los programadores de open source) que se ha hecho estándar por ser open source (totalmente gratuito), llamado DIA, con licencia GPLv2.

Diagramas básicos

Los diagramas de flujo se componen de elementos geométricos con texto en su interior unidos por una ruta a seguir. Hay distintos tipos de elementos, dependiendo de la naturaleza del proceso a representar, pero en nuestro caso nos bastará con 5 elementos:

  1. Proceso definido: Rectángulo con bandas a los lados. Lo usaremos para iniciar el diagrama de flujo y establecer las condiciones previas del proceso.
  2. Proceso: Rectángulo. Es el elemento más usado para describir los distintos sub procesos que componen el proceso general.
  3. Decisión: Rombo. Es el elemento más importante al establecer parámetros a verificar y cuyo valor determina cual de las dos salidas debe tomarse. Debe incluir un SI y un NO o una descripción más detallada.
  4. Conector: Círculo. Es un elemento de continuidad en otro diagrama de flujo o de finalización, por ejemplo, por no corresponder la incidencia.
  5. Documentación. Rectángulo con una onda en la base. Elemento de documentación del proceso, cierre de incidencia y finalización del diagrama.

No fueron mil las palabras, pero he aquí la imagen:

Elementos básicos del diagrama (Izquierda), con ejemplos (derecha).
Todo diagrama debe tener un comienzo y, al menos, un final.

Todo elemento debe estar conectado marcando una dirección, con elementos anteriores y posteriores.

Todas las decisiones deben tener marcado el valor consultado en sus bifurcaciones.

Siempre debe haber un proceso específico de documentación de la incidencia.

 Actividades de autoevaluación

ACTIVIDAD DE AUTOEVALUACIÓN: Comandos TCP/IP-UnixWindows
ACTIVIDAD DE AUTOEVALUACIÓN: Diagramas de flujo
ACTIVIDAD DE AUTOEVALUACIÓN: Procedimientos sistemáticos