This page was exported from Administración y Diseño de Redes Departamentales [ https://redes.noralemilenio.com ]
Export date: Tue Mar 2 3:47:46 2021 / +0000 GMT

Desarrollo de supuestos y/o casos prácticos simulados, debidamente caracterizados, para el diagnóstico y localización de averías en una red


En la realización de los supuestos prácticos, se van a utilizar los componentes reflejados en el escenario de ejemplo de la siguiente imagen:



El host Server-PT Servidor ofrece servicios de DNS (Domain Name Server) y de WWW (World Wide Web) para el dominio <midominio.es>, accesibles a través de la URL: <http://midominio.es>.

El host Server-PT Servidor1 ofrece servicio de asignación de direcciones dinámica DHCP.

Todos los servidores tienen abierto y accesible el servicio de administración remota por medio del protocolo SSH (Secure Shell).

Interpretar la documentación del sistema, identificando los distintos bloques funcionales y componentes específicos que lo componen

En el esquema lógico se puede diferenciar:

  • Un subsistema horizontal, la red interna en color naranja, formado por un router, un switch, un servidor que hace las funciones de servidor DHCP, asignando direcciones IP a los dispositivos que las soliciten, y dos puestos de trabajo; todo ello conectado en estrella.

  • Una red extensa accesible a través de router ISP que ofrece servicios de DNS (Servidor de Nombres de Dominio) y HTTP (Protocolo de Transferencia de Hipertexto), con una entrada de dominio activa con URL: <http://midominio.es>; accesible desde el navegador web del escritorio de los puestos de trabajo PC0 y PC1.


Identificar los síntomas de la avería caracterizándola por los efectos que produce

Sobre el escenario de ejemplo se produce una avería. Esta llega al Departamento de Informática mediante el alta de incidencia, utilizando un software de gestión de incidencias interno.

Al tratar la incidencia, los efectos que se observan en un primer momento son los siguientes:

  • Al acceder con el navegador web de PC1 a la url <http://midominio.es> se obtiene el mensaje Request Timeout en la ventana del navegador.


uf1878-cap5-28

  • Desde el puesto de trabajo PC0 ocurre exactamente lo mismo: Request Timeout al intentar acceder a la web del dominio <midomin¡o.es>.

  • No existen indicativos de que el servidor Server-PT Servidor tenga problemas de funcionamiento de carácter hardware.


Analizando los síntomas de esta avería, en un primer diagnóstico se puede pensar que puede estar producida tanto por problemas físicos como por problemas lógicos, al ser un componente software el principal implicado en la avería.

Realizar al menos una hipótesis de la causa posible que puede producir la avería, relacionándola con los síntomas (físicos y/o lógicos) que presenta el sistema

Analizando el mapa topológico de la instalación, se observa que entre los ordenadores clientes y el servidor que ofrece los servicios de WWW existen distintos dispositivos que intervienen en el proceso de transmisión de datos en ambos sentidos: Switch0, Router0, Router ISP y Switch1.

Se descarta de las posibles causas el dispositivo Switch0. La comunicación interna en la zona naranja se realiza sin problemas. Los PC-PT obtienen sus direcciones IP sin problemas.

Utilizando una de las herramientas software de diagnóstico, tracert o traceroute, se va a comprobar si están accesibles los dispositivos intermedios entre el PC de prueba y el servidor problemático.

Desde uno de los PCs se lanza el comando:

> tracert midominio.es

uf1878-cap5-29

Al ejecutar el comando da como resultado una traza completa hasta el servidor, por lo que se puede descartar como posible foco de avería cualquiera de los componentes intermedios entre el servidor y el PC.

Se puede observar en la ejecución del comando que el servicio de resolución de nombres DNS ha funcionado correctamente. Esto es una evidencia clara de que la comunicación desde el PC con el servidor funciona correctamente y que posiblemente el problema esté centrado en el propio servicio HTTP.

Vistos los síntomas, y sabiendo que no hay problemas físicos en las líneas de transmisión, se cree que el inconveniente puede estar originado por un problema lógico del propio servicio HTTP del servidor con IP 66.102.9.104/8.

Realizar un plan de intervención en el sistema para determinar la causa o causas que producen la avería

Se sabe que utilizando la herramienta de diagnóstico traceroute desde cualquiera de los puestos de trabajo se accede al servidor sin problemas.

En este caso, la asistencia puede llevarse accediendo remotamente al servidor, ya que la comunicación con este es correcta.

Al no responder el servicio de HTTP, no se necesitará una planificación previa y podrá atenderse en el momento que se crea más oportuno (por lo general, lo antes posible).

Si el procedimiento de resolución de averías de servicios requiere de autorización por parte de algún responsable, será necesario cumplimentar el correspondiente parte de avería y tramitar su solicitud.

Una vez se tenga la debida autorización se procederá a su resolución.

Localizar el elemento (físico o lógico) responsable de la avería y realizar la sustitución (mediante la utilización de componentes similares o equivalentes) o modificación del elemento, configuración y/o programa, aplicando los procedimientos requeridos y en un tiempo adecuado.

Al acceder remotamente a la configuración del servidor, se observa que efectivamente el servicio HTTP se encuentra apagado:

uf1878-cap5-30

En la imagen anterior puede observarse como el servicio HTTP efectivamente se encuentra en estado de Apagado. También puede observarse que el servicio de acceso seguro HTTPS está en estado de Encendido. Esto implica que si se hubiese accedido mediante el protocolo seguro de acceso a hipertexto se hubiese obtenido respuesta del servidor y se hubiese afinado aún más en la posible causa de avería.

Realizar las comprobaciones, modificaciones y ajustes de los parámetros del sistema según las especificaciones de la documentación técnica del mismo, utilizando las herramientas apropiadas, que permitan su puesta a punto en cada caso

Localizada la avería se utilizará el procedimiento de puesta en servicio del servidor web siguiendo los pasos que dicte y utilizando, si lo hay, el check list correspondiente de la puesta en servicio. A modo de ejemplo se incluye el siguiente check list:

uf1878-cap5-31

Una vez solucionado el problema, se realizada una prueba de conexión desde cualquiera de los puestos de trabajo para comprobar que se ha solventado correctamente este y vuelve a estar operativo el servicio afectado:

uf1878-cap5-32

Elaborar un informe-memoria de las actividades desarrolladas y resultados obtenidos, estructurándolo en los apartados necesarios para una adecuada documentación de las mismos (descripción del proceso seguido, medios utilizados, medidas, explicación funcional y esquemas)

Como informe de la incidencia se redactaría el siguiente:

Descripción de la incidencia


Se recibe una entrada de incidencia N° ______ por imposibilidad de acceso al dominio: <midominio.es>.

Comprobaciones iniciales

Se han realizado las comprobaciones de comunicación mediante el comando tracert de conexión del enlace comprendido desde los puestos de trabajo hasta el servidor web, observando que el servidor respondía a todas las peticiones menos a la del servicio de HTTP

Operativa de resolución de incidencia

Mediante conexión remota por SSH y siguiendo la operativa indicada en el procedimiento de puesta en servicio de un servicio web, se ha procedido a la puesta en marcha del servicio HTTP que se encontraba apagado y a la realización posterior de las pruebas oportunas desde un puesto de trabajo.

Elementos afectados

El elemento afectado en la incidencia corresponde al servicio HTTP del servidor Server-PT Servidor,

Recursos materiales utilizados

No ha sido necesaria ninguna intervención a nivel de hardware.

Recursos software utilizados

Se ha utilizado el comando tracert, conexión administrativa mediante SSH y un navegador web para comprobaciones finales.

Estado de la incidencia

El estado de la incidencia tras la intervención es de RESUELTA.

 
Post date: 2015-05-24 15:58:47
Post date GMT: 2015-05-24 15:58:47
Post modified date: 2015-05-24 15:58:47
Post modified date GMT: 2015-05-24 15:58:47
Powered by [ Universal Post Manager ] plugin. HTML saving format developed by gVectors Team www.gVectors.com