Hoy analizaremos 3 conceptos: el protocolo propietario CDP de Cisco, el registro del sistema Syslog y el protocolo de tiempo de red NTP. También continuaremos discutiendo el tema de los problemas y veremos algunas herramientas para diagnosticarlos, luego veremos Syslog y NTP y al final de la lección discutiremos CDP y LLDP.
En la lección anterior, analizamos la metodología de solución de problemas, y ahora hablaré sobre varias herramientas integradas en el sistema operativo y los dispositivos Cisco que lo ayudarán a resolver problemas de red.
La primera herramienta es el comando ipconfig, y dado que la mayoría de las personas usan Windows 10, veremos este comando usando este sistema operativo como ejemplo. Si va al terminal de línea de comando de su computadora e ingresa el comando ipconfig, puede ver los parámetros de configuración de todas las interfaces de red disponibles en su computadora.

Verá una interfaz virtual de software Adaptador Ethernet VPN y varias interfaces de software más, cuyo número depende de los controladores disponibles en el sistema. Aquí se muestra mi adaptador de LAN inalámbrica Wi-Fi, con el que ahora estoy conectado a Internet, los datos en el adaptador virtual WMware Network WMnet1 se encuentran un poco más arriba. El adaptador de túnel se muestra a continuación, es decir, todos los adaptadores instalados por el software VPN se muestran aquí.
El tema del curso CCNA requiere que conozca dos adaptadores: un adaptador inalámbrico Wi-Fi y un adaptador Ethernet.

Para una red de oficina, el adaptador inalámbrico es más importante, y si alguno de los usuarios se contacta con usted por un problema, primero debe usar el comando ipconfig y mirar la dirección IP del dispositivo. Debe verificar si esta dirección está en el rango de direcciones DHCP. Quizás el usuario apagó la dinámica y activó la IP estática, que no forma parte de DHCP, o el dispositivo está configurado para obtener automáticamente una dirección IP y, por alguna razón, no puede contactar al servidor DHCP.
Si necesita información más completa, use el comando ipconfig / all. Recibirá los mismos datos, pero de forma más detallada, con la descripción de la marca del adaptador, los parámetros de DHCP, la dirección local de enlace, la dirección IP, el período de validez del contrato de arrendamiento del servidor, la dirección de puerta de enlace predeterminada, etc.

Si, como resultado de verificar esta información, resulta que todo está bien con la dirección IP y la configuración de la interfaz no es la causa del problema, debe usar otras herramientas de diagnóstico, como NSLookup. Esta es una utilidad que le permite acceder al sistema DNS a través de la línea de comando. Si esto no resuelve el problema, use ping. Uso el comando ping 8.8.8.8, es decir, hago ping al DNS público de Google. Si el ping pasa, entonces todo está en orden con la conexión y la razón debe buscarse en otro lugar.
Si el ping no pasa, debe usar una herramienta llamada Trace Route o tracert. Este es un comando de Windows para rastrear la ruta a un host determinado. Si escribe tracert 8.8.8.8 en la línea de comando, obtendrá ping con un valor de TTL = 1 con un rastreo de ruta de hasta 30 nodos. Como puede ver, el primer nodo es mi enrutador, el sistema mostró su firmware DD-WRT y la dirección IP 192.168.1.1, el segundo es el servidor de mi proveedor con la dirección IP 192.168.100.1, con la que voy a Internet, luego pings en otros nodos y llega al servidor de Google. En nuestro caso, resultó 14 esperanzas, pero si, por ejemplo, surgió un problema por parte de mi proveedor, entonces el seguimiento se detendrá después del tercer nodo que caracteriza el servidor ISP.

Por lo tanto, Trace Route es una excelente herramienta para identificar problemas a lo largo de la ruta del tráfico.
Echemos un vistazo más de cerca a lo que es NSLookup. Este es un comando que habla sobre su servidor DNS. Si escribe nslookup, obtengo dos líneas: el servidor predeterminado es DD-WRT, es decir, mi enrutador, y su dirección es 192.168.1.1. Si especifico un servidor DNS específico con el comando del servidor 8.8.8.8, el sistema me dará su descripción y dirección IP. De esta manera puede verificar cualquier servidor DNS dado. Del mismo modo, puedo obtener datos sobre un dominio específico escribiendo, por ejemplo,
www.cisco.com .

Como puede ver, Cisco usa dos versiones de la dirección IP, y si escribo google.com, veremos muchas direcciones IP utilizadas por este servidor. Este es un servicio enorme al que acceden tantas personas que una sola dirección IP puede no ser suficiente.

Hay una broma que dice que cuando las personas quieren saber si Internet funciona, simplemente escriben google.com. Además de los usuarios de PC, los propietarios de teléfonos inteligentes con Android acceden constantemente a este servicio, por lo que simplemente hay un enorme tráfico que pasa por los servidores de esta empresa.
Por lo tanto, el comando nslookup le permite encontrar la dirección IP de un nombre de dominio específico. Todas las herramientas mencionadas anteriormente no solucionan los problemas, pero sirven para diagnosticarlos. Cuanto más practique en la industria de TI, más eficazmente podrá utilizar estas herramientas, porque solo la práctica y la experiencia pueden enseñarle a diagnosticar y solucionar rápidamente los problemas de la red. La práctica le dará la oportunidad de comprender cuál es el problema, de un vistazo a la configuración de red de la consola de la computadora. Por lo tanto, después de completar el estudio del tema de ICND1, publicaré el trabajo práctico de laboratorio en el sitio para que pueda aplicar el conocimiento de la teoría.
Antes de hablar sobre el syslog, quiero hablar sobre el comando Terminal Monitor del sistema operativo Cisco IOS. Entraré en el programa Packet Tracer (si aún no lo ha instalado, puede registrarse en Network Academy y descargar este programa), tomar dos enrutadores y conectarlos con un cable.
Luego iré al modo de configuración global y me turno para configurar estos enrutadores, dándoles los nombres R0 y R1.

Luego, en la configuración R1, ingresaré el comando enable password enable para establecer la contraseña y configurar la interfaz g0 / 0 usando ip add 10.1.1.2 255.255.255.0 y sin comandos de apagado. Del mismo modo, configuraré el enrutador R0 asignándole la dirección IP 10.1.1.1. Luego activo el protocolo Telnet con el comando line vty 0 4 y configuro la contraseña para ingresar a Telnet con los comandos telnet de inicio de sesión y contraseña. A continuación, iré a la configuración de R0 y usaré el comando telnet 10.1.1.2 para establecer una conexión con el enrutador R1. Después de eso, el sistema solicitará una contraseña para establecer una conexión e ingresaré la palabra telnet, que configuré como contraseña para R1. Como puede ver, después de eso, en la línea de comando, el nombre del enrutador R0 cambió a R1; esto significa que pasé por el enrutador R0 a la configuración del enrutador R1.

Ahora pasemos a la interfaz g0 / 1 y le mostraré un par de cosas. Primero, uso el comando no shut para ello. Verá que el mensaje de registro apareció en la ventana CLI del segundo enrutador, que el estado de la interfaz g0 / 1 ha cambiado a arriba.

Desde que ingresé la configuración R1 desde el enrutador R0, resultó que había conectado una computadora portátil normal al segundo enrutador con un cable y lo controlé de forma remota. Sin embargo, este mensaje de registro apareció solo en la ventana R1, porque estaba conectado al segundo enrutador solo a través del canal Telnet y no estaba duplicado en la ventana CLI del primer enrutador. El hecho es que si ingresó de forma remota la configuración de un dispositivo ubicado, por ejemplo, en otro edificio, de manera predeterminada, los mensajes de registro de este dispositivo no se mostrarán en su pantalla.
Para que estos mensajes de registro se muestren en la pantalla de su dispositivo, debe usar el comando de monitor de terminal. De hecho, significa que si aparecen mensajes de registro de eventos en la pantalla de otro dispositivo, deben enviarse en forma de paquetes a través del protocolo Telnet a la dirección IP de su dispositivo. Por defecto, los mensajes de registro no se envían a la dirección IP, pero después de ingresar el comando de monitor de terminal, esto comenzará a suceder. Si ahora ingreso el comando de apagado en la ventana de configuración del enrutador R1, aparecerá un mensaje de registro sobre el cambio del estado de la interfaz simultáneamente en ambas pantallas.

Ahora iré al modo de configuración global R1 en la primera ventana y comenzaré a escribir algún comando, por ejemplo, int g0 / 0. Supongamos que logré imprimir solo int g0 /, y en ese momento apareció algún tipo de mensaje de registro. Mi equipo se romperá en pedazos por este mensaje, por lo que 0 estará en la siguiente línea y el dispositivo puede no entenderlo. Esto es especialmente inconveniente si escribo un comando largo o si los mensajes de registro consisten en muchas líneas, porque no sabré dónde dejar de escribir para que mi equipo no se rompa en pedazos, o puedo olvidar dónde lo dejé.

Para evitar esto, se utiliza la sincronización de registros. Escribo el comando line vty 0 4 en la ventana derecha para ir a la configuración de Telnet, después de lo cual el encabezado de la línea de comando cambia de R1 (config-if) a R1 (config-line). Luego ingreso el comando síncrono de registro y regreso a la ventana izquierda.
Ahora repito la misma situación: escriba int g0 / y pause, durante el cual el mensaje de registro aparece nuevamente. También aparece en ambas pantallas, pero ahora su texto no interrumpe mi comando, y debajo solo repite lo que comencé a escribir. Ahora puedo continuar tranquilamente escribiendo el equipo que comencé, sin temor a que los registros que aparezcan lo dividan en pedazos. Para mí, como usuario, esto es muy conveniente, ya que no necesita pensar cómo escribir un comando más rápido, hasta que de repente aparece un mensaje de registro de eventos. Esto es lo que hace el comando síncrono de registro, o "sincronizar registros".

Cada uno de los mensajes de registro tiene un cierto nivel de prioridad, en nuestro ejemplo es el nivel 5. Cuanto menor sea el valor del nivel de registro, más importante será el mensaje. Hay 8 niveles de prioridad de registros de Cisco en total.

0 - emergencia, el sistema no está completamente operativo,
1 - una situación alarmante, es necesaria una intervención urgente,
2 - eventos críticos, el sistema puede fallar,
3 - mensajes de error,
4 - todo tipo de advertencias
5 - varias notificaciones importantes,
6 - mensajes informativos,
7 - mensajes de depuración.
Los primeros tres niveles informan condiciones peligrosas del sistema, el nivel 3 indica problemas en el sistema, el cuarto nivel advierte que el estado del sistema puede volverse inestable, pero aún funciona. El nivel 5 notifica sobre varios eventos, por ejemplo, sobre un cambio en el estado del enlace, como en nuestro ejemplo. Si usa el modo de depuración, la pantalla mostrará mensajes de depuración del 7º nivel. Si es una persona ocupada y no desea leer todos los registros, puede elegir qué nivel de mensajes de peligro se mostrarán en la pantalla.
Por ejemplo, quiero ver solo mensajes de registro hasta el 3er nivel de peligro. En este caso, el sistema solo mostrará mensajes de los niveles 0, 1, 2 y 3, ignorando los mensajes de los niveles 4-7. De forma predeterminada, el nivel 7 está configurado, por lo que verá los registros de todos los niveles, desde cero hasta séptimo.
Examinamos qué es el monitor de Terminal, y ahora pasemos a Syslog. Si aparecen mensajes de registro importantes en su pantalla, es posible que desee guardarlos de alguna manera en el servidor Syslog, porque generalmente estos mensajes se almacenan solo en la memoria del enrutador y no podrá analizarlos después de un tiempo.
Volvamos a Packet Tracer y agreguemos un servidor al circuito que está conectado directamente al primer enrutador. En la práctica, el interruptor debe ubicarse entre ellos, pero usamos este esquema con fines de capacitación, por lo que podemos prescindir del interruptor. Entro en la configuración de red del servidor y le asigno una dirección IP estática 10.1.2.10, una máscara de subred de 255.255.255.0 y una dirección de puerta de enlace predeterminada de 10.1.2.1. Esta dirección aún no existe, pero la configuraré cuando proceda a configurar la interfaz del enrutador R0.
A continuación, iré a la configuración de R0, usaré el comando g0 / 1 y le asignaré la dirección 10.1.2.1 con una máscara de subred de 255.255.255.0. Por lo tanto, el servidor y el enrutador estarán en la misma red. Luego necesito entrar en la configuración del segundo enrutador R1 y configurar la conexión con el primer enrutador. Puede configurar un RIP o una ruta estática, en este caso elijo el último.
Para hacer esto, ingreso el comando ip route 0.0.0.0 0.0.0.0 10.1.1.1, es decir, indico que todo el tráfico se envía a la dirección 10.1.1.1. Luego ingreso do show ip route y veo que la puerta de enlace de la última cola Gateway de último recurso tiene la dirección 10.1.1.1 para la red 0.0.0.0.
Ahora comprobaré si es posible hacer ping al dispositivo en 10.1.2.10. Si recuerda, el ping es una herramienta de diagnóstico y, como puede ver, el ping fue exitoso. A continuación, enciendo el modo de depuración con el comando debug ip icmp, esto significa que cada vez que suena el enrutador, aparecerá un mensaje correspondiente en la ventana de la consola.
Si hago ping R1 desde el enrutador izquierdo R0 usando el comando ping 10.1.1.2, aparecerán mensajes de registro en la ventana CLI del enrutador derecho, por defecto, nivel de prioridad 7. Quiero que cualquier mensaje de registro que aparezca durante el proceso de configuración se envíe al servidor Syslog. Para hacer esto, voy a la pestaña Servicios del panel de configuración del servidor y veo que el parámetro Syslog está habilitado de forma predeterminada. Bueno, ahora tengo que decirle a R1: "cada vez que aparezca un mensaje de registro, ¡envíelo al servidor Syslog en 10.1.2.10!". Para hacer esto, ingreso el comando logging 10.1.2.10. Ahora todos los mensajes de registro se enviarán al servidor. Veamos cómo sucede esto.
Entro en la configuración de R0 y nuevamente hago ping al enrutador R1. En la ventana CLI del servidor correcto, aparece el mensaje de depuración, que debe reenviarse al servidor Syslog. Voy a la pestaña Syslog del servidor y veo que todos estos mensajes aparecieron allí.

Por lo tanto, si se produjo algún evento durante el fin de semana, luego de haber venido a trabajar el lunes, podrá ver todos los mensajes de registro en los que se registran estos eventos. Si tiene algún problema, puede analizar lo que sucedió y aplicar medidas para eliminarlo.
Sin embargo, si observa de cerca los mensajes de Syslog, verá un error: todos tienen una marca de tiempo el 1 de enero de hora cero. Esto significa que no puedo saber cuándo sucedieron realmente los eventos grabados. Esto sucedió porque el reloj del sistema del enrutador R1 muestra la hora incorrecta. Si ingreso el comando show clock en la configuración de este enrutador, veré el mensaje 0: 26: 9.539 UTC del 1 de marzo de 1993. Esto significa que han pasado 26 minutos y 9 segundos desde que se encendió el enrutador, y el reloj predeterminado comienza a contar desde el 1 de marzo de 1993 años
Puedo configurar manualmente la hora correcta y comenzar a hacerlo con el enrutador R0. Entro en el comando de configuración del reloj y luego configuro la hora correcta en el formato hh: mm: ss. Después de ingresar 22:05:00, el sistema da un mensaje para ingresar el día del mes del 1 al 31 y el nombre del mes. Estoy imprimiendo el 14 de marzo y ahora debería ingresar el año en el rango de 1993 a 2035. Como resultado, escribo la línea 22:05:00 del 14 de marzo de 2017, después de lo cual presiono Enter. Si ahora escribe show clock, el sistema mostrará la hora correcta.

Puede preguntar por qué configuré la hora en el enrutador R0 y no en R1. Esto se debe a que quiero mostrarle la configuración de hora automática del segundo enrutador. Luego, ingreso los comandos debug ip icmp y logging 10.1.2.10 en la configuración R0 para que los registros se envíen al servidor Syslog.
Luego deshabilito la depuración del enrutador R1 con el comando un all y hago ping al dispositivo 10.1.1.1. El ping es exitoso, y si ahora mira los registros del servidor, puede ver que se han agregado nuevos mensajes aquí, pero por alguna razón nuevamente con la hora incorrecta y la fecha cero. Esto es extraño, porque la hora correcta también se muestra en la configuración del enrutador R1. Vuelvo a hacer ping al enrutador R0 desde el enrutador R1, los mensajes de registro aparecen en la pantalla y en el registro del servidor, pero nuevamente con la fecha incorrecta. Probablemente la información aún no se haya actualizado, y trataré de averiguar por qué.
Voy a la configuración del enrutador R0 y apago los mensajes de depuración con el comando un all, después de lo cual voy a la configuración del enrutador R1 e ingreso el comando de marcas de tiempo del servicio, que pone una marca de tiempo en los mensajes de depuración o mensajes de registro. En nuestro caso, utilizo las marcas de tiempo del servicio de registro de fecha y hora ms.
Luego vuelvo a la configuración de R0 y hago ping a R1. Ahora verá que los mensajes aparecieron en el servidor con la fecha y la hora: 1 de marzo, 00:31:02 con milisegundos. ¡Pero esta es la fecha incorrecta, ya que no fijé el 1 de marzo, sino el 14 de marzo! Pido disculpas por cometer errores en este video tutorial, ahora los arreglaré.
Intentaré configurar la hora correcta de una manera diferente. El hecho es que hasta que activé el servicio de sello de tiempo, los mensajes llegaron con la hora y fecha predeterminadas. Luego activé el servicio de marcas de tiempo, pero después de eso no configuré la hora y fecha correctas, por lo que la marca de tiempo en los mensajes de registro resultó ser incorrecta.
El problema con la configuración manual de la hora es que si tiene cientos de dispositivos, debe ir a la configuración de cada dispositivo y configurar la hora y la fecha. Para evitar esto, existe un mecanismo automático de NTP, o protocolo de tiempo de red, que sincroniza la hora de una computadora con la hora de los dispositivos de red. Puede seleccionar un dispositivo de red como maestro NTP y configurar el tiempo deseado. Estudiar este protocolo está más allá del alcance del curso CCNA, y no estoy seguro de que el comando maestro ntp sea compatible con Packet Tracer. Pero todavía trato de establecer la hora correcta, para lo cual agregaré otro servidor a nuestra red y le asignaré un servidor NTP.
Para hacer esto, entraré en su configuración y comprobaré la pestaña NTP. Como puede ver, la fecha y la hora correctas se configuran aquí y la función NTP está habilitada.

Luego entro en la configuración de red del Servidor1 y le asigno una dirección IP 10.1.3.10, una máscara de subred de 255.255.255.0 y una puerta de enlace predeterminada de 10.1.3.1. Como mencioné anteriormente, esta puerta de enlace no está configurada, por lo que entro en la configuración del enrutador R1 y configuro la interfaz g0 / 1 para comunicarse con el servidor emitiendo ip add 10.1.3.1 255.255.255.0 y sin comandos de apagado.
A continuación, en la configuración del enrutador, ingreso el comando ntp server 10.1.3.10, después de lo cual el enrutador R1 podrá recibir la hora correcta del servidor NTP. Como puede ver, ahora tenemos mensajes de registro de nivel 5 con la marca de tiempo correcta.

show clock, , . ntp association, , Packet Tracer, ntp.

ntp status , . , Stratum 2 – , NTP-, R2 , 1. , R1, stratum 3 (NTP- + R1 + ), R1 NTP- 2. , .
R0 R1 10.1.1.2, , Server0 , .

, NTP Syslog. – CDP, Cisco Discovery Protocol. .
, , , , . Cisco, , , IP-. , LLDP, Link Layer Discovery Protocol, , CDP, .
CDP Cisco . LLDP, Cisco . , LLDP, Cisco, CDP.
, , Packet Tracer. , , CDP , Server0 R0. , , .
CLI R0 show cdp. , cdp- 60 , 180 , – CDPv2.

CDP , , , . 60 . show cdp neighbors, , R0 CDP-.

, R0 – R1 . R1 R 1900 R0 g0/0, g0/0 R0.
, show cdp neighbors , , , . , .
R0 – 2960, g0/1. , , , , , Capability, : R – , S – , H- .. R0 FastEthernet 0/1.
, CDP . , , – CDP . , , . CDP? config t cdp run. , cdp . cdp no cdp run. , cdp, show cdp – , CDP is not enable.
, cdp , . , , cdp cdp run, , , int g0/1, cdp enable, , no cdp enable, . no cdp enable cdp , . , / cdp run, – enable.
show cdp neighbors, , R0 – R1. cdp g0/1, «».
LLDP , CDP, lldp run/no lldp run. , Cisco CDP , LLDP – . LLDP , , g0/1, lldp receive, , lldp transmit, LLDP -.
, no lldp receive, – no lldp transmit. CDP LLDP , , – , LLDP -.
Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato? ¡Solo tenemos
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre
Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?