Resolución de Problemas de Conectividad IP
Resumen
Aprenderás a solucionar problemas de una red mediante un modelo en capas. ¡¡Empieza a aprender CCNA 200-301 gratis ahora mismo!!
¡Bienvenido!: Este tema forma parte del Módulo 12 del curso de Cisco CCNA 3, para un mejor seguimiento del curso puede ir a la sección CCNA 3 para guiarte del índice.
Tabla de Contenido
1. Componentes Resolución de Problemas de Conectividad de Extremo a Extremo
En este tema se presenta una topología única y las herramientas para diagnosticar y, en algunos casos, resolver un problema de conectividad de extremo a extremo. Diagnosticar y resolver problemas es una aptitud esencial para los administradores de red. No existe una única receta para la resolución de problemas, y un problema en particular se puede diagnosticar de muchas maneras diferentes. Sin embargo, al emplear un enfoque estructurado para el proceso de resolución de problemas, un administrador puede reducir el tiempo que tarda en diagnosticar y resolver un problema.
En este tema, se usa la siguiente situación. El host cliente PC1 no puede acceder a las aplicaciones en el servidor SRV1 o el servidor SRV2. En la ilustración, se muestra la topología de esta red. PC1 utiliza SLAAC con EUI-64 para crear su dirección unicast global IPv6. EUI-64 crea el ID de la interfaz usando la dirección MAC de Ethernet, insertando FFFE en el medio e invirtiendo el séptimo bit.
Cuando no hay conectividad de extremo a extremo y el administrador elige resolver problemas con un enfoque ascendente, estos son los pasos frecuentes que el administrador puede seguir:
- Paso 1. Revisar la conectividad física en el punto donde la comunicación de la red se detiene. Esto incluye los cables y el hardware. El problema puede ser con un cable o interfaz defectuoso, o involucrar un hardware mal configurado o defectuoso.
- Paso 2. Revisar las incompatibilidades de dúplex.
- Paso 3. Revisar el direccionamiento de las capas de enlace de datos y de red en la red local. Esto incluye las tablas ARP de IPv4, las tablas de vecinos IPv6, las tablas de direcciones MAC y las asignaciones de VLAN.
- Paso 4. Verificar que el gateway predeterminado sea correcto.
- Paso 5. Asegurarse de que los dispositivos determinen la ruta correcta del origen al destino. Si es necesario, se debe manipular la información de enrutamiento.
Paso 6. Verificar que la capa de transporte funcione correctamente. También se puede usar Telnet desde la línea de comandos para probar las conexiones de la capa de transporte.
Paso 7. Verificar que no haya ACL que bloqueen el tráfico.
Paso 8. Asegurarse de que la configuración del DNS sea correcta. Debe haber un servidor DNS accesible.
El resultado de este proceso debería proveer una conectividad operativa de extremo a extremo. Si se han realizado todos los pasos sin ninguna resolución, el administrador de la red puede querer repetir los pasos anteriores o escalar el problema a un administrador más experimentado.
2. Problema de Conectividad de Extremo a Extremo: Inicio de la Resolución de Problemas
Generalmente, lo que da inicio a un esfuerzo de resolución de problemas es la detección de un problema con la conectividad de extremo a extremo. Dos de las utilidades más comunes que se utilizan para verificar un problema con la conectividad de extremo a extremo son ping y traceroute, que se muestran en la figura.
Haz clic en cada botón para revisar las utilidades ping y traceroute en IPv4 e IPv6.
Nota: El comando traceroute se realiza comúnmente cuando el comando ping falla. Si el ping tiene éxito, el comando traceroute comúnmente no es necesario porque el técnico sabe que existe la conectividad.
3. Paso 1: Verificar la Capa Física
Todos los dispositivos de red son sistemas de computación especializados. Como mínimo, estos dispositivos constan de una CPU, RAM y espacio de almacenamiento, que permiten que el dispositivo arranque y ejecute el sistema operativo y las interfaces. Esto permite la recepción y la transmisión del tráfico de la red. Cuando un administrador de red determina que existe un problema en un dispositivo determinado y que el problema puede estar relacionado con el hardware, vale la pena verificar el funcionamiento de estos componentes genéricos. Los comandos de Cisco IOS más utilizados para este propósito son show processes cpu, show memory, y show interfaces. En este tema, se analiza el comando show interfaces .
Cuando se trabajan en problemas relacionados al rendimiento y se sospecha del hardware, el comando show interfaces puede ser usado para revisar las interfaces por las que el tráfico pasa.
Consulta el resultado del comando show interfaces .
R1# show interfaces GigabitEthernet 0/0/0 GigabitEthernet0/0/0 is up, line protocol is up Hardware is CN Gigabit Ethernet, address is d48c.b5ce.a0c0(bia d48c.b5ce.a0c0) Internet address is 10.1.10.1/24 (Output omitted) Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 85 packets input, 7711 bytes, 0 no buffer Received 25 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 5 multicast, 0 pause input 10112 packets output, 922864 bytes, 0 underruns 0 output errors, 0 collisions, l interface resets 11 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out R1#
Haz clic en cada botón para obtener una explicación de la salida resaltada.
4. Paso 2: Revisar las Incompatibilidades de Dúplex
Otra causa común de los errores de interfaz es un modo de dúplex incompatible entre los dos extremos de un enlace Ethernet. Actualmente, en numerosas redes basadas en Ethernet, las conexiones punto a punto son la norma, y el uso de hubs y la operación half-duplex asociadas se están volviendo menos frecuentes. Esto significa que, en la actualidad, la mayoría de los enlaces Ethernet operan en modo full-duplex y que, si bien se consideraba que las colisiones eran normales en un enlace Ethernet, hoy en día las colisiones suelen indicar que la negociación de dúplex falló y que el enlace no opera en el modo de dúplex correcto.
El estándar Gigabit Ethernet IEEE 802.3ab exige el uso de la autonegociación para velocidad y dúplex. Además, si bien no es estrictamente obligatorio, casi todas las NIC Fast Ethernet también usan la autonegociación de manera predeterminada. En la actualidad, la práctica recomendada es la autonegociación para velocidad y dúplex.
Sin embargo, si la negociación de dúplex falla por algún motivo, podría ser necesario establecer la velocidad y el dúplex manualmente en ambos extremos. Por lo general, esto conllevaría configurar el modo dúplex en full-duplex en ambos extremos de la conexión. Si esto no funciona, es preferible ejecutar semidúplex en ambos extremos para evitar una diferencia entre dúplex.
Las pautas de configuración de dúplex incluyen:
- Se recomienda la autonegociación de velocidad y dúplex.
- Si la autonegociación falla, configurar manualmente la velocidad y el dúplex en los extremos interconectados.
- Los enlaces Ethernet de punto a punto siempre se deben ejecutar en modo full-duplex.
- El semidúplex es inusual y solo suele encontrarse cuando se usan hubs.
Ejemplo de Resolución de Problemas
En el siguiente escenario, el administrador de la red tuvo que añadir usuarios adicionales a la red. Para incorporar estos nuevos usuarios, el administrador de la red instaló un segundo switch y lo conectó al primero. Poco después de que se añadiera S2 a la red, los usuarios de ambos switches empezaron a experimentar problemas significativos de rendimiento al conectarse con los dispositivos del otro switch, como se muestra en la figura.
El administrador de red observa un mensaje de la consola en el switch S2:
*Mar 1 00:45:08.756: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/20 (not half duplex), with Switch FastEthernet0/20 (half duplex).
Mediante el comando show interfaces fa 0/20 , el administrador de red examina la interfaz en el S1 usada para conectarse al S2 y observa que está establecida en full-duplex, como se muestra en la figura.
S1# show interface fa 0/20 FastEthernet0/20 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0cd9.96e8.8a01 (bia 0cd9.96e8.8a01) MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, Auto-speed, media type is 10/100BaseTX (Output omitted) S1#
Ahora, el administrador de red examina el otro lado de la conexión: el puerto en el S2. Se muestra que este lado de la conexión se configuró como half-duplex.
S2# show interface fa 0/20 FastEthernet0/20 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0cd9.96d2.4001 (bia 0cd9.96d2.4001) MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Half-duplex, Auto-speed, media type is 10/100BaseTX (Output omitted) S2(config)# interface fa 0/20 S2(config-if)# duplex auto S2(config-if)#
El administrador de red corrige la configuración y la establece en duplex auto, para que el dúplex se negocie automáticamente. Debido a que el puerto en el S1 se establece en full-duplex, el S2 también usa full-duplex.
Los usuarios informan que ya no existe ningún problema de rendimiento.
5. Paso 3: Verificar el Direccionamiento en la Red Local
Al resolver problemas de conectividad de extremo a extremo, es útil verificar las asignaciones entre las direcciones IP de destino y las direcciones Ethernet de capa 2 en segmentos individuales. En IPv4, ARP proporciona esta funcionalidad. En IPv6, la funcionalidad de ARP se reemplaza por el proceso de detección de vecinos e ICMPv6. La tabla de vecinos almacena en caché las direcciones IPv6 y sus direcciones físicas de Ethernet (MAC) resueltas.
Haz clic en cada botón para ver un ejemplo y una explicación del comando para verificar el direccionamiento de Capa 2 y Capa 3.
6. Ejemplo de Resolución de Problemas de Asignación de VLAN
Al resolver problemas de conectividad de extremo a extremo, otro problema que se debe considerar es la asignación de VLAN. En una red conmutada, cada puerto en un switch pertenece a una VLAN. Cada VLAN se considera una red lógica independiente, y los paquetes destinados a las estaciones que no pertenecen a la VLAN se deben reenviar a través de un dispositivo que admita el enrutamiento. Si el host de una VLAN envía una trama de Ethernet de broadcast, como una solicitud de ARP, todos los host de la misma VLAN recibirán la trama; los host de otras VLAN no la recibirán. Incluso si dos hosts están en la misma red IP, no se podrán comunicar si están conectados a puertos asignados a dos VLAN separadas. Además, si se elimina la VLAN a la que pertenece el puerto, este queda inactivo. Ninguno de los hosts conectados a los puertos que pertenecen a la VLAN que se eliminó se puede comunicar con el resto de la red. Los comandos como show vlan se pueden usar para validar las asignaciones de VLAN en un switch.
Supongamos, por ejemplo, que en un esfuerzo por mejorar la gestión de cables en el armario de cableado, tu empresa ha reorganizado los cables que se conectan al switch S1. Casi inmediatamente después de hacerlo, los usuarios comenzaron a llamar al soporte técnico con el comentario de que ya no tenían posibilidad de conexión a los dispositivos fuera de su propia red.
Haz clic en cada botón para obtener una explicación del proceso utilizado para solucionar este problema.
7. Paso 4: Verificar la Puerta de Enlace Predeterminada
Si no hay una ruta detallada en el router o si el host está configurado con la puerta de enlace predeterminada incorrecta, la comunicación entre dos terminales en redes distintas no funciona.
En la figura, se muestra que la PC1 usa el R1 como puerta de enlace predeterminada. De manera similar, el R1 usa al R2 como puerta de enlace predeterminada o como gateway de último recurso. Si un host necesita acceso a recursos que se encuentran más allá de la red local, se debe configurar la puerta de enlace predeterminada. La puerta de enlace predeterminada es el primer router en la ruta a los destinos que se encuentran más allá de la red local.
Ejemplo de Resolución de problemas de puerta de enlace predeterminada IPv4
En este ejemplo, R1 tiene la puerta de enlace por defecto correcta, que es la dirección IPv4 de R2. Sin embargo, PC1 tiene la puerta de enlace por defecto incorrecta. PC1 debería tener la puerta de enlace por defecto de R1 10.1.10.1. Esta debe ser configurada manualmente si la información de dirección IPv4 fue configurada manualmente en PC1. Si la información de direcciones IPv4 se obtuvo automáticamente de un servidor DHCPv4, entonces se debe examinar la configuración en el servidor DHCP. Un problema de configuración en un servidor DHCP suele afectar a varios clientes.
Haz clic en cada botón para ver la salida del comando para R1 y PC1.
8. Ejemplo de Solución de Problemas de Puerta de Enlace Predeterminada de IPv6
En IPv6, la puerta de enlace por defecto puede ser configurada manualmente, usando la autoconfiguración sin estado (SLAAC), o usando DHCPv6. Con SLAAC, la puerta de enlace por defecto es anunciada por el router a los hosts usando mensajes Router Advertisement (RA) ICMPv6. La puerta de enlace por defecto en el mensaje RA es la dirección IPv6 de la interfaz del router. Si la puerta de enlace por defecto se configura manualmente en el host, lo cual es muy poco probable, la puerta de enlace por defecto se puede configurar a la dirección IPv6 global o a la dirección IPv6 link-local.
Haz clic en cada botón para ver un ejemplo y una explicación de cómo solucionar un problema de puerta de enlace predeterminada IPv6.
- Tabla Routing R1
- Direccionamiento PC1
- Revisar Configuración de Interfaz de R1
- Enrutamiento IPv6 en R1 Correcto
- Verificar que PC1 tiene Gateway Predeterminado IPv6
Como se muestra en la salida del comando, el comando show ipv6 route del Cisco IOS se utiliza para comprobar la ruta predeterminada IPv6 en R1. R1 tiene una ruta predeterminada a través de R2.
R1# show ipv6 route (Output omitted) S ::/0 [1/0] via 2001:DB8:ACAD:2::2 R1#
El comando ipconfig de Windows, se utiliza para comprobar que un PC1 tiene una puerta de enlace predeterminada IPv6. En el resultado del comando, a PC1 le falta una dirección unicast global IPv6 y una puerta de enlace predeterminada IPv6. La PC1 está habilitada para IPv6 debido a que tiene una dirección IPv6 link-local. El dispositivo crea automáticamente la dirección link-local. Al revisar la documentación de red, el administrador de red confirma que los hosts en esta LAN deberían recibir la información de dirección IPv6 del router que usa SLAAC.
Nota: En este ejemplo, otros dispositivos que usen SLAAC en la misma LAN también experimentarían el mismo problema al recibir la información de dirección IPv6.
C:\> ipconfig Windows IP Configuration Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . : fe80::5075:d0ff:fe8e:9ad8%13 IPv4 Address . . . . . . . . . . : 10.1.10.10 Subnet Mask . . . . . . . . . . : 255.255.255.0 Default Gateway. . . . . . . . . : 10.1.10.1 C:\>
La salida del comando show ipv6 interface GigabitEthernet 0/0/0 en R1 revela que aunque la interfaz tiene una dirección IPv6, no es miembro del grupo multicast All-IPv6-Routers FF02::2. Esto significa que el router no está habilitado como router IPv6. Por eso no envía RA de ICMPv6 en esta interfaz.
R1# show ipv6 interface GigabitEthernet 0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::1
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:ACAD:1::1, subnet is 2001:DB8:ACAD:1::/64
Joined group address(es):
FF02:: 1
FF02::1:FF00:1
(Output omitted)
R1#
R1 está habilitado como un router IPv6 mediante el comando ipv6 unicast-routing . El comando show ipv6 interface GigabitEthernet 0/0/0 verifica que R1 sea miembro de ff02::2, el grupo multicast All-IPV6-Routers.
R1(config)# ipv6 unicast-routing
R1(config)# exit
R1# show ipv6 interface GigabitEthernet 0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::1
No Virtual link-local address(es):
Global unicast address(es):
2001:DB8:ACAD:1::1, subnet is 2001:DB8:ACAD:1::/64
Joined group address(es):
FF02:: 1
FF02:: 2
FF02::1:FF00:1
(Output omitted)
R1#
Para verificar que la PC1 tenga configurado la puerta de enlace predeterminada, usa el comando ipconfig en la PC con Microsoft Windows o el comando ifconfig en Linux y Mac OS X. La PC1 tiene una dirección IPv6 unicast global y una puerta de enlace predeterminado IPv6. La puerta de enlace predeterminada se configura en la dirección link-local del router R1, FE80::1.
C:\> ipconfig
Windows IP Configuration
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . : 2001:db8:acad:1:5075:d0ff:fe8e:9ad8
Link-local IPv6 Address . . . . : fe80::5075:d0ff:fe8e:9ad8%13
IPv4 Address . . . . . . . . . . : 10.1.10.10
Subnet Mask . . . . . . . . . . : 255.255.255.0
Default Gateway. . . . . . . . . : fe80::1
10.1.10.1
C:\>
9. Paso 5: Verificar la Ruta Correcta
Al resolver problemas, con frecuencia es necesario verificar la ruta hacia la red de destino. En la figura, se muestra la topología de referencia que indica la ruta deseada para los paquetes de la PC1 al SRV1.
Los routers de la ruta toman la decisión de enrutamiento basándose en la información de las tablas de enrutamiento. Haz clic en cada botón para ver las tablas de enrutamiento IPv4 e IPv6 para R1.
Las tablas de enrutamiento IPv4 e IPv6 se pueden llenar con los siguientes métodos:
- Redes conectadas directamente
- Hosts locales o rutas locales
- Rutas estáticas
- Rutas dinámicas
- Rutas predeterminadas
El proceso de reenvío de paquetes IPv4 e IPv6 se basa en la coincidencia más larga de bits o de prefijos. El proceso de la tabla de enrutamiento intenta reenviar el paquete mediante una entrada en la tabla de enrutamiento con el máximo número de bits coincidentes en el extremo izquierdo. La longitud de prefijo de la ruta indica el número de bits coincidentes.
La figura describe el proceso de las tablas de enrutamiento IPv4 e IPv6.
Examina los siguientes escenarios basados en el diagrama de flujo anterior. Si la dirección de destino en un paquete:
- No coincide con una entrada en la tabla de rutas, entonces se utiliza la ruta por defecto. Si no hay una ruta por defecto que esté configurada, el paquete se descarta.
- Coincide con una sola entrada en la tabla de enrutamiento, entonces el paquete se reenvía a través de la interfaz que se define en esta ruta.
- Coincide con más de una entrada en la tabla de enrutamiento y las entradas de enrutamiento tienen la misma longitud de prefijo, entonces los paquetes para este destino pueden ser distribuidos entre las rutas que están definidas en la tabla de enrutamiento.
- Coincide con más de una entrada en la tabla de enrutamiento y las entradas de enrutamiento tienen diferentes longitudes de prefijo, entonces los paquetes para este destino son reenviados fuera de la interfaz que está asociada con la ruta que tiene la coincidencia de prefijo más larga.
Ejemplo de resolución de problemas
Los dispositivos no se pueden conectar al servidor SRV1 en 172.16.1.100. Mediante el comando show ip route, el administrador debe revisar si existe una entrada de enrutamiento para la red 172.16.1.0/24. Si la tabla de enrutamiento no tiene una ruta específica a la red del SRV1, el administrador de la red debe entonces comprobar la existencia de una entrada de ruta por defecto o resumida en dirección a la red 172.16.1.0/24. Si no existe ninguna, entonces el problema puede estar en el enrutamiento y el administrador debe verificar que la red está incluida en la configuración del protocolo de enrutamiento dinámico o añadir una ruta estática.
10. Paso 6: Verificar la Capa de Transporte
Si la capa de red parece funcionar como se esperaba, pero los usuarios aún no pueden acceder a los recursos, el administrador de red debe comenzar a resolver problemas en las capas superiores. Dos de los problemas más frecuentes que afectan la conectividad de la capa de transporte incluyen las configuraciones de ACL y de NAT. Una herramienta frecuente para probar la funcionalidad de la capa de transporte es la utilidad Telnet.
Precaución: Si bien se puede usar Telnet para probar la capa de transporte, por motivos de seguridad se debe usar SSH para administrar y configurar los dispositivos en forma remota.
Ejemplo de resolución de problemas
Un administrador de red está solucionando un problema en el que no puede conectarse a un router mediante HTTP. El administrador hace ping R2 como se muestra en la salida del comando.
R1# ping 2001:db8:acad:2::2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:2::2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms R1#
R2 responde y confirma que la capa de red y todas las capas debajo de la capa de red están operativas. El administrador sabe que el problema está en la capa 4 o en las capas superiores y que debe comenzar a resolver problemas en esas capas.
A continuación, el administrador verifica que pueden hacer Telnet a R2 como se muestra en el ejemplo.
R1# telnet 2001:db8:acad:2::2 Trying 2001:DB8:ACAD:2::2 ... Open User Access Verification Password: R2> exit [Connection to 2001:db8:acad:2::2 closed by foreign host] R1#
El administrador ha confirmado que los servicios de Telnet están funcionando en R2. Aunque la aplicación de servidor Telnet se ejecuta en su propio y conocido puerto 23 y los clientes Telnet se conectan a este puerto por defecto, se puede especificar un número de puerto diferente en el cliente para conectarse a cualquier puerto TCP que deba ser probado. El uso de un puerto diferente al puerto TCP 23 indica si la conexión es aceptada (como se indica con la palabra “Open” en la salida), rechazada (refused) o agotada (times out). A partir de cualquiera de esas respuestas, se pueden sacar más conclusiones sobre la conectividad. Ciertas aplicaciones, si utilizan un protocolo de sesión basado en ASCII, pueden incluso mostrar un banner de la aplicación, puede ser posible desencadenar algunas respuestas del servidor escribiendo ciertas palabras clave, como con SMTP, FTP y HTTP.
Por ejemplo, el administrador intenta Telnet a R2 usando el puerto 80.
R1# telnet 2001:db8:acad:2::2 80 Trying 2001:DB8:ACAD:2::2, 80 ... Open ^C HTTP/1.1 400 Bad Request Date: Mon, 04 Nov 2019 12:34:23 GMT Server: cisco-IOS Accept-Ranges: none 400 Bad Request [Connection to 2001:db8:acad:2::2 closed by foreign host] R1#
Una vez más, en el resultado se verifica una conexión correcta de la capa de transporte, pero R2 rechaza la conexión mediante el puerto 80.
11. Paso 7: Verificar las ACL
En los routers, puede haber ACL configuradas que prohíben a los protocolos atravesar la interfaz en sentido entrante o saliente.
Usa el comando show ip access-lists para visualizar el contenido de todas las ACL de IPv4 y el comando show ipv6 access-list para visualizar el contenido de todas las ACL de IPv6 configuradas en un router. Se puede visualizar una ACL específica al introducir el nombre o el número de la ACL, como una opción de este comando. Los comandos show ip interfaces y show ipv6 interfaces muestran la información de interfaz IPv4 e IPv6 que indica si hay alguna ACL de IP establecida en la interfaz.
Ejemplo de resolución de problemas
Para prevenir los ataques de suplantación de identidad, el administrador de red decidió implementar una ACL para evitar que los dispositivos con la dirección de red de origen 172.16.1.0/24 ingresen a la interfaz de entrada S0/0/1 en el R3, como se muestra en la figura. Todo el resto del tráfico IP debe ser permitido.
Sin embargo, poco después de implementar la ACL, los usuarios en la red 10.1.10.0/24 no podían conectarse a los dispositivos en la red 172.16.1.0/24, incluido el SRV1.
Haz clic en cada botón para ver un ejemplo de cómo solucionar este problema.
12. Paso 8: Verificar DNS
El protocolo DNS controla el DNS, una base de datos distribuida mediante la cual se pueden asignar nombres de host a las direcciones IP. Cuando configuras DNS en el dispositivo, puedes reemplazar el nombre de host por la dirección IP con todos los comandos IP, como ping o telnet.
Para visualizar la información de configuración de DNS en el switch o el router, utiliza el comando show running-config . Cuando no hay instalado un servidor DNS, es posible introducir asignaciones de nombres a direcciones IP directamente en la configuración del switch o del router. Utiliza el comando ip host para introducir un nombre que se utilizará en lugar de la dirección IPv4 del switch o router, como se muestra en el ejemplo.
R1(config)# ip host ipv4-server 172.16.1.100 R1(config)# exit R1#
Ahora se puede utilizar el nombre asignado en lugar de utilizar la dirección IP, como se muestra en el ejemplo.
R1# ping ipv4-server Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.100, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/7 ms R1#
Para mostrar la información del mapeo de nombre a dirección IP en un PC con Windows, utiliza el comando nslookup.
13. Packet Tracer – Resolución de Problemas de Redes Empresariales
Esta actividad aplica una variedad de tecnologías que has visto durante tus estudios de CCNA, incluido el enrutamiento, la seguridad de puertos, EtherChannel, DHCP, NAT, Tu tarea consiste en revisar los requisitos, aislar y resolver cualquier problema, y luego documentar los pasos que tomaste para verificar los requisitos.
Glosario: Si tienes dudas con algún término especial, puedes consultar este diccionario de redes informáticas.
¡Listo! Sigue visitando nuestro blog de curso de redes, dale Me Gusta a nuestra fanpage; y encontrarás más herramientas y conceptos que te convertirán en todo un profesional de redes.
