Resolución de Problemas de Conectividad IP CCNA
Resolución de Problemas de Conectividad IP CCNA

Resolución de Problemas de Conectividad IP

Resolución de Problemas de Conectividad IP
3

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.

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.

Topología Resolución de Problemas Red
Topología Resolución de Problemas Red

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.

Problema de Conectividad de Extremo a Extremo
Problema de Conectividad de Extremo a Extremo

Haz clic en cada botón para revisar las utilidades ping y traceroute en IPv4 e IPv6.

Es probable que ping sea la utilidad de prueba de conectividad más popular en el ámbito de la tecnología de redes y siempre formó parte del software IOS de Cisco. Esta herramienta envía solicitudes de respuesta desde una dirección host especificada. El comando ping usa un protocolo de capa 3 que forma parte de la suite TCP/IP llamado ICMP. Ping usa la solicitud de echo ICMP y los paquetes de respuesta de echo ICMP. Si el host en la dirección especificada recibe la solicitud de echo ICMP, responde con un paquete de respuesta de echo ICMP. Se puede usar ping para verificar la conectividad de extremo a extremo tanto en IPv4 como en IPv6. Se muestra un ping satisfactorio de la PC1 al SRV1, en la dirección 172.16.1.100.

C:\> ping 172.16.1.100
Pinging 172.16.1.100 with 32 bytes of data:
Reply from 172.16.1.100: bytes=32 time=199ms TTL=128
Reply from 172.16.1.100: bytes=32 time=193ms TTL=128
Reply from 172.16.1.100: bytes=32 time=194ms TTL=128
Reply from 172.16.1.100: bytes=32 time=196ms TTL=128
Ping statistics for 172.16.1.100:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 193ms, Maximum = 199ms, Average = 195ms
C:\>

Al igual que el comando ping, el comando traceroute de Cisco IOS se puede utilizar tanto para IPv4 como para IPv6. El comando tracert se usa con el sistema operativo Windows. El rastreo genera una lista de saltos, direcciones IP de router y la dirección IP de destino final a las que se llega correctamente a través de la ruta. Esta lista proporciona información importante sobre la verificación y la resolución de problemas. Si los datos llegan al destino, el rastreo indica la interfaz de cada router de la ruta. Si los datos fallan en algún salto de la ruta, se conoce la dirección del último router que respondió al rastreo. Esta dirección es un indicio de dónde se encuentran el problema o las restricciones de seguridad.

El ejemplo tracert muestra la ruta que los paquetes IPv4 toman para llegar al destino.

C:\> tracert 172.16.1.100
Tracing route to 172.16.1.100 over a maximum of 30 hops:
  1     1 ms    <1 ms    <1 ms  10.1.10.1
  2     2 ms     2 ms     1 ms  192.168.1.2
  3     2 ms     2 ms     1 ms  192.168.1.6
  4     2 ms     2 ms     1 ms  172.16.1.100
Trace complete.
C:\>

Al utilizar estas utilidades, la utilidad IOS de Cisco reconoce si la dirección es una dirección IPv4 o IPv6 y utiliza el protocolo apropiado para probar la conectividad. El resultado del comando muestra los comandos ping y traceroute en el router R1 utilizados para probar la conectividad IPv6.

R1# ping 2001:db8:acad:4::100 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:ACAD:4::100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/56 ms
R1#
R1# traceroute 2001:db8:acad:4::100 
Type escape sequence to abort.
Tracing the route to 2001:DB8:ACAD:4::100
1.   2001:DB8:ACAD:2::2 20 msec 20 msec 20 msec
2.   2001:DB8:ACAD:3::2 44 msec 40 msec 40 msec 
R1#

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 cpushow 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.

Las caídas de la cola de entrada (input queue drops) (y los contadores relacionados ignored y throttle) significan que en algún momento se entregó más tráfico al router del que podía procesar. Esto no indica necesariamente un problema. Podría tratarse de tráfico normal durante los períodos de máxima actividad. Sin embargo, podría ser una indicación de que la CPU no puede procesar paquetes a tiempo, por lo que si este número es consistentemente alto, vale la pena tratar de detectar en qué momentos estos contadores están aumentando y cómo esto se relaciona con el uso de la CPU.

Las caídas de la cola de salida (output queue drops) indican que los paquetes se cayeron debido a la congestión en la interfaz. Es normal ver caídas de salida en cualquier punto en el que el tráfico de entrada agregado sea mayor que el de salida. Durante los períodos de tráfico máximo, los paquetes se caen si el tráfico se entrega a la interfaz más rápido de lo que puede ser enviado. Sin embargo, incluso si esto se considera un comportamiento normal, provoca caídas de paquetes y retrasos en las colas, por lo que las aplicaciones que son sensibles a ellos, como la VoIP, pueden sufrir problemas de rendimiento. Ver constantemente caídas de cola de salida puede ser un indicador de que se necesita implementar un mecanismo de cola avanzado para implementar o modificar la QoS.

Los errores de entrada (input errors) indican errores que se experimentan durante la recepción de la trama, como errores de CRC. Un alto número de errores CRC podría indicar problemas de cableado, problemas de hardware de la interfaz o, en una red basada en Ethernet, desajustes dúplex.

Los errores de salida (output errors) indican errores, como colisiones, durante la transmisión de una trama. En la mayoría de las redes basadas en Ethernet de hoy en día, la transmisión full-duplex es la norma, y la transmisión half-duplex es la excepción. En la transmisión full-duplex, no pueden producirse colisiones de operación; por lo tanto, las colisiones (especialmente las colisiones tardías) suelen indicar desajustes en el dúplex.

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.

Resolución de Problemas dúplex
Resolución de Problemas dúplex

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.

El comando arp de Windows muestra y modifica las entradas en la caché ARP, que se usan para almacenar las direcciones IPv4 y sus direcciones físicas de Ethernet (MAC) resueltas. Como se muestra, el resultado del comando arp de Windows, enumera todos los dispositivos que actualmente están en la caché ARP.

La información que se muestra para cada dispositivo incluye la dirección IPv4, la dirección física (MAC) y el tipo de direccionamiento (estático o dinámico).

Si el administrador de red desea volver a llenar la caché con información actualizada, se puede borrar la caché mediante el comando arp -d de Windows.

Nota: Los comandos arp en Linux y MAC OS X tienen una sintaxis similar.

C:\> arp -a
Interface: 10.1.10.100 --- 0xd
  Internet Address      Physical Address      Type
  10.1.10.1             d4-8c-b5-ce-a0-c0    dynamic
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.251           01-00-5e-00-00-fb     static
  239.255.255.250       01-00-5e-7f-ff-fa     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static
C:\>

El comando netsh interface ipv6 show neighbor de Windows enumera todos los dispositivos que están actualmente en el caché de la tabla de detección de vecinos.

La información que se muestra para cada dispositivo incluye la dirección IPv6, la dirección física (MAC) y el tipo de direccionamiento. Al examinar la tabla de vecinos, el administrador de red puede verificar que las direcciones IPv6 de destino se asignen a las direcciones Ethernet correctas. Las direcciones IPv6 link-local se configuraron manualmente en todas las interfaces del R1 como FE80::1. De manera similar, se configuró el R2 con la dirección link-local FE80::2 en sus interfaces, y se configuró el R3 con la dirección link-local FE80::3 en sus interfaces. Recuerda que una dirección link-local debe ser única solo en ese enlace o red.

Nota: en los sistemas operativos Linux y MAC OS X, se puede mostrar la tabla de vecinos mediante el comando ip neigh show.

C:\> netsh interface ipv6 show neighbor 
Internet Address                              Physical Address   Type
--------------------------------------------  -----------------  -----------
fe80::9657:a5ff:fe0c:5b02                     94-57-a5-0c-5b-02  Stale
fe80::1                                       d4-8c-b5-ce-a0-c0  Reachable (Router)
ff02::1                                       33-33-00-00-00-01  Permanent
ff02::2                                       33-33-00-00-00-02  Permanent
ff02::16                                      33-33-00-00-00-16  Permanent
ff02::1:2                                     33-33-00-01-00-02  Permanent
ff02::1:3                                     33-33-00-01-00-03  Permanent
ff02::1:ff0c:5b02                             33-33-ff-0c-5b-02  Permanent
ff02::1:ff2d:a75e                             33-33-ff-2d-a7-5e  Permanent

El comando show ipv6 neighbors muestra un ejemplo de la tabla de detección de vecinos en el router Cisco IOS.

Nota: Los estados de los vecinos en IPv6 son más complejos que los estados de la tabla ARP en IPv4. RFC 4861 contiene información adicional.

R1# show ipv6 neighbors 
IPv6 Address                        Age  Link-layer Addr   State  Interface
FE80::21E:7AFF:FE79:7A81              8  001e.7a79.7a81    STALE  Gi0/0
2001:DB8:ACAD:1:5075:D0FF:FE8E:9AD8   0  5475.d08e.9ad8    REACH  Gi0/0

Cuando se encuentra una dirección MAC de destino en la tabla de direcciones MAC del switch, el switch reenvía la trama solo al puerto con el dispositivo que tiene esa dirección MAC específica. Para hacer esto, el switch consulta su tabla de direcciones MAC. La tabla de direcciones MAC indica la dirección MAC conectada a cada puerto. Usa el comando show mac address-table para visualizar la tabla de direcciones MAC en el switch. Se muestra un ejemplo de tabla de direcciones MAC de switch.

Vale notar que la dirección MAC de PC1, un dispositivo en VLAN 10, se detectó junto con el puerto de switch S1 al que se conecta PC1. Recuerda que la tabla de direcciones MAC de un switch solo contiene información de capa 2, que incluye la dirección MAC de Ethernet y el número de puerto. No se incluye información de dirección IP.

S1# show mac address-table
              Mac Address Table
--------------------------------------------
Vlan      Mac Address         Type     Ports
All       0100.0ccc.cccc      STATIC   CPU
All       0100.0ccc.cccd      STATIC   CPU
10        d48c.b5ce.a0c0      DYNAMIC  Fa0/4
10        000f.34f9.9201      DYNAMIC  Fa0/5
10        5475.d08e.9ad8      DYNAMIC  Fa0/13
Total Mac Addresses for this criterion: 5

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.

Un análisis de la tabla ARP de PC1 utilizando el comando arp de Windows muestra que la tabla ARP ya no contiene una entrada para la puerta de enlace por defecto 10.1.10.1, como se muestra en la salida del comando.

C:\> arp -a
Interface: 10.1.10.100 --- 0xd
  Internet Address      Physical Address      Type
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.251           01-00-5e-00-00-fb     static
  239.255.255.250       01-00-5e-7f-ff-fa     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static
C:\>

No hubo cambios de configuración en el router, de modo que la resolución de problemas se centra en el S1.

La tabla de direcciones MAC para el S1, muestra que la dirección MAC del R1 está en una VLAN diferente que el resto de los dispositivos en 10.1.10.0/24, incluida la PC1.

S1# show mac address-table
              Mac Address Table
--------------------------------------------
Vlan      Mac Address         Type     Ports
All       0100.0ccc.cccc      STATIC   CPU
All       0100.0ccc.cccd      STATIC   CPU
 1        d48c.b5ce.a0c0      DYNAMIC  Fa0/1
10        000f.34f9.9201      DYNAMIC  Fa0/5
10        5475.d08e.9ad8      DYNAMIC  Fa0/13
Total Mac Addresses for this criterion: 5
S1#

Mientras se volvían a conectar los cables, se trasladó el cable de conexión del R1 de Fa0/4 en la VLAN10 a Fa0/1 en la VLAN 1. El problema se resolvió después de que el administrador de red configuró el puerto FA 0/1 del S1 para que estuviera en la VLAN, como se muestra en la figura. Ahora la tabla de direcciones MAC muestra la VLAN 10 para la dirección MAC del R1 en el puerto Fa 0/1.

S1(config)# interface fa0/1
S1(config-if)# switchport mode access
S1(config-if)# switchport access vlan 10
S1(config-if)# exit
S1# 
S1# show mac address-table
              Mac Address Table
--------------------------------------------
Vlan      Mac Address         Type     Ports
All       0100.0ccc.cccc      STATIC   CPU
All       0100.0ccc.cccd      STATIC   CPU
10        d48c.b5ce.a0c0      DYNAMIC  Fa0/1
10        000f.34f9.9201      DYNAMIC  Fa0/5
10        5475.d08e.9ad8      DYNAMIC  Fa0/13
Total Mac Addresses for this criterion: 5
S1#

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.

Verificar Puerta de Enlace Predeterminada
Verificar Puerta de Enlace Predeterminada

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.

La salida del comando show ip route de Cisco IOS se utiliza para verificar la puerta de enlace por defecto de R1.

R1# show ip route | include Gateway|0.0.0.0
  
Gateway of last resort is 192.168.1.2 to network 0.0.0.0 
S* 0.0.0.0/0 [1/0] via 192.168.1.2
  
R1#

En un host de Windows, el comando route print de Windows, se utiliza para verificar la presencia de la puerta de enlace predeterminada IPv4 como se muestra en la salida del comando.

C:\> route print
(Output omitted)
  
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.1.10.1      10.1.10.10      11
(Output omitted)

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.

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.

Verificar la Ruta Correcta
Verificar la Ruta Correcta

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.

R1# show ip route | begin Gateway
Gateway of last resort is 192.168.1.2 to network 0.0.0.0
O*E2  0.0.0.0/0 [110/1] via 192.168.1.2, 00:00:13, Serial0/1/0
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.10.0/24 is directly connected, GigabitEthernet0/0/0
L        10.1.10.1/32 is directly connected, GigabitEthernet0/0/0
      172.16.0.0/24 is subnetted, 1 subnets
O        172.16.1.0 [110/100] via 192.168.1.2, 00:01:59, Serial0/1/0
      192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
C        192.168.1.0/30 is directly connected, Serial0/1/0
L        192.168.1.1/32 is directly connected, Serial0/1/0
O        192.168.1.4/30 [110/99] via 192.168.1.2, 00:06:25, Serial0/1/0
R1#

R1# show ipv6 route
IPv6 Routing Table - default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
       NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       a - Application
OE2 ::/0 [110/1], tag 1
     via FE80::2, Serial0/1/0
C   2001:DB8:ACAD:1::/64 [0/0]
     via GigabitEthernet0/0/0, directly connected
L   2001:DB8:ACAD:1::1/128 [0/0]
     via GigabitEthernet0/0/0, receive
C   2001:DB8:ACAD:2::/64 [0/0]
     via Serial0/1/0, directly connected
L   2001:DB8:ACAD:2::1/128 [0/0]
     via Serial0/1/0, receive
O   2001:DB8:ACAD:3::/64 [110/99]
     via FE80::2, Serial0/1/0
O   2001:DB8:ACAD:4::/64 [110/100]
     via FE80::2, Serial0/1/0
L   FF00::/8 [0/0]
     via Null0, receive
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.

Proceso de tablas de enrutamiento
Proceso de tablas de enrutamiento

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.

Verificar las ACL
Verificar las ACL

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.

El comando show ip access-lists muestra que la ACL está configurada correctamente, como se muestra.

R3# show ip access-lists
Extended IP access list 100
    10 deny ip 172.16.1.0 0.0.0.255 any (108 matches)
    20 permit ip any any (28 matches)
R3#

Podemos verificar qué interfaz tiene la ACL aplicada usando el comando show ip interfaces serial 0/1/1 y el comando show ip interfaces serial 0/0/0. Una investigación más profunda revela que la ACL nunca se aplicó a la interfaz de entrada Serial 0/0/1, si no que se aplicó accidentalmente a la interfaz G0/0, lo que bloqueó todo el tráfico saliente de la red 172.16.1.0/24.

R3# show ip interface serial 0/1/1 | include access list
  Outgoing Common access list is not set
  Outgoing access list is not set
  Inbound Common access list is not set
  Inbound  access list is not set
R3#
R3# show ip interface gig 0/0/0 | include access list
  Outgoing Common access list is not set
  Outgoing access list is not set
  Inbound Common access list is not set
  Inbound  access list is 100
R3#

Una vez ubicada correctamente la ACL IPv4 en la interfaz entrante del puerto Serial 0/0/1, como se muestra en la figura, los dispositivos podrán conectarse con éxito al servidor.

R3(config)# interface GigabitEthernet 0/0/0
R3(config-if)# no ip access-group 100 in
R3(config-if)# exit
R3(config)#
R3(config)# interface serial 0/1/1
R3(config-if)# ip access-group 100 in
R3(config-if)# end
R3#

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.