RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
6. RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES
6.1. ESTRATEGIAS Y PARÁMETROS DE RENDIMIENTO
Lo ideal sería que, una vez que montamos una red, funcionase bien para
siempre, pero esto no es lo real. Con frecuencia se produce un desgaste de los
materiales, personas utilizando la red que pueden desconectar accidentalmente
un cable, un software malicioso que se introduce en nuestra red, etc. Por ello, en
este apartado vamos a ver en que debemos fijarnos para darnos cuenta de que la
red no está funcionando adecuadamente.
6.1.1. ESTRATEGIAS
Existen multitud de estrategias para aislar, identificar, priorizar y resolver un
problema. Algunas de esas son:
A. Diagnostico diferencial
Consiste en plantearse una serie de hipótesis que pueden explicar el problema,
valorar cuál de ellas es la más probable e intentar resolver el problema partiendo
de esa base.
Ejemplo
Supongamos que nuestro un ordenador un día, de repente, ya no se conecta a
Internet. Podríamos pensar que las causas son:
- El cable de red se ha desconectado.
- La tarjeta de red se ha estropeado.
- El controlador o driver de la tarjeta de red se ha desconfigurado.
- Otras causas.
Estas causas que acabamos de mencionar serían las hipótesis del diagnóstico
diferencial. Para resolver el problema, pensaríamos cuál de todas las hipótesis es
la más probable, en nuestro caso, lo más probable sería que el cable de red se
haya desconectado. Pero supongamos que ayer instalamos una tarjeta gráfica
nueva con sus controladores correspondientes, puede ser que estos controladores
no sean compatibles con los de la tarjeta de red y hayan entrado en conflicto. Con
lo cual, en este caso, la hipótesis más probable podría se el mal funcionamiento
del controlador.
B. Divide y vencerás
Esta estrategia consiste en tratar de aislar la zona o componentes de la red
donde se está dando el problema.
Ejemplo
Supongamos que dentro de nuestra red tenemos varios segmentos y en uno de
ellos los paquetes que enviamos no llegan a su destino.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Según esta estrategia, cuando se produce el problema, lo que debemos hacer es
mirar si este se puede aislar, es decir, ¿es un problema que afecta a toda la red o
solo a una pare de ella?
En nuestro caso, el problema solo afecta a uno de los segmentos de la red, con lo
que podemos concentrarnos en el segmento que ha dejado de funcionar
correctamente. El resto de la red seguirá trabajando sin dificultades. Una vez
localizado el segmento conflictivo, procederemos a intentar nuevamente reducir
el problema, por ejemplo: ¿el problema de envío de paquetes se da en todos los
ordenadores de este segmento o solo entre algunos ordenadores?
Y así, sucesivamente, iríamos acotando el problema todo lo que pudiéremos hasta
tenerlo lo más localizado posible.
C. Enfoque ascendente
En la resolución de problemas ascendente, se comienza por los componentes
físicos de la red y se atraviesan las capas del modelo OSI de manera ascendente
hasta que se identifica la causa del problema, como se muestra en la siguiente
imagen.
La resolución de problemas ascendente es un buen método para usar cuando se
sospecha que el problema es físico. La mayoría de los problemas de red residen en los
niveles inferiores, de modo que, con frecuencia, la implementación del método
ascendente es eficaz.
La desventaja del método de resolución de problemas ascendente es que
requiere que revise cada dispositivo e interfaz en la red hasta que detecte la
posible causa del problema. Recuerde que se debe registrar cada conclusión y
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
cada posibilidad, de modo que es posible que haya mucho papeleo asociado a este
enfoque.
Ejemplo
Supongamos que uno de los ordenadores que está conectado a la red de la
empresa de repente no puede imprimir en la impresora de red.
Según esta estrategia, tendríamos que empezar a buscar el fallo comenzando por
las capas inferiores e ir ascendiendo por las capas hasta dar con el problema.
Recordemos que la primera de las capas de modelo OSI hace referencia a la parte
física de los elementos, es decir, a los conectores, funcionamiento eléctrico, etc.
Por lo que lo primero que deberíamos comprobar es si físicamente todos los
elementos se encuentran en perfecto estado: si tanto el ordenador como la
impresora se encuentra enchufados a la red eléctrica y a la red de datos, además
de comprobar que ambos están encendidos. Si no hubiese ningún problema en la
capa física, procederíamos a comprobar la capa de enlace de datos, donde
investigaríamos el tipo de error que nos muestra el ordenador cuando intenta
imprimir (si es que da algún error). Si en esta capa tampoco encontrase ningún
error, seguiríamos con la capa de red y miraríamos si está funcionando
correctamente, si los demás equipos si pueden imprimir, si nuestro equipo tiene
acceso a los demás recursos de red o no, si nuestro equipo puede acceder a la red,
etc. De esta manera, iríamos ascendiendo por las diferentes capas hasta dar con el
problema.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
D. Enfoque descendente
En la siguiente imagen, la resolución de problemas descendente comienza por
las aplicaciones de usuario final y atraviesa las capas del modelo OSI de manera
descendente hasta que se identifica la causa del problema.
Antes de abordar las partes más específicas de la red, se prueban las
aplicaciones de usuario final de un sistema final. Use este método para los
problemas más simples o cuando crea que el problema está en un software.
La desventaja del enfoque descendente es que requiere que se revise cada
aplicación de red hasta que se detecte la posible causa del problema. Se debe
registrar cada conclusión y cada posibilidad. El desafío es determinar qué
aplicación se debe examinar primero.
Ejemplo
Esta estrategia es igual que la anterior, pero en este caso, en lugar de empezar por
la capa física del modelo e ir ascendiendo por las distintas capas, empezaríamos
por la capa más alta e iríamos descendiendo. Es decir, empezaríamos a buscar a un
nivel más alto, más cercano al usuario, e iríamos descendiendo hasta los niveles
más bajos.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Si tuviésemos el mismo problema que en el caso anterior, pero quisiéramos
utilizar esta estrategia, seguiríamos el siguiente procedimiento: comenzaríamos
por la capa de aplicación, mirando si existe algún problema en la aplicación de la
impresora que esté impidiendo su uso (que no esté bien configurada, que haya
demasiados trabajos en cola, etc.) comprobaríamos los protocolos que se están
utilizando entre las aplicaciones que están interviniendo en el proceso. Si en esta
capa no encontrásemos el problema, continuaríamos con la siguiente: en la capa
de presentación miraríamos si hay incompatibilidad en el formato de los datos, en
los documentos que estamos mandando a imprimir, en las tramas que se están
enviando, si van comprimidas por la red, si van cifradas, etc. Y así hasta llegar al
problema o la capa más baja.
E. Sustitución
La sustitución es otra metodología rápida de resolución de problemas, que
implica cambiar el dispositivo problemático por uno que se sepa que funciona. Si
se corrige el problema, el administrador de red sabe que el problema está en el
dispositivo que quitó. Si el problema permanece, la causa puede estar en cualquier
otro lugar.
En situaciones específicas, este puede ser un método ideal para la resolución
rápida de un problema, por ejemplo, cuando queda inactivo un único punto de
error crítico, como un router de frontera. En vez de resolver el problema, puede
resultar más beneficioso reemplazar el dispositivo y restaurar el servicio.
Ejemplo
Supongamos que intentamos enviar mensajes en nuestra red, pero estos no legan,
ningún mensaje llega. Los ordenadores se encuentran todos en diferentes
segmentos. Lo más probable es que el router esté dando problemas. Como
tenemos otro router nuevo, con las mismas características o muy similares,
procedemos a cambiar un router, por otro y volver a enviar mensajes. Otra opción
podría haber sido cambiar las tarjetas de red, pero en este caso, al fallar todos los
equipos, era más que probable que el fallo estuviese en un switch o en el router.
F. Simulación de averías
Consiste en intentar reproducir el problema. Simulando la avería, para
confirmar o descartar nuestras hipótesis.
Ejemplo
Supongamos que tenemos dos equipos dentro de una misma red y entre ellos no
pueden mandarse mensajes porque no llegan. Estos equipos están conectados a
un switch. Si utilizamos esta estrategia, lo que tendríamos que hacer sería intentar
representar el escenario y ver si se da nuevamente el problema. En ese caso,
tendremos el problema aislado y podríamos empezar a aplicar soluciones hasta
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
ver cuál da resultado. Otra opción, si no disponemos de los elementos físicos,
Odría ser utilizar algún simulador y reproducir en nuestros equipos y el switch.
G. Fuentes externas
Consiste en consultar en foros de Internet, en la página web del fabricante, en las PAQ
o preguntar a otros profesionales.
Ejemplo
Supongamos que se nos ha dado un problema en la red wifi que administramos,
no encontramos la solución, y ya no se nos ocurre qué más probar.
Esta estrategia consiste en utilizar medios, como los foros. Podemos meternos en
la página web del fabricante de nuestro router inalámbrico y buscar entre el foro
de problemas a ver si alguien ha tenido el mismo que nosotros. Podemos buscar
entre las respuestas o bien, si no se ha planteado aún esa cuestión, podemos abrir
un nuevo hilo.
6.1.2. PARÁMETROS DEL RENDIMIENTO
Los parámetros de rendimiento ayudan a localizar las averías y a prevenirlas.
Cuando se trabaja con redes es de suma importancia conocer la manera en
cómo se están comunicando los dispositivos, para de esta manera realizar un
análisis que permita determinar la calidad del enlace de comunicaciones. Para
esto es necesario analizar el comportamiento de la red y de esta manera estimar
su rendimiento, debido a que una red mal configurada o con un pobre
rendimiento puede ocasionar grandes pérdidas de tiempo, bajas en la
productividad, etc.
Para poder resolver problemas que se puedan presentar es necesario conocer a
profundidad todos los parámetros de la red en cuestión además de realizar un
monitoreo de la misma para poder detectar cualquier anomalía, con estas
herramientas se puede hacer un diagnóstico acertado de cualquier tipo de
eventualidad para poder corregirla a tiempo.
Antes de efectuar un análisis como tal es importante definir ciertos parámetros
que permiten determinar el rendimiento de una red, y la calidad en la
comunicación, dichos parámetros son:
a) Tasa de transferencia: La tasa de transferencia expresa la velocidad a la que se
puede transmitir y se mide en bits/segundo (bps); No hay que confundir ancho
de banda con tasas de transferencia, el primero mide en hertzios y no mide
realmente la capacidad de transmisión de la red, mientras que la tasa de
transferencia sí, ya que toma en cuenta todos los factores para hacer una
medición real.
Por desgracia ningún tipo de red es capaz de proporcionar una tasa de
transferencia igual a la teórica. Cuando hacemos referencia a la que en
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
realidad se obtiene, se habla de tasa de transferencia real o simplemente tasa
de transferencia.
b) Throughput: se refiere a la cantidad “real” de información que se recibe, es
decir, es el número de paquetes que llegan bien a su destino.
c) Pérdida de paquetes: es la probabilidad de que se pierdan datos en el proceso
de comunicación, debido a la falta de espacio en buffers, por ejemplo. Esto
debido a que los buffers no tienen un tamaño infinito, si un paquete llega a un
buffer que está lleno se descarta.
d) Retrasos: esto se refiere los tiempos de retardo que sufren los datos en las
colas generadas por los buffers en los dispositivos de conmutación.
e) Otros factores: existen otros factores, además de los ya mencionados, que
pueden condicionar que una red funcione mejor o peor. Estos factores son:
- La topología de la red.
- El uso de esa red.
- Los protocolos que se estén utilizando
- El tipo de tarjeta de red.
- La finalidad de la red.
Aunque estos factores no puedan parecer relevantes a priori, si no estamos
obteniendo los resultados esperados, no es mala idea revisarlos.
Para tener estos parámetros controlados, tenemos en el mercado diferentes
herramientas como Ipert, TCPKali, Parkdale, etc. También hay herramientas que
nos permitir medir la velocidad de la red, como TotuSoft LAN Speed Test,
LANBench, NetStress, etc. Dependiendo del parámetro que queramos medir, es
importante buscar la herramienta adecuada.
Aunque no pueda considerarse técnicamente como una estrategia, en general,
lo que nos da la pista de que algo no está funcionando bien es un usuario que se
queja de que su equipo no funciona de manera adecuada o ha perdido la conexión
a Internet o algo similar. Por tanto, es muy importante prestar atención cuando
algún usuario nos comunica que está teniendo problemas.
6.2. Uso de modelos en capas para la resolución de problemas
Cuando se realiza la resolución de problemas, se pueden aplicar estos modelos
en capas a la red física para aislar los problemas de la red.
6.2.1. Modelo de referencia OSI
El modelo de referencia OSI proporciona un lenguaje común para los
administradores de red y se usa frecuentemente para resolver problemas de
red. Por lo general, los problemas se describen en términos de una
determinada capa del modelo OSI.
Este modelo describe la forma en que la información de una aplicación de
software en una computadora se desplaza a través de un medio de red hasta
una aplicación de software en otra computadora.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Las capas superiores (de 5 a 7) se ocupan de los problemas de aplicación y,
generalmente, se implementan solo en el software. La capa de aplicación es
la más cercana al usuario final.
Las capas inferiores (de 1 a 4) se ocupan de los problemas de transporte de
datos. Las capas 3 y 4 por lo general se implementan solo en el software. La
capa física (capa 1) y la capa de enlace de datos (capa 2) se implementan en
el hardware y el software. La capa física es la más cercana al medio físico de
red, como el cableado de la red, y es responsable de colocar efectivamente
la información en el medio.
Imagen 1: Modelo de referencia OSI
En la Imagen 1, se muestran algunos dispositivos comunes en las capas del
modelo OSI, que se deben examinar durante el proceso de resolución de
problemas de cada dispositivo.
Observe que los routers y los switches multicapa se muestran en la capa 4, la
capa de transporte. Si bien los routers y los switches multicapa generalmente
toman decisiones de reenvío en la capa 3, se pueden usar las ACL en esos
dispositivos para tomar decisiones de filtrado con la información de la capa 4.
6.2.2. Modelo TCP/IP
Similar al modelo de red OSI, el modelo de red TCP/IP también divide la
arquitectura de red en capas modulares. En la Imagen 2, se muestra la relación
entre el modelo de red TCP/IP y las capas del modelo de red OSI.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Esta es una asignación estrecha que permite que la suite de protocolos TCP/IP
se comunique correctamente con muchas tecnologías de red.
Imagen : Comparación del modelo OSI y el modelo TCP/IP
La capa de aplicación en la suite TCP/IP combina las funciones de las tres
capas del modelo OSI: sesión, presentación y aplicación. La capa de
aplicación proporciona comunicación entre aplicaciones tales como FTP,
HTTP y SMTP en hosts separados.
Las capas de transporte de TCP/IP y de OSI se corresponden directamente en
cuanto a su función. Esta capa es responsable del intercambio de segmentos entre
dispositivos en una red TCP/IP.
La capa de Internet de TCP/IP se relaciona con la capa de red del modelo OSI.
Esta capa es responsable de colocar los mensajes en un formato fijo para que los
dispositivos los administren.
La capa de acceso a Internet de TCP/IP corresponde a las capas física y de
enlace de datos de OSI. Esta capa se comunica directamente con los medios de red
y proporciona una interfaz entre la arquitectura de la red y la capa de Internet.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
6.2.3. Resolución de problemas de Red
[Link]. Resolución de problemas de la capa física
La capa física transmite bits desde una computadora a otra y regula la
transmisión de un flujo de bits a través del medio físico. La capa física es la
única con propiedades físicamente tangibles, como cables, tarjetas y
antenas.
Los problemas en una red con frecuencia se presentan como problemas de
rendimiento. Los problemas de rendimiento indican que existe una
diferencia entre el comportamiento esperado y el comportamiento
observado y que el sistema no funciona como se podría esperar
razonablemente.
Las fallas y las condiciones por debajo del nivel óptimo en la capa física no
solo presentan inconvenientes para los usuarios sino que pueden afectar la
productividad de toda la empresa. Las redes en las que se dan estos tipos
de condiciones por lo general se desactivan. Dado que las capas superiores
del modelo OSI dependen de la capa física para funcionar, el administrador
de red debe tener la capacidad de aislar y corregir los problemas en esta
capa de manera eficaz.
Imagen: Síntomas y causas de la capa física
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
A. Síntomas frecuentes de problemas de red en Capa Física
Los síntomas frecuentes de los problemas de red en la capa física incluyen
los siguientes:
Rendimiento inferior a la línea de base: las razones más frecuentes de
un rendimiento lento o deficiente incluyen servidores sobrecargados o con
alimentación insuficiente, configuraciones de router o switch inadecuadas,
congestión del tráfico en un enlace de baja capacidad y pérdida crónica de
tramas.
Pérdida de la conectividad: si un cable o un dispositivo fallan, el síntoma
más evidente es una pérdida de la conectividad entre los dispositivos que
se comunican a través de ese enlace o con el dispositivo o la interfaz que
presenta la falla. Esto se indica por medio de una simple prueba de ping. La
pérdida intermitente de la conectividad puede indicar una conexión floja u
oxidada.
Cuellos de botella o congestión de la red: si un router, una interfaz o un
cable fallan, es probable que los protocolos de routing redirijan el tráfico
hacia otras rutas que no estén diseñadas para transportar la capacidad
adicional. Esto puede provocar congestión o cuellos de botella en esas
partes de la red.
Tasas de uso de CPU elevadas: las tasas de uso de CPU elevadas son un
síntoma de que un dispositivo, como un router, un switch o un servidor,
funciona en el límite admitido por su diseño o lo supera.
Mensajes de error de la consola: los mensajes de error que se muestran
en la consola de un dispositivo indican un problema de la capa física.
B. Causas frecuentes de problemas de red en Capa Física
Los incidentes que comúnmente causan problemas de red en la capa física
incluyen los siguientes:
Problemas relacionados con la alimentación: Debe revisarse el
funcionamiento de los ventiladores y asegurarse de que los orificios de
entrada y salida de ventilación del bastidor no estén obstruidos.
Fallas de hardware: las tarjetas de interfaz de red (NIC) defectuosas
pueden ser la causa de errores de transmisión de red debido a colisiones
tardías, tramas cortas y jabber. Con frecuencia, “jabber” se define como la
condición en la que un dispositivo de red transmite continuamente datos
aleatorios, sin sentido, a la red.
Fallas del cableado: se pueden corregir numerosos problemas
simplemente por medio de volver a asentar cables que se desconectaron
de manera parcial.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Atenuación: la atenuación puede ocurrir cuando la longitud de un cable
supera el límite de diseño para los medios o cuando hay una conexión
deficiente que se debe a un cable flojo o a contactos sucios u oxidados.
Ruido: la interferencia electromagnética (EMI) local se conoce
comúnmente como “ruido”. El ruido se puede generar a partir de muchas
fuentes, como estaciones de radio FM, o cualquier elemento que cuente
con un transmisor más potente que el de un teléfono celular.
Errores de configuración de la interfaz: muchos elementos se pueden
configurar incorrectamente en una interfaz y ocasionar que se desactive,
por ejemplo, una frecuencia de reloj incorrecta, un origen de reloj
incorrecto y que la interfaz no esté encendida.
Límites de diseño excedidos: un componente puede operar de manera
deficiente en la capa física porque se usa a una tasa promedio superior a la
que está configurado para funcionar.
Sobrecarga de CPU: los síntomas incluyen procesos con porcentajes
elevados de uso de CPU, descartes de la cola de entrada, rendimiento
lento, lentitud o falta de respuesta de los servicios de router.
[Link]. Resolución de problemas de la capa de enlace de datos
La resolución de problemas de capa 2 puede ser un proceso desafiante.
La configuración y el funcionamiento de estos protocolos son
fundamentales para crear redes con ajustes precisos y en condiciones de
funcionamiento.
Los problemas de capa 2 causan síntomas específicos que, al
reconocerse, ayudan a identificar el problema rápidamente.
Imagen 2: Síntomas y causas de la capa de enlace de datos
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
A. Síntomas frecuentes de problemas de red en Capa Enlace de datos
Los síntomas frecuentes de los problemas de red en la capa de enlace
de datos incluyen los siguientes:
Falta de funcionalidad o conectividad en la capa de red o en las
capas superiores: algunos problemas de capa 2 pueden detener el
intercambio de tramas a través de un enlace, mientras que otros solo
provocan un deterioro del rendimiento de la red.
Funcionamiento de la red por debajo de los niveles de
rendimiento de línea de base: en una red, pueden ocurrir dos tipos de
funcionamiento deficiente en la capa 2. (1) que las tramas elijan una ruta
deficiente al destino, pero lleguen. En este caso, la red podría
experimentar un uso de ancho de banda elevado en enlaces que no
deberían tener ese nivel de tráfico. (2) que se descarten algunas tramas.
Estos problemas se pueden identificar mediante las estadísticas del
contador de errores y los mensajes de error de la consola en el switch o el
router. En un entorno Ethernet, un ping extendido o continuo también
revela si se descartan tramas.
Difusiones excesivas: los sistemas operativos usan difusiones y
multidifusiones ampliamente para detectar los servicios de red y otros
hosts. Por lo general, las difusiones excesivas son el resultado de una de las
siguientes situaciones: aplicaciones programadas o configuradas
incorrectamente, grandes dominios de difusión de capa 2 o problemas de
red subyacentes, como bucles de STP o rutas inestables.
Mensajes de la consola: a veces, un router reconoce que se
produjo un problema de capa 2 y envía mensajes de alerta a la consola.
Generalmente, un router hace esto cuando detecta un problema con la
interpretación de las tramas entrantes (problemas de encapsulación o
entramado) o cuando se esperan keepalives pero no llegan.
B. Causas frecuentes de problemas de red en Capa Enlace de datos
Los problemas en la capa de enlace de datos que con frecuencia
provocan problemas de conectividad o rendimiento de la red incluyen los
siguientes:
Errores de encapsulación: ocurre porque los bits que el emisor
coloca en un campo determinado no son los que el receptor espera ver.
Esta condición se produce cuando la encapsulación en un extremo de un
enlace WAN está configurada de manera diferente de la encapsulación que
se usa en el otro extremo.
Errores de asignación de direcciones: en las topologías, como
punto a multipunto, Frame Relay o Ethernet de difusión, es fundamental
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
darle a la trama una dirección de destino de capa 2 correcta. Esto asegura
su llegada al destino correcto. Para lograr esto, el dispositivo de red debe
encontrar la coincidencia entre una dirección de destino de capa 3 y la
dirección de capa 2 correcta mediante mapas estáticos o dinámicos.
Errores de entramado: las tramas generalmente operan en
grupos de bytes de 8 bits. Cuando una trama no termina en un límite de
bytes de 8 bits, se produce un error de entramado. Cuando sucede esto, el
receptor puede tener problemas para determinar dónde termina una
trama y dónde comienza la otra.
Fallas o bucles de STP: el objetivo del protocolo de árbol de
expansión (STP) es convertir una topología física redundante en una
topología de árbol mediante el bloqueo de los puertos redundantes. La
mayoría de los problemas de STP se relacionan con el reenvío de bucles,
que se produce cuando no se bloquean puertos en una topología
redundante y el tráfico se reenvía en círculos indefinidamente, lo que
implica una saturación excesiva provocada por una tasa elevada de
cambios en la topología STP.
[Link]. Resolución de problemas de la capa de red
Los problemas de la capa de red incluyen cualquier problema que
comprenda a un protocolo de capa 3, ya sea un protocolo de routing (como
IPv4 o IPv6) o un protocolo de routing (como EIGRP, OSPF, entre otros).
Imagen 3: Síntomas y causas de la capa de red
A. Síntomas frecuentes de problemas de red en Capa de Red
Los síntomas frecuentes de los problemas de red en la capa de red
incluyen los siguientes:
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Falla de red: se produce cuando esta no funciona o funciona
parcialmente, lo que afecta a todos los usuarios y a todas las
aplicaciones en la red.
Rendimiento por debajo del nivel óptimo: los problemas de
optimización de la red por lo general comprenden a un subconjunto de
usuarios, aplicaciones, destinos o un determinado tipo de tráfico. Es
difícil detectar los problemas de optimización, y es incluso más difícil
aislarlos y diagnosticarlos. Esto generalmente se debe a que estos
problemas abarcan varias capas o, incluso, al equipo host.
En la mayoría de las redes, se usan rutas estáticas junto con protocolos
de routing dinámico. La configuración incorrecta de las rutas estáticas
puede provocar un routing deficiente. En algunos casos, las rutas
estáticas configuradas incorrectamente pueden generar bucles de
routing que hacen que algunas partes de la red se vuelvan
inalcanzables.
La resolución de problemas de protocolos de routing dinámico
requiere una comprensión profunda de cómo funciona el protocolo de
routing específico. Algunos problemas son comunes a todos los
protocolos de routing, mientras que otros son específicos de un
protocolo de routing particular.
Nota: No existe una única plantilla para resolver problemas de capa 3.
Los problemas de routing se resuelven con un proceso metódico, por
medio de una serie de comandos para aislar y diagnosticar el
problema.
B. Causas frecuentes de problemas de red en Capa de Red
Las siguientes son algunas áreas que se deben explorar al diagnosticar
un posible problema que involucre protocolos de routing:
Problemas de red generales: con frecuencia, un cambio en la
topología, como un enlace inactivo, puede tener efectos en otras áreas
de la red que tal vez no sean evidentes en ese momento. Esto puede
implicar instalar nuevas rutas, estáticas o dinámicas, o eliminar otras.
Determine si algún elemento de la red cambió de manera reciente y si
hay alguna persona trabajando en la infraestructura de la red en ese
momento.
Problemas de conectividad: revise si existe algún problema de
conectividad o en los equipos, incluidos problemas de alimentación
como cortes de energía y problemas ambientales (por ejemplo,
recalentamiento). También revise si hay problemas de capa 1, como
problemas de cableado, puertos defectuosos y problemas del ISP.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Problemas de vecinos: si el protocolo de routing establece una
adyacencia con un vecino, revise si hay algún problema con los routers
en lo que respecta a la formación de adyacencias de vecinos.
Base de datos de topología: si el protocolo de routing usa una tabla o
base de datos de topología, revíselas para ver si existe algo
inesperado, como entradas faltantes o imprevistas.
Tabla de routing: revise la tabla de routing para ver si existe algo
inesperado, como rutas faltantes o imprevistas. Use los
comandos debug para ver las actualizaciones de routing y el
mantenimiento de la tabla de routing.
[Link]. Resolución de problemas de la capa de transporte: ACL
Los problemas de red pueden surgir a partir de problemas de la capa de
transporte en el router, especialmente en el perímetro de la red, donde se
examina y se modifica el tráfico.
Arquitecturas de Red en Evolución
Dos de las tecnologías de capa de transporte que se implementan con más
frecuencia son las listas de control de acceso (ACL) y la traducción de
direcciones de red (NAT).
Imagen 4: Síntomas y causas de la capa de transporte
A. Errores comunes de configuración de ACL
La mayoría de los problemas frecuentes con las ACL se debe a una
configuración incorrecta.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Imagen 5: Errores comunes configuración ACL
Los problemas con las ACL pueden provocar fallas en sistemas que, por lo
demás, funcionan correctamente. Comúnmente, las configuraciones
incorrectas ocurren en varias áreas:
Selección del flujo de tráfico: la configuración incorrecta del router más
frecuente es aplicar la ACL al tráfico incorrecto.
Orden de entradas de control de acceso: el orden de las entradas en
una ACL debe ir de lo específico a lo general. Si bien una ACL puede tener
una entrada para permitir específicamente un flujo de tráfico en particular,
los paquetes nunca coincidirán con esa entrada si una entrada anterior en
la lista ya los rechazó.
Instrucción implícita de denegar todo el tráfico: cuando no se requiere
un nivel de seguridad elevado en la ACL, este elemento implícito de control
de acceso puede ser la causa de una configuración incorrecta de la ACL.
Direcciones y máscaras wildcard IPv4: las máscaras wildcard IPv4
complejas proporcionan mejoras importantes en términos de eficiencia,
pero están más sujetas a errores de configuración.
Selección del protocolo de la capa de transporte: al configurar las ACL,
es importante que se especifiquen solo los protocolos de la capa de
transporte correctos.
Puertos de origen y destino: controlar el tráfico entre dos hosts de
manera adecuada requiere elementos simétricos de control de acceso para
las ACL de entrada y de salida.
Uso de la palabra clave established: aumenta la seguridad que se
proporciona mediante una ACL, pero si se aplica incorrectamente puede
tener lugar resultados imprevistos.
Protocolos poco frecuentes: las ACL configuradas incorrectamente
suelen causar problemas en protocolos distintos de TCP y UDP.
La palabra clave log es un comando útil para ver la operación de las ACL en
las entradas de ACL.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
B. Resolución de problemas de la capa de transporte: NAT para IPv4
Existen varios problemas con la NAT, como la falta de interacción con
servicios como DHCP y tunneling. Estos pueden incluir la configuración
incorrecta de la NAT interna, la NAT externa o la ACL.
Imagen 6: Áreas frecuentes de interoperabilidad con NAT
Otros problemas incluyen interoperabilidad con otras tecnologías de red,
especialmente con aquellas que contienen o derivan información de
direccionamiento de red del host en el paquete.
C. Áreas frecuentes de interoperabilidad con NAT
Algunas de estas tecnologías incluyen las siguientes:
BOOTP y DHCP: ambos protocolos administran la asignación automática
de direcciones IPv4 a los clientes. Recuerde que el primer paquete que
un nuevo cliente envía es un paquete IPv4 de difusión de solicitud de
DHCP. El paquete de solicitud de DHCP tiene la dirección IPv4 de origen
[Link]. Debido a que la NAT requiere direcciones IPv4 de origen y de
destino válidas, BOOTP y DHCP pueden tener dificultades para operar a
través de un router que ejecuta una NAT estática o dinámica.
DNS y WINS: debido a que un router que ejecuta una NAT dinámica
cambia la relación entre las direcciones internas y externas
periódicamente, a medida que las entradas de la tabla se vencen y se
vuelven a crear, un servidor DNS o WINS fuera del router NAT no tiene
una representación precisa de la red dentro del router.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
SNMP: de manera similar a los paquetes DNS, la NAT no puede alterar la
información de direccionamiento almacenada en el contenido de datos
del paquete.
Nota: La configuración de la característica de aplicación auxiliar IPv4
puede contribuir a la resolución de los problemas anteriormente
mencionados.
Protocolos de cifrado y tunneling: los protocolos de cifrado y tunneling
suelen requerir que el tráfico se origine en un puerto UDP o TCP
específico o usan un protocolo en la capa de transporte que la NAT no
puede procesar. Por ejemplo, la NAT no puede procesar los protocolos
de tunneling IPsec y los protocolos de encapsulación de routing genérico
usados por las implementaciones de VPN.
Nota: el router puede reenviar DHCPv6 de un cliente IPv6 mediante el
comando ipv6 dhcp relay.
[Link]. Resolución de problemas de la capa de aplicación
La mayoría de los protocolos de la capa de aplicación proporcionan
servicios para los usuarios. Los protocolos de la capa de
aplicación normalmente se usan para la administración de red, la
transferencia de archivos, los servicios de archivos distribuidos, la
emulación de terminal y el correo electrónico. Con frecuencia, se agregan
nuevos servicios para usuarios, como VPN y VoIP.
Imagen 7: Capa de aplicación
En la ilustración, se muestran los protocolos de capa de aplicación de
TCP/IP más conocidos e implementados, que incluyen los siguientes:
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
SSH/Telnet: permite a los usuarios establecer conexiones de sesión de
terminal a los hosts remotos.
HTTP: admite el intercambio de texto, gráficos, sonido, video y otros
archivos multimedia en la Web.
FTP: realiza transferencias interactivas de archivos entre los hosts.
TFTP: realiza transferencias interactivas básicas de archivos,
generalmente, entre hosts y dispositivos de red.
SMTP: admite servicios básicos de entrega de mensajes.
POP: conecta a los servidores de correo electrónico y descarga correo
electrónico.
Protocolo simple de administración de red (SNMP) : recopila información de
administración de los dispositivos de red.
DNS: asigna direcciones IP a los nombres asignados a los dispositivos de
red.
Sistema de archivos de red (NFS): habilita las computadoras para montar
unidades en hosts remotos y operarlas como si fueran unidades locales.
Desarrollado originalmente por Sun Microsystems, se combina con otros
dos protocolos de capa de aplicación, la representación externa de
datos (XDR) y la llamada a procedimiento remoto (RPC), para permitir
un acceso transparente a los recursos de la red remota.
A. Síntomas y Causas de problemas de red en Capa de Aplicación
Los tipos de síntomas y causas dependen de la aplicación real propiamente
dicha.
Los problemas de la capa de aplicación impiden la provisión de servicios a
los programas de aplicación. Cuando las capas física, enlace de datos, de
red y de transporte funcionan, un problema en la capa de aplicación puede
tener como consecuencia recursos inalcanzables o inutilizables. Es posible
que, teniendo una conectividad de red plena, la aplicación simplemente no
pueda proporcionar datos.
Otro tipo de problema en la capa de aplicación ocurre cuando las capas
física, de enlace de datos, de red y de transporte funcionan, pero la
transferencia de datos y las solicitudes de servicios de red de un único
servicio o aplicación de red no cumplen con las expectativas normales de
un usuario.
Un problema en la capa de aplicación puede hacer que los usuarios se
quejen de que, al transferir datos o solicitar servicios de red, la red o la
aplicación específica con la que trabajan está inactiva o más lenta de lo
normal.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
6.3. INCIDENCIAS FÍSICAS E INCIDENCIAS LÓGICAS EN REDES LOCALES
6.3.1. Incidencias físicas.
Las incidencias físicas son las menos comunes, pero ocurren a medio y largo plazo.
Se muestran a continuación:
a) Fallo en la tarjeta de red inalámbrica:
Comprobar que el conector del cable de red esté correctamente conectado
a la tarjeta.
Comprobar que el dispositivo de interconexión esté conectado a la toma de
corriente.
Comprobar que el conector esté correctamente conectado al dispositivo de
interconexión.
Comprobar que la tarjeta de red este bien instalada.
b) Fallo en el cableado de la red:
Revisar el estado de los conectores de los dos extremos de los cables.
Comprobar la conexión entre los cables y las tarjetas de red.
Comprobar la conexión entre los cables y los dispositivos de interconexión
Comprobar que los cables no superan la longitud máxima para su categoría.
Revisar el estado del cable en sí, que no esté roto, doblado, etc.
c) Fallo en algún dispositivo específico de la red:
Comprobar que el dispositivo de interconexión está conectado a la
corriente.
Comprobar que el dispositivo de interconexión no está recalentado.
Si el problema afecta un solo nodo de los que están conectados al
dispositivo de interconexión, puede deberse a un fallo del puerto al que
está conectado. En este caso, el led de dicho puerto no se encenderá.
d) Fallo en el acceso a una máquina:
Comprobar que la máquina esté encendida.
Comprobar que no existen fallos en las tarjetas de red ni en los cables.
Ejecutar el comando ping a la máquina.
Estos fallos pueden ser debidos a accidentes (que alguien tropiece con un
cable y lo desconecte), condiciones ambientales no adecuadas (excesivo calor en
la sala), presencia de roedores (muerden algún cable), la instalación de un nuevo
elemento (no es compatible con otros programas), etc.
6.3.2. Incidencias lógicas
Podemos encontrarnos con la siguiente serie de incidencias de tipo lógico:
a) Fallo al utilizar algún recurso de la red:
Reinstalar el controlador del recurso.
Comprobar que el recurso está bien compartido.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Comprobar que no es necesario configurar ninguna contraseña en el driver
del recurso para poder utilizarlo. En el caso de que sí sea necesario,
comprobar que está bien configurado.
b) Fallo provocado por un atraque de seguridad:
Uso de antivirus actualizados.
Uso de cortafuegos.
Acceso a equipos protegidos por usuario y una buena contraseña.
Uso de técnicas de cifrado de dato almacenados en el equipo y de los datos
que viajan por la red.
Activación de las funciones de seguridad de los navegadores web.
Uso de protocolos de seguridad en el caso de redes inalámbricas.
También podemos encontrarnos con incidencias de tipo lógico en el uso de
programas en versiones beta o con poco tiempo de uso, bugs de fábrica,
incompatibilidades al instalar nuevas versiones, antivirus, cortafuegos mal
configurados, etc.
6.3.3. COMO ACTUAR ANTE UNA INCIDENCIA
Podemos gestionar o actuar frente a una incidencia de dos maneras diferentes:
1. De manera reactiva: proponemos una solución según el problema que
se haya dado.
2. De manera proactiva: se adelanta a todos los posibles fallos y
problemas que puedan aparecer en nuestra red, minimizando impactos:
La caída de sistemas, redes y comunicaciones.
Monitorización de puertos de nuestra red.
Gestión de Backup o copias de seguridad.
Gestión de antivirus.
Análisis del rendimiento de la red.
Gestión de actualizaciones.
Asistencia remota.
Este tipo de soporte da mayor importancia a la continuidad del servicio,
resultando el soporte más costoso, pero a la larga se ahorra, puesto que al
anticiparse al problema no hay que volver a invertir dinero en solucionarlo.
Las incidencias deben comunicarse de manera escrita. La empresa debe tener
un medio para comunicar incidencias, en este medio debe quedar constancia de
qué incidencia se ha producido, qué usuario ha dado parte sobre ella, a qué hora
se produjo la incidencia y cualquier otro detalle que se considere importante, por
ejemplo, si últimamente se ha realizado la instalación de algún software.
La tabla proporciona algunas directrices/pautas y ejemplos de preguntas para
los usuarios finales.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Preguntas de ejemplo para los usuarios
Directrices
finales
¿Qué no está funcionando?
Hacer preguntas pertinentes. ¿Cuál es exactamente el problema?
¿Qué intentas lograr?
¿A quién afecta este problema?
¿Solo a ti u otros también?
Determinar el alcance del problema. ¿En qué dispositivo está pasando
esto?
¿Cuándo se produjo exactamente el
problema?
¿Cuándo notó el problema por
Determinar cuándo y con qué frecuencia
primera vez?
ocurre u ocurrió el problema.
¿Se han mostrado mensajes de
error?
¿Puedes reproducir el problema?
Determinar si el problema es constante ¿Puedes enviarme una captura de
o intermitente. pantalla o un video del problema?
¿Qué se ha modificado desde la
Determinar si algo ha cambiado. última vez que funcionó?
Utilizar cada pregunta como un medio ¿Que está funcionando?
para eliminar o descubrir posibles ¿Qué no está funcionando?
problemas.
Es muy importante documentar la incidencia, para ello será necesario anotar el
problema que ha dado la incidencia y cómo lo hemos resuelto. Esta
documentación servirá para que, si en un futuro vuelva a ocurrir la misma
incidencia, sepamos cómo resolverla, con lo cual, habremos ganado tiempo y el
impacto de la incidencia será menor.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
También es importante comunicarle al usuario o usuarios, en el caso de que sea
una incidencia relacionada con un usuario o un grupo de usuarios, que la
incidencia se ha resuelto. De no hacerlo así, si el usuario, por ejemplo, ha tenido
un problema con la impresora, puede que no vuelva a utilizarla porque piensa que
el problema sigue ahí. Por eso es importante comunicar a los usuarios cuándo se
ha resuelto la incidencia.
Para conocer la gravedad de una incidencia, debemos medir varios factores,
todos ellos importantes:
1. El coste de reparar la incidencia. Debemos incluir aquí tanto el conste del
material nuevo, si es que hemos tenido que comprar algún dispositivo o
pieza nueva para sustituir o reparar la que no funciona, como el coste de la
persona que se ha encargado de resolverlo
2. El coste de tener parado el sistema mientras se repara la incidencia. Este
es el factor que puede pasar desapercibido, pero que es importante tener
en cuenta: debemos medir el precio que estamos pagando por tener
parado el sistema, ya sea un ordenador, un servidor, un dispositivo, etc. Lo
importante es que todo el tiempo que tengamos para el sistema nos está
generando unas pérdidas importantes para nuestra empresa, o lo que es lo
mismo, estamos dejando de recibir una serie de beneficios. Siempre
debemos procurar que el tiempo que tenemos parado un sistema en
nuestra empresa sea el menor posible.
3. El tiempo necesario para reparar la incidencia. Este factor hace referencia
al tiempo que tardamos en solucionar el problema. Para la empresa no es
lo mismo que tardemos una hora a que tardemos varios meses.
6.4. MONITORIZACION DE REDES CABLEADAS E INALÁMBRICAS
La monitorización es el proceso mediante el cual revisamos el estado de la red.
Lo ideal es hacerlo mediante un software especializado, que será mucho más
sencillo y cómodo. Comentaremos en este apartado algunos de los softwares
más utilizados para este propósito, pero antes vamos a ver cómo podemos
monitorizar la red nosotros mismos, sin ese software.
Los dispositivos de interconexión de redes suelen tener unos diodos led de
diferentes colores que nos permiten saber qué problemas podemos tener.
1. Si observamos la parte trasera de nuestro ordenador, la tarjeta de red,
podemos observar que tiene dos leds (ACT y Link), como mínimo.
- LED VERDE: Indica que la tarjeta de red recibe corriente eléctrica.
- LED NARANJA O ROJO: indica la velocidad de la actividad en la red
(envío o recepción de datos). Si la velocidad de la conexión es de 10
Mbps el led es de color naranja y si la velocidad es de 100 Mbps, el led
es de color rojo.
Estos pueden ser los problemas que se pueden presentar:
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Si no se encienden: quiere decir que el cable está roto o no está
conectado al switch.
Los dos en verde: la tarjeta, el cable y la red funcionan
correctamente.
Parpadea en verde: el tráfico que circula es normal, no hay ningún
problema.
Parpadea en verde y parpadea en naranja: colisión de paquetes,
problema de tráfico o error en la tarjeta de red.
Verde apagado y parpadea el naranja: no se está usando la red y se
ha activado el ahorro de energía.
2. En los switches, routers y demás dispositovs tenemos más luces. Vemos
cada una de ellas:
Fila de diodos Link/Act/ACTIVE/Data/LK:
- Si el led está encendido en verde fijo: no hay problema.
- Si el led está apagado: error de conexión o no tenemos el cable
conectado
Fila de diodos 10/100/1000/DUPLEX/DUPLX/SPEED (esta fila está en
equipos de gama media y alta, se reriere a la velocidad):
- En verde: está transmitiendo a la velocidad estándar.
- Si tiene los tres indicadores (10/100/1000) se encenderá el que
detecte el tráfico a esa velocidad. Si sólo existe uno, hará referencia
a la media de tráfico.
- Si parpadea: se está comunicando en modo half-duplex, semidúplex
o ahay un error en una dirección.
- Si el nombre es SPEED: la velocidad no es la adecuada.
Fila de diodos Full/Col:
- Si está en naranja: todo va bien.
- Si está en rojo: existe colisión, tráfico excesivo, tarjeta dañada o
virus.
Wireless/Wi-Fi (en algunos modelos solo tiene un color, si está apagado:
no funciona; si está encendido de forma fija: todo funciona
correctamente; si parpadea: tiene un problema o esta
reconfigurándose):
- Si está en verde: funciona correctamente o está apagado.
- Si está en rojo: no funciona o no está habilitado.
WAN/INTERNET/DSL/CaTV/FDDI (funcionamiento de Interrnet):
- Si está encendido y fijo: no hay problemas.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
- Si está apagado: no tiene conexión con el proveedor ISP o hay un
error.
- Si parpadea: se está configurando o negociando una IP con un
servidor DHCP.
Security:
- Encendido indica que se ha activado el cortafuegos, el filtrado de
paquetes o la administración local.
POWER/(ON/OFF)/PWR/READY/RD/EN (en los modelos de gama alta
existen dos indicadores):
- Si los dos indicadores está apagados: no tiene corriente
- Si los dos indicadores están en verde: todo está bien.
- Si están en verde parpadeante: se está reconfigurando, está en
modo espera o en modo ahorro de energía.
- Si parpadea en naranja: error eléctrico.
- Si parpadean los dos: se ha superado la temperatura aconsejada.
- Si está en naranja fijo: error eléctrico o de temperatura (se debe
apagar el equipo).
Todos estos indicadores son generales, son los más comunes que
podemos ver en los dispositivos que se utilizan normalmente en las redes
locales. Podemos tener algún indicador en nuestros dispositivos que no se
haya mencionado aquí o que el significado no coincida al cien por cien con lo
que aquí se ha explicado.
Como comentamos anteriormente, existen herramientas que nos
permiten monitorizar la red. Las características principales de estas
herramientas son:
Nos permiten controlar los dispositivos de manera remota y así
evitamos los desplazamientos.
Nos proporcionan información actualizada de los dispositivos que
estamos monitorizando.
Nos permiten configurar alertas para estar informados en todo
momento.
Su instalación es sencilla.
Nos permiten hacer un seguimiento del uso de cada dispositivo para
luego poder generar unas estadísticas.
Algunas de estas herramientas son: Nagios, PRTG, Hyperic HQ,
SolarWinds, ManageEngine OpManager, DataDog y Zabbix.
6.5. HERRAMIENTAS DE DIAGNÓSTICO
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Gracias a diferentes herramientas podemos averiguar las causas de los
problemas. Podemos dividir las herramientas para diagnosticar problemas en la red
en dos tipos.
6.5.1. Herramientas para detectar fallos hardware.
Dentro de este tipo de herramientas, podemos encontrar las siguientes:
Testers o comprobadores de red: estos aparatos nos permiten saber si el
cable tiene continuidad o si hay hilos cruzados.
Multímetros: nos permiten medir la continuidad de los cables. Es una
herramienta bastante rápida, pero requiere que el cable que se tiene que
comprobar no sea muy largo. Es barato.
Certificadores: estos aparatos nos dan medidas para ver el grado de
cumplimiento de los estándares. Son capaces de detectar las características
del cable, como la calidad, la longitud o la clase. Detectan atenuaciones,
impedancia, etc. Es importante que las empresas que se dedican a montar
redes cuenten con ellos para poder realizar un trabajo adecuado y fiable.
Suelen ser herramientas bastante caras.
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
6.5.2. Herramientas para detectar fallos software.
[Link]. Analizadores de red o protocolos.
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Comandos: tenemos una serie de comandos para comprobar si nuestra red está funcionando
adecuadamente. Algunos de estos comandos son:
Comando Descripción
2
Envía un paquete de solicitud de echo a una dirección y espera una
respuesta.
ping {host | ip-
La variable host o ip-address es el alias o la dirección IP del sistema
address}
objetivo.
Identifica la ruta que recorre un paquete a través de las redes.
traceroute La variable destination es el nombre de host o la dirección IP del
destination sistema objetivo.
Se conecta con una dirección IP usando la aplicación Telnet.
telnet {host |
Utiliza SSH siempre que sea posible en lugar de Telnet.
ip-address}
Se conecta a una dirección IP con SSH.
ssh -l user-id ip-
SSH es más seguro que Telnet.
address
show ip Muestra un resumen del estado de todas las interfaces en un
interface brief dispositivo.
Útil para identificar rápidamente el direccionamiento IP en todas las
show ipv6 interfaces.
interface brief
show ip route Muestra las tablas de routing IPv4 e IPv6 actuales, que contienen las
rutas a todos los destinos de red conocidos.
show ipv6 route
Muestra los protocolos configurados y muestra los valores globales
show protocols y estado específico de la interfaz de cualquier protocolo
2
RESOLUCIÓN DE INCIDENCIAS EN REDES LOCALES SMRA
Comando Descripción
configurado de Capa 3.
Muestra una lista de opciones para habilitar o deshabilitar eventos
debug de depuración.